3. Time base architecture

Sub-microsecond video synchronization is not achieved by a single clever device; it is the outcome of a coherent time base architecture. Every camera, capture card, and encoder in an instrumented channel must agree on what time it is to within a fraction of a microsecond, and it must keep agreeing while the system runs for hours. This chapter explains how that shared time base is built: where the master clock comes from, how IEEE 1588 Precision Time Protocol (PTP) and its generalized variant gPTP distribute it, which profile to choose, and how each endpoint disciplines its local oscillator so that timestamp error stays inside the video sync budget.

Why the time base, not the trigger, dominates accuracy

A common misconception is that a hardware trigger line alone guarantees tight sync. In practice, a trigger only aligns events; it does not tell you when those events occurred in a common time scale. If two cameras are triggered simultaneously but their internal clocks drift apart by 50 ppm, their frame timestamps diverge by 50 µs per second of free-running operation. Over a 60-second capture that is 3 ms — far outside any sub-microsecond requirement. The time base is therefore the foundation: triggers and genlock align phase, while PTP-disciplined clocks align the time scale in which every timestamp is expressed.

Define the reference convention used throughout this course: all timestamps are expressed in the PTP epoch (TAI seconds since 1970-01-01), and "sync error" means the absolute difference between an endpoint's reported timestamp for a physical event and the grandmaster's timestamp for the same event. Positive error means the endpoint is ahead of the grandmaster.

Master clock selection

The grandmaster (GM) is the single source of truth for the domain. Selection should be deliberate, not left to chance. Three practical options dominate instrumented video systems:

• GNSS-disciplined grandmaster. A GPS/GNSS receiver with a PTP-capable NIC provides absolute traceability and long-term stability (typically <100 ns to UTC). Best when recordings must be correlated across sites or with external data sources.
• Local high-stability grandmaster. An OCXO- or rubidium-referenced clock generator. Excellent short-term stability and immunity to GNSS outages, but no absolute traceability unless disciplined externally.
• Boundary clock on a switch. A PTP-aware switch acting as GM or boundary clock. Convenient, but its oscillator quality and servo implementation determine the floor of achievable accuracy.

Selection criteria should be explicit: required absolute accuracy, holdover duration during reference loss, number of hops to endpoints, and whether the capture must be traceable to an external time standard. For a lab instrumented channel targeting <500 ns, a GNSS-disciplined GM with a boundary-clock-capable switch is the usual baseline.

PTP and gPTP: what actually gets exchanged

IEEE 1588 PTP synchronizes clocks through a message exchange that measures path delay and offset. The core sequence is Sync, Follow_Up (in two-step mode), Delay_Req, and Delay_Resp. The slave computes:

offset = ((t2 - t1) - (t4 - t3)) / 2
path_delay = ((t2 - t1) + (t4 - t3)) / 2

where t1 is the GM Sync egress timestamp, t2 the slave ingress timestamp, t3 the slave Delay_Req egress, and t4 the GM ingress. The critical engineering point is where t1/t2/t3/t4 are captured: hardware timestamping at the PHY/MAC boundary removes software stack jitter (often tens of microseconds) that would otherwise swamp the sub-microsecond budget. Always verify that hardware timestamping is enabled on both GM and slave ports.

gPTP (IEEE 802.1AS) is a profile of IEEE 1588 tailored for time-sensitive networking. It uses peer-to-peer delay measurement, mandates hardware timestamping, and runs a best-master-clock (BMC) election based on priority1, clockClass, clockAccuracy, and offsetScaledLogVariance. gPTP is the natural choice when the video transport rides an AVB/TSN Ethernet fabric, because switches participate as time-aware bridges and correct for residence time.

Choosing an IEEE 1588 profile

The profile fixes message rates, transport, and timestamping rules. Mismatched profiles are a frequent cause of "PTP is running but sync is poor." The table below summarizes the profiles most relevant to instrumented video.

For a camera-to-capture instrumented channel on a TSN switch, use 802.1AS. For SMPTE-style studio integration, ST 2059-2. For a simple direct-attached lab setup, the default profile with hardware timestamping and a 125 ms sync interval is a reasonable starting point.

Clock discipline strategies

Receiving PTP messages is only half the job; the endpoint must discipline its local clock. Three strategies are common:

1. Step adjustment. On large offset (e.g., >1 ms at startup), the clock jumps. Fast convergence, but causes timestamp discontinuities — unacceptable mid-capture.
2. Slew (frequency) adjustment. The servo adjusts the oscillator's rate to null the offset gradually. Continuous, monotonic time; the standard choice during recording.
3. Hybrid with holdover. Slew during normal operation, freeze the last frequency correction when the GM is lost, and re-converge on recovery. Essential for GNSS-outage resilience.

A practical PI servo configuration for a camera endpoint might use a proportional gain around 0.7 and integral gain around 0.3 (normalized), with a slew limit of 200 ppm and a step threshold of 1 ms. These are example values to be tuned against measured offset; they are not universal constants. The servo should log offset and frequency correction so that convergence and residual error can be verified.

Verification and typical failure symptoms

After deployment, verify the time base with an independent measurement: compare the endpoint's PTP offset against a direct measurement (e.g., a pulse-per-second output observed on a scope, or a second PTP slave on the same segment). Expected residual offset for a well-tuned hardware-timestamped endpoint on a boundary-clock switch is on the order of tens to low hundreds of nanoseconds.

Common symptoms and their causes: offset oscillating with large amplitude usually indicates a profile mismatch or asymmetric path delay; a slowly growing offset with periodic resets suggests the servo is stepping rather than slewing; high offset only on some endpoints points to missing hardware timestamping or a non-PTP-aware switch dropping Follow_Up messages. Each of these is diagnosable from the offset and frequency-correction logs.

Putting it together: a reference configuration

A reproducible starting configuration for a two-camera instrumented channel on a TSN switch:

# Grandmaster (GNSS-disciplined)
ptp4l -i eth0 -f /etc/linuxptp/gPTP.cfg -m --hwstamp

# Boundary clock switch: enable 802.1AS, P2P delay, HW timestamping
# Camera endpoint A
ptp4l -i eth0 -f /etc/linuxptp/gPTP.cfg -m --hwstamp -s
phc2sys -s eth0 -c CLOCK_REALTIME -w -m -O 0

# Verify hardware timestamping
ethtool -T eth0 | grep -i hardware

After convergence (allow 30–60 s), inspect the offset reported by ptp4l. A healthy endpoint on a boundary-clock switch should settle to a few tens of nanoseconds of offset with low variance. If offset remains above 1 µs, check profile consistency, confirm hardware timestamping on every hop, and verify that the switch is not treating PTP as ordinary multicast traffic. Only after the time base is verified should genlock and trigger alignment be commissioned — the time base is the reference against which every other synchronization mechanism is measured.