Engineering Guides · Module 07

PPS and PTP setup

PTP measures offset using four timestamps and assumes the path delay is the same both ways. PPS provides the once-per-second edge that anchors a clock to GNSS time.

Intermediate
Module 07: Sensor Time Synchronization & Latency Engineering
Written for ROS 2 Jazzy where ROS 2 is used
Sources checked 2026-11-06

Assumptions: Numbers in the examples are illustrative and the code is executed by the site’s tests. Facts taken from a cited source are marked; other statements are general engineering knowledge and must be confirmed on the datasheet of the part you use.

1. Engineering problem

Sensors on a network or on separate boards each have their own clock. Synchronising them to a common time requires a reference (PPS from a GNSS receiver or a PTP grandmaster) and software that disciplines each clock to it.

2. When is this needed?

Setting up multi-sensor fusion with network sensors (LiDAR, cameras, an IMU box).
When sensor timestamps drift relative to each other.
Before specifying switches and NICs for a robot network.

3. Selection and design decisions

In a PTP exchange the leader sends a Sync message at time t1, the follower receives it at t2, sends a delay request at t3 and the leader receives it at t4. With a symmetric path the follower’s offset is ((t2 − t1) − (t4 − t3)) / 2 and the path delay is ((t2 − t1) + (t4 − t3)) / 2. Asymmetric paths put an error of half the asymmetry into the offset. The tools: ptp4l (linuxptp) runs the PTP protocol and can use hardware timestamping where the NIC supports it; phc2sys (also linuxptp) synchronises the system clock to a PTP hardware clock; chrony can take a PPS device as a reference clock.

Overview
Piece	Role	Check
GNSS receiver with PPS output	Provides the once-per-second edge and time of day	PPS wired to a GPIO or serial control line the kernel exposes as /dev/pps0
chrony with PPS refclock	Disciplines the host clock to PPS	chronyc sources shows the PPS source selected
PTP grandmaster	Time source on the network	Clock quality and priority settings
ptp4l	Runs PTP on each NIC	Hardware timestamping supported (ethtool -T)
phc2sys	Copies the NIC clock to the system clock	Offset reported small and stable
Switch	Must handle PTP correctly (boundary or transparent clock) for best accuracy	Vendor documentation

4. Advantages and disadvantages

Hardware timestamping gives much better accuracy than software timestamping and needs NIC support.
PPS is simple and needs a GNSS signal; indoors use a PTP grandmaster.
One grandmaster is a single point of failure for time.

5. Requirements and constraints

NICs and switches in the path support the chosen PTP mode.
Path asymmetry is understood and minimised.
Time source quality is monitored.

6. Architecture

GNSS ──PPS──▶ grandmaster ──PTP──▶ switch ──PTP──▶ LiDAR / camera / IMU box
                         └─▶ host NIC (ptp4l) ─▶ phc2sys ─▶ system clock (chrony)

7. Implementation

Choose the reference (GNSS PPS or PTP grandmaster) and confirm all sensors support it.
Configure ptp4l on the host NIC and check hardware timestamping with ethtool -T.
Run phc2sys to align the system clock and watch its reported offsets.
If using PPS, configure the chrony PPS refclock and check chronyc sources.
Verify by comparing stamps of one physical event across sensors.

def ptp(t1, t2, t3, t4):
    # t1: master sends Sync; t2: slave receives; t3: slave sends Delay_Req; t4: master receives
    offset = ((t2 - t1) - (t4 - t3)) / 2
    delay = ((t2 - t1) + (t4 - t3)) / 2
    return offset, delay
o, d = ptp(100.000000, 100.000150, 100.001000, 100.001050)
print(f"slave offset {o * 1e6:.1f} us, one-way path delay {d * 1e6:.1f} us")
o, d = ptp(100.000000, 100.000130, 100.001000, 100.001130)
print(f"symmetric path: offset {o * 1e6:.1f} us, delay {d * 1e6:.1f} us")

Printed (checked by the site’s tests):

slave offset 50.0 us, one-way path delay 100.0 us
symmetric path: offset 0.0 us, delay 130.0 us

Reading it: in the first exchange the forward leg takes 150 µs and the return leg 50 µs, so the formula reports a 50 µs offset and a 100 µs mean delay, but the “offset” is really the path asymmetry: the true offset may be zero. In the symmetric case (130 µs both ways) it correctly reports zero offset and 130 µs delay. That is why path asymmetry limits PTP accuracy. The timestamps are illustrative; the commands in the steps are not executed by the site’s tests.

8. Real examples

Mobile robot with an Ethernet LiDAR: LiDAR synchronised by PTP to a grandmaster on the robot, host clock disciplined via phc2sys.

9. Failure scenarios

A switch that does not support PTP adds variable delay and ruins accuracy.
Software timestamping used on a NIC without hardware support.
PPS wired but chrony not configured with the refclock.

10. Troubleshooting

Check that all devices agree on the clock source and domain.
Check hardware timestamping with ethtool.
Look at the offset trend: a slow drift means the clock servo is not locked.

11. Validation

The example prints the lines shown (executed by the site tests).
Reported offsets stay below the requirement over a long run.
An event stamped by two sensors agrees within the requirement.

12. Engineering checklist

13. Further references

Wikipedia, Precision Time Protocol and Pulse-per-second signal, read 2026-11-06 (secondary sources; the IEEE 1588 standard itself was not read).
linuxptp ptp4l documentation: linuxptp.nwtime.org, read 2026-11-06.
chrony documentation: chrony.conf(5), read 2026-11-06 (the PPS refclock driver reads the kernel PPS device, typically /dev/pps?).