When working in a system with different devices that continuously communicate/log time-stamped data, the synchronization of the devices' clocks is crucial to be able to consolidate the data.

In this article we’ll first, determine the different calculation delays within an SBG INS, then see how a SBG INS synchronizes its own clock with a GNSS time and then we'll highlight the tools that can be used to synchronize the clock across multiple devices.

INS output latency

The output latency is an important aspect in real time control applications, where a higher output latency could degrade control loops performance. SBG INS embedded software has been designed to minimize output latency: once sensor data are sampled, the Extended Kalman Filter (EKF) performs small and constant-time computations before the outputs are generated.

Typically the observed output delay is less than one millisecond.

Note that CAN Logs might be received after all serial outputs because the CAN protocol cannot guarantee the output delay in case of traffic on the CAN bus.


Good to know

The processing latency should be added to the data transmission latency if you want to get total delay. This transmission latency vary from one interface to another.

For instance, a 50bytes message sent on a UART interface at 115200bps will take 4ms for complete transmission. Consider higher baudrates to minimize output latency.


Event inputs

Inertial sensors can include up to 5 synchronization inputs that can be used for different purposes:

  • Event triggered logs: All pulses received generate events that can generate specific Logs output. Any output log can be triggered by an event pulse.
  • Event Marker: An event marker log can be sent each time a pulse is received in order to time mark each event.
  • PPS input: When connected to an external GNSS system, the PPS signal is used to realign and synchronize internal clock to GPS clock.
  • Other aiding input timestamping: If a specific aiding sensor generates pulses that time stamp the following output, the corresponding event input can be used for data synchronization.

Event triggered logs

In this mode of operation, the inertial device runs on its own clock to sample sensor data and compute the inputs.

Once a new output is ready to send, the system will simply check if an event input was received during last processing loop, and will send the output messages accordingly.

This mode of operation may induce an output jitter of up to 5ms due to the synchronized internal and host clocks.


SBG Systems sensors handle up to 200Hz input. In case of higher frequency events, only the last received event will be considered for message triggers.

Event markers handling

Event markers allows you to precisely measure the time of events such as camera shutter time, up to the microsecond precision. Once received, events inputs are precisely timestamped and stacked in the system and a marker output message will be sent during the next message output window.

This log will include all events received during previous loop.

Events In


SBG Systems sensors handle up to 1kHz event Marker’s input. Sending more than 1KHz events may overload the internal CPU.

Event output

The INS can be used to synchronize other devices by generating pulses on a synchronization output pin.

These pulses can be generated based on the following modes:

  • Main loop divider: an event is sent at the beginning of an INS loop (at the sensor sample time). A divider can be configured to reduce its frequency. For example, If the divider is set to 4, the pulse output frequency will be 200Hz / 4 = 50Hz.
  • PPS: an event is sent at the beginning of an INS loop (at the sensor sample time), at 1Hz frequency. It will only be sent once the clock is correctly aligned with the GNSS clock. So this output is provided at each top of a second in UTC time.
  • Virtual odometer: an event is generated each time a specific (configurable) distance has been traveled.

Time synchronization

Internal clock and time

Clock bias and gain estimation with PPS

SBG Systems sensors are able to improve their internal crystal accuracy by using a PPS signal from a GNSS receiver, or high precision clock sources.

The different clock modes are listed below

  • Free running mode : In this mode, the clock is freely running, only based on internal crystal
  • Clock steering mode: Once clock reference is available such as GNSS PPS, the first step is used to realign the main loop to the reference clock. Internal loops will quickly steer to align the processing loops to the top of a second. Delta time between two data samples may not be constant in this phase. Once the clock bias is settled, the clock gain will also be estimated.
  • Clock Valid: In this mode, the clock has been properly aligned to GNSS PPS clock. A constant and precise timing with respect to the external clock is available.


All SBG devices with internal GNSS automatically synchronize their clock to GNSS PPS. If external receiver is used, it's then important to connect the PPS signal along with communication line.

Internal time vs UTC time

At power-up, the internal clock is started from 0, and UTC time is marked as invalid.

Once the internal or external GNSS receiver has a position fix, and a consistent PPS signal is received, the UTC time becomes valid, and enables precise synchronization with other devices.


Before GNSS fix is available, the UTC time starts at an invalid date and time that may be configured in certain product lines.  When the GNSS becomes available, a first value of UTC (based on GNSS time) is provided but it can be a few seconds away from the actual UTC time and when “leap seconds” information becomes available, a jump can be observed to realign output on actual UTC time.

A set of flags informs the user about the UTC time validity.

Synchronizing with external devices

There are three main solutions to synchronize with external equipment.

  • PPS + time messages output. This mode is very similar to common GNSS receivers operation and enables less than 1µs accuracy. See the Event output section of this document.
  • Network Time Protocol (NTP) allows for synchronization with a 1 millisecond accuracy on local network.
  • Precision Time Protocol (PTP) allows for synchronization with an accuracy of 150 nanosecond to 1µs . It however requires specific Hardware so is not always usable.

Network Time Protocol (NTP)

NTP is a distributed service that synchronizes the clocks of equipment to a coordinated universal time UTC based on TCP/IP networks.

The protocol uses a hierarchical (master-slave topology) of time source, with each level called a Stratum. The highest level (Stratum 0) are the atomic clocks, such as the ones in GNSS satellites. Additional stratums can be added to synchronize equipment on a specific network.

The NTP is only implemented in Stratum 1 to distribute time to other devices. Time is marked as not synchronized until an internal UTC time is available.

NTP uses the UDP protocol, on port number 123.

If you need further details on the NTP protocol you can check the NTP wikipedia page.

Precision Time Protocol (PTP)

Like NTP, PTP is a protocol used to synchronize clocks throughout a TCP/IP network. However it is built to offer a substantially better precision than NTP.

To reach this level of precision, the protocol has a Hardware dependency, and is therefore not applicable on all devices. All SBG inertial devices featuring an Ethernet connection enable the PTP time server, with a measured average time accuracy of 150ns.

The PTP implementation generates a clock marked as faulty in case UTC time is not available internally.

Once UTC time is available, our PTP system can operate as Grand master clock (or passive mode if a higher precision time reference is available on the network).

PTP operates uses the UDP network protocol, on port number 319 and 320.

If you need further details on the PTP protocol you can check the PTP wikipedia page.