Time Synchronization

Accurate time synchronization is essential for V2X communication, as message timestamps must align precisely across all participating stations. The cube:evk achieves this through GNSS-based Pulse-Per-Second (PPS) synchronization combined with chrony time management. This setup provides sub-microsecond accuracy between the system clock and GNSS reference time.

1. Overview

The cube:evk uses the PPS output from the u-blox GNSS receiver and the corresponding time data stream (UBX protocol via gpsd) to discipline the system clock. The chrony daemon integrates both sources to maintain a highly stable and precise system time. This configuration ensures that V2X timestamps follow the TAI (International Atomic Time) reference as defined by ETSI ITS-G5 and C-V2X standards.

2. Chrony Configuration

The time service is configured through:

1
/etc/chrony.conf

The default configuration is optimized for GNSS-based synchronization:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# public NTP server pool
pool 0.openembedded.pool.ntp.org iburst maxpoll 3

# use time pulses (PPS) and time data from u-blox GNSS receiver
refclock PPS /dev/pps_gnss poll 0 refid PPS0 lock GPS
refclock SHM 0 refid GPS offset 0.01 delay 0.5 noselect
# Prefered over SHM 0 but does not work with gpsd 3.23.1
#refclock SOCK /run/chrony.ttyM8U.sock offset 0.01 delay 0.5 refid GPS noselect

# step clock up to three times if adjustment is largen than 1 second
makestep 1.0 3

# store drift parameters (also used for restoring time at startup)
driftfile /var/lib/chrony/drift

# synchronize with RTC (if available)
rtcsync

# set TAI/UTC offset according to timezone database
leapsectz right/UTC

Key Configuration Details

• PPS /dev/pps_gnss
  Uses the precise 1 Hz pulse from the GNSS receiver to lock the system clock.
• SHM 0
  Receives coarse time data (seconds, leap status) from gpsd via shared memory.
• lock GPS
  Ties the PPS signal to the GNSS time stream to validate the source.
• makestep 1.0 3
  Allows three large clock corrections (> 1 s) at startup to quickly converge on GNSS time.
• leapsectz right/UTC
  Ensures leap seconds are applied correctly according to the timezone database.

When operating, chrony maintains a stratum 1 reference derived from the GNSS PPS.

3. Checking Synchronization Status

You can verify synchronization at runtime using chronyc, the command-line interface for chrony.

View Time Sources

1
cube:~$ chronyc sources

Example output:

1
2
3
4
5
6
7
8
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
#* PPS0                          0   0   377     2  -2810ns[-3003ns] +/-  125ns
#? GPS                           0   4   377    21  -3141us[-3141us] +/-  251ms
^- saiph.pmsf.net                2   6   377    48  -7529us[-7528us] +/-   33ms
^- netcup01.theravenhub.com      2   6   377   32m   -651us[ -641us] +/-   14ms
^- x1.ncomputers.org             2   6   377    48    -28ms[  -28ms] +/-   85ms
^- 192.248.187.154.vultruse>     2   6   377   239   +490us[ +489us] +/-   22ms

The #* PPS0 line indicates that PPS is the active synchronization source, showing nanosecond-level precision and confirming proper GNSS lock.

View Detailed Tracking

1
cube:~$ chronyc tracking

Typical output:

1
2
3
4
5
6
7
8
9
10
11
12
13
Reference ID    : 50505330 (PPS0)
Stratum         : 1
Ref time (UTC)  : Thu Oct 23 13:21:21 2025
System time     : 0.000000115 seconds fast of NTP time
Last offset     : +0.000000052 seconds
RMS offset      : 0.000000061 seconds
Frequency       : 14.430 ppm slow
Residual freq   : +0.000 ppm
Skew            : 0.023 ppm
Root delay      : 0.000000001 seconds
Root dispersion : 0.000002208 seconds
Update interval : 1.0 seconds
Leap status     : Normal

Use chronyc sources and chronyc tracking to confirm that PPS0 is the active reference. Stable nanosecond offsets indicate correct GNSS time synchronization.

4. Verifying PPS Input

The PPS signal can be tested directly using ppstest to ensure the hardware pulse is detected:

1
cube:~$ sudo ppstest /dev/pps0

Expected output (repeating once per second):

1
2
3
4
5
6
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1761225714.999997082, sequence: 85701 - clear  0.000000000, sequence: 0
source 0 - assert 1761225715.999999802, sequence: 85702 - clear  0.000000000, sequence: 0
source 0 - assert 1761225717.000004307, sequence: 85703 - clear  0.000000000, sequence: 0

Each line corresponds to a precise 1 Hz PPS pulse received from the GNSS module.

5. Managing TAI/UTC Offset

The V2X stack operates on TAI (International Atomic Time) rather than UTC. The cube-timectl utility provides a convenient interface to inspect and set the TAI-UTC offset used by the system and middleware.

Checking Time Status

1
cube:~$ cube-timectl show

Example output:

1
2
3
4
ItsTimestamp: 688311210198ms
SystemClockSynchronized: yes
TaiUtcOffset: 37
LeapSecondStatus: none

Setting TAI Offset Manually

1
cube:~$ sudo cube-timectl set-tai-offset 42

This command updates the TAI offset based on the latest GNSS or system data. The current TAI-UTC difference (as of 2025) is 37 seconds.

6. Typical Synchronization Flow

1. GNSS receiver outputs 1 Hz PPS on /dev/pps_gnss.
2. gpsd provides matching time data via shared memory.
3. chrony locks the system clock to PPS for sub-microsecond precision.
4. cube-timectl reports synchronization and TAI offset status.
5. V2X services use the synchronized system time for message timestamps.