Feature Guide: PTP and gPTP

Overview

Precision Time Protocol (PTP) enables precise time synchronisation between devices across an Ethernet network. OXTS devices support PTP according to:

• IEEE 1588 (PTPv2)

• IEEE 802.1AS (gPTP)

• AUTOSAR gPTP profile

PTP can be used to synchronise multiple devices to a common time reference, such as GPS time or another network master clock. Depending on configuration, your device can act as:

• PTP Master – provides time to other devices, synchronised to GPS time.

• PTP Slave – receives time from another PTP master.

Note: When post-processing in NAVsolve, PTP time is currently available in simulated processing mode only and is not supported in combined processing mode.

Supported Modes

1. PTP (IEEE 1588)

Standard Precision Time Protocol as defined by IEEE 1588. Suitable for most general timing applications.

2. gPTP (IEEE 802.1AS)

Generalised PTP used in automotive and industrial Ethernet applications, offering a tightly standardised protocol for improved interoperability between different hardware vendors.

3. gPTP AUTOSAR

AUTOSAR-compliant PTP with optional message extensions and static delay configuration for specialised automotive applications.

Configuring PTP

You can configure PTP in NAVconfig under Interfaces → PTP.

Step 1. Select PTP Mode

Choose one of:

• PTP

• gPTP

• gPTP AUTOSAR

Step 2. Choose System Mode

Select how your device will behave in the network:

• Master – Acts as a Grandmaster, providing time to other devices.

• Slave – Synchronises time from an external master.

Note: When configured as a Master, the device can only operate with GNSS as the time source, hence GNSS must be available at initialisation.

Step 3. Configure Time Epoch

Select which time base the device will use:

Note if using PTP slave mode: by default, the timestamp in NCOM will be in the GPS epoch, to output time in the raw PTP epoch enter the command -ncom_time_source_no_conversion under the Advanced → Commands section of NAVconfig.

Step 4. Configure AUTOSAR Options (if applicable)

If gPTP AUTOSAR is selected:

• Add Message Extensions via the Data ID List.

• To use standard gPTP-compliant messages, enable Message Compliance.

• If acting as a Master, specify User Data Length, Sub-TLVs, and whether to include a CRC.

• If acting as a Slave, you can optionally apply a static delay in nanoseconds to account for network latency.

Verifying PTP Operation

Method 1: Using NAVdisplay

You can view the following the NCOM signals:

• PTP Status – identifies whether PTP is in operation - the signal should display Master (6) or Slave (9) if working correctly.

• PTP Epoch Type – displays the epoch the device is currently configured to use.

Method 2: Using Wireshark

You can confirm that PTP packets are being transmitted and synchronisation messages are present.

1. In the Capture filter box (before starting the capture), enter host 225.0.1.129 || host 224.0.0.107. These are the multicast addresses used by PTP (IEEE 1588) and gPTP (802.1AS).

2. Start capture of network interface connected to the PTP network.

3. Verify the following message types are present:

   • Announce – advertises the grandmaster clock’s state.

   • Sync / Follow_Up – provide timing information to slaves.

   • Delay_Req / Delay_Resp – used by slaves to measure path delay.

Announce message for a device configured to Master mode using the UTC epoch

Behaviour at Start-Up

When the device is configured as a PTP master but GNSS is not yet available, it will still transmit PTP Sync and Announce messages. However:

• These messages use the device's internal oscillator and do not represent valid absolute time.

• The TimeSource will appear as internal oscillator (0xA0) in the announce message.

• Once GNSS lock is achieved, the device automatically transitions to a GNSS-disciplined grandmaster:

  • The TimeSource updates to GPS (0x20).

  • The originTimestamp field in Sync messages jumps to a real epoch (GPS/UTC).

Practical Notes

• Network setup: Ensure the PTP master and slaves are connected to the same Ethernet segment or through PTP-enabled switches.

• Post-processing: PTP timestamps are currently only supported in simulated processing mode, not when using combined processing mode in NAVsolve.