Download PDF
Download page Time Synchronization.
Time Synchronization
This article aims to provide you with comprehensive insights into clock management with your Ekinox, Apogee, Quanta or Navsight product.
Internal clock vs UTC time
The sensors have 2 notions to track the status and accuracy of the clocks:
- The internal clock
- It is used for the time-stamping of all messages.
- It is strictly monotonic: it starts at 0 upon powering up the device, and is increased by 1 at each increment.
- The interval between each increment is not fixed: during the synchronization with an external reference clock (most of the time a GNSS receiver or an external PPS) the duration of each interval will change.
- Note that the timestamp has a maximum value of 4 294 967 295: once this value is reached it will cycle back to zero. Since the timestamp is increased every microsecond, it will be reset to zero after the device has been powered-on for about 1 hour and 10 minutes.
- The UTC clock
- It is used to provide human/machine readable absolute time information
- It is not strictly monotonic: during the alignment of the internal clock, or after long loss of the GNSS reception, the UTC time can decrease
Both clocks have independent statuses described below. Keep in mind that there is no 1:1 link between the internal clock status and the UTC status.
Internal clock states - SBG_ECOM_CLOCK_STATUS
The internal clock operates in three different states:
- Free running: When there is no external reference clock input. Either because there is no reference clock configured, or because the reference clock cannot provide a valid reference time (for example before GNSS fix or after a long GNSS outage).
- Steering: When the unit detects a reference clock, it enters the steering state. However, the internal clock is not yet aligned with the reference at this point.
- Valid: When the internal clock is aligned with the reference clock, it enters the valid state. In this state, the clock maintains synchronization for a certain period of time and limits drift when the reference is lost temporarily. For example, during a GNSS outage where the clock reference is the PPS from the GNSS receiver, the clock will remain accurate and stable for ~30 minutes in common cases.
Reference clock configuration
The reference clock can either be a SYNC IN signal (PPS) or GNSS (either internal or External). Be mindful to the actual polarity of PPS signal vs. configuration/expected polarity at SBG device side. Not matching polarities would introduce an offset from the width of the PPS signal (or 1s - width of signal depending on cases) which would be sometimes hard to detect as the product clock would still end in Valid, but with an offset to actual UTC.
The clock reference can be selected in Device Settings → Advanced → Clock Reference (note that, in this setting window, the GNSS selection refers to the SYNC/PPS chosen in the Aiding Assignment screen).
It is important to note that the clock cannot reach a valid state without first going through the steering state.
The following state machine diagram summarizes the different statuses of the internal clock and the transition between each status:
The internal clock-related flags can be read directly from the web interface:
- The "Input Clock" indicator turns "green" when it receives a PPS from the input clock reference and shifts to "red" as soon as the signal is lost.
- The "Clock Status" refers to the internal clock states explained earlier.
Sensor usage and clock status
Make sure you check that the clock status is valid before the start of the mission.
UTC time flags - SBG_ECOM_CLOCK_UTC_STATUS
At power-up, the internal clock is started from 0, and UTC time is marked as invalid.
There are two fields related to the UTC time that can allow you to understand its state: UTC information and UTC accuracy.
The UTC information status gives the information about the full resolution of the UTC time. It has three values:
- Invalid: This status indicates that the UTC time is unknown. The unit has not been able to resolve the UTC time since the last boot, and therefore cannot determine the current UTC time.
- Initialized: This status indicates that the GPS time has been received at least once since the unit started operating, and the leap seconds are known. Thus, the UTC time is fully resolved.
- No leap seconds: The GPS time is known and has been initialized, but there is no precise knowledge of the leap seconds. In that case, the unit will use the leap second value pre-configured in the Firmware or configured by the user.
The UTC accuracy flag indicates the reliability of the reported UTC time:
- Valid: This flag indicates that the value of the UTC time is reliable. As long as the GNSS is available, this flag remains valid. In case of a GNSS outage, the unit will continue to output the UTC time with a good accuracy for a period of time and maintains the valid flag during this period.
- Invalid: This flag indicates either:
- That the UTC time has never been resolved.
- Or that the GNSS signal has been lost for a significant amount of time (around 30 minutes in common cases). The UTC information is still available using our internal clock, but with reduced accuracy.
Keep in mind that, if the unit has been able to resolve the current UTC time since the last boot (UTC information not invalid), it will continue to output a UTC time until it is powered off.
You should use the UTC accuracy flag to confirm whether the UTC time is reliable.
Clock accuracy assessment during GNSS outage
In the event of losing the GPS time source, the unit will continue to accurately output the UTC time for a certain period. The UTC accuracy flag provides a reliable indication of the clock's accuracy at a high level.
If you require a precise estimation of the clock error, you can utilize the following CLK_BIAS_SD. This parameter provides the standard deviation of the accumulated error of the UTC clock since the last acquisition of a GPS time source.
It is important to note that this standard deviation estimator assume "normal conditions" regarding temperature variations and vibrations:
- In stable environmental conditions, the standard deviation may be pessimistic.
- In scenarios with significant temperature variations or high vibrations, the standard deviation may be slightly optimistic.
For minor interruptions in GNSS coverage, it is generally safe to disregard this estimator. It becomes particularly useful when planning to navigate without GNSS for extended periods of time (15 minutes and above).
External devices synchronization
SBG Systems products provide the capability to synchronize multiple external devices. For that, you can use different mechanisms :
- PPS signal: A Pulse at the top of each second. The reference of the PPS is the internal clock of the INS, not the GNSS receiver. Thus, the PPS signal continues to be provided even during GNSS outages.
- PTP (Precision Time Protocol): PTP is available only when the UTC is valid. It returns the following states:
- Faulty: If UTC time is not valid.
- Master: When the UTC time is valid, and the device acts as the network master clock.
- Passive: When the UTC time is valid, but the device is not the master clock due to the presence of a more accurate master clock in the network.
- NTP (Network Time Protocol): similar to PTP with significantly lower accuracy. It can be used to broadcast date and time with an accuracy around 1 to 10 ms. It has only two states: enabled/disabled.
To enable or disable PTP or NTP synchronization methods, you should simply toggle the respective check-boxes in the configuration window shown below:
The different synchronization methods have different level of accuracy:
Synchronization method | Error level | Comment |
---|---|---|
NTP accuracy | 10 ms | Not recommended for applications requiring synchronization, only to propagate a network time. |
PTP accuracy | ~1 μs | SBG PTP implementation provides timestamps in TAI time scale. |
PPS accuracy | ~ 5-8 µs | |
Drift in dead reckoning | ~1 ppm | Drift of the internal clock measured over 30 minutes |
For more details on the processing loop, the time-stamping of events, and the NTP/PTP, please refer to our Knowledge Base.