4. Time code standards and protocols

Crash measurement synchronization ultimately reduces to one question: how does every sensor, camera, data logger, and controller in the facility agree on what "now" means? Time code standards and protocols answer that question at different levels of precision, robustness, and infrastructure cost. Choosing among IRIG, PTP (IEEE 1588), NTP, and GPS-derived time is not a matter of picking the "best" standard — it is a matter of matching the required timing uncertainty to the physics of the measurement and to the practical constraints of the test cell.

This section examines each standard's mechanism, its typical accuracy, and where it fits in a crash measurement architecture. The guiding principle throughout: the synchronization budget must be small relative to the fastest phenomenon you intend to resolve. A crash pulse with meaningful content up to 1 kHz has features on the order of 1 ms; a synchronization error of 100 µs is then a 10% distortion of the fastest feature, which is usually unacceptable for channel-to-channel correlation. That single calculation already rules out some standards for some roles.

IRIG Time Codes

IRIG time codes (IRIG-A, IRIG-B, and the slower IRIG-E/G variants, standardized under IRIG Standard 200-16) are serial, amplitude-modulated or DC-level-shift pulse trains that carry time-of-day, day-of-year, and control bits. IRIG-B is the workhorse of test ranges: a 1 kHz carrier with a 100 Hz frame rate, encoding 100 bits per second of time information. The DC-level-shift form (IRIG-B00x) is a unidirectional, one-way distribution — a master clock drives a bus, and every connected device decodes the same frame.

The practical attraction of IRIG-B is its determinism and simplicity: no network stack, no negotiation, no packet loss. A well-implemented IRIG-B decoder achieves synchronization on the order of 1–10 µs to the master, and the code is inherently immune to the latency jitter that plagues packet-based protocols. The limitation is equally clear: IRIG is one-way. The master cannot verify that a slave is actually locked, and there is no path for the slave to report its status. In a crash facility, this means IRIG-B is excellent for distributing time to data loggers and transient recorders that support it, but it must be paired with an independent health check — typically a heartbeat or status line, or a periodic comparison against a GPS reference.

A second practical point: IRIG-B carries time-of-day but not a date in the modern sense, and its year field is limited. For test records that must be correlated months later, the facility should define a convention (for example, day-of-year plus a separately logged year) and apply it consistently across all recorders.

PTP — IEEE 1588

Precision Time Protocol is the modern answer for sub-microsecond synchronization over Ethernet. IEEE 1588-2008 (PTPv2) uses a master–slave hierarchy in which the master periodically exchanges Sync, Follow_Up, Delay_Req, and Delay_Resp messages with each slave. The slave computes the offset between its local clock and the master by measuring the round-trip delay and assuming path symmetry. Hardware timestamping — capturing the timestamp in the PHY or MAC rather than in software — is what makes PTP achieve its headline accuracy: typically tens to hundreds of nanoseconds with hardware support, and a few microseconds with software timestamping only.

For crash measurement, PTP is the natural fit when the facility already runs an Ethernet-based data acquisition network and needs tight correlation between high-speed cameras, DAQ chassis, and the event controller. A typical configuration uses a GPS-disciplined grandmaster clock, a PTP-aware switch (transparent clock) to compensate for queuing delay, and slaves configured for the appropriate delay mechanism (end-to-end or peer-to-peer). The critical engineering detail is that PTP accuracy collapses if the network is not PTP-aware: ordinary switches introduce variable queuing delay that the protocol cannot fully correct, and the resulting error can reach milliseconds under load. Verify by monitoring the slave's offset-from-master statistic over a sustained period, not just at startup.

NTP

Network Time Protocol (NTPv4, RFC 5905) is ubiquitous and inexpensive, but its accuracy over a general-purpose network is typically 1–10 ms, and can be worse under congestion. NTP is entirely adequate for timestamping test logs, aligning file timestamps, and providing a coarse common time base across an entire facility. It is not adequate as the primary synchronization source for crash event correlation, where channel-to-channel alignment at the sub-millisecond level matters. The correct role for NTP in a crash facility is supervisory: it keeps servers, workstations, and non-critical devices on a common wall clock, while the measurement-critical path uses PTP or IRIG.

GPS Time

GPS is not a distribution protocol in the same sense as the others — it is a reference source. A GPS receiver with a 1PPS (pulse-per-second) output and a time-of-day message provides an absolute, globally traceable time base with 1PPS edge accuracy typically better than 100 ns. In a crash facility, GPS is almost always the root of the synchronization tree: a GPS-disciplined oscillator (GPSDO) drives the IRIG-B generator and/or the PTP grandmaster. This gives every downstream standard a common, absolute reference, which is what allows records from different test cells — or different facilities — to be compared on a common timeline.

Two cautions apply. First, GPS reception indoors is unreliable; the antenna must have a clear view of the sky, and the receiver should be configured to enter holdover gracefully if the signal is lost, with the holdover drift logged. Second, GPS time is not UTC: it differs by the leap-second offset (currently 18 s). Facilities that log UTC must apply the offset explicitly and document it, or correlation across systems that handle the offset differently will silently fail.

Crash Facility Time Synchronization Hierarchy GPS Receiver + GPSDO 1PPS edge accuracy < 100 ns · absolute reference IRIG-B Generator (DC level shift) One-way serial bus · 1–10 µs to master No slave feedback — needs health check PTP Grandmaster (IEEE 1588) Ethernet · 10–100 ns HW timestamp Requires PTP-aware switches Transient Recorders IRIG-B decoder Legacy DAQ IRIG-B input High-Speed Cameras PTP slave DAQ Chassis PTP slave NTP (supervisory only) Servers, workstations, logs · 1–10 ms coarse wall clock Typical synchronization uncertainty (log scale) PTP HW: 0.1 µs IRIG-B: 5 µs PTP SW: 5 µs NTP: 5 ms

Matching Standards to Measurement Roles

The hierarchy in the figure reflects a practical division of labor. GPS anchors the facility to absolute time. IRIG-B serves devices that predate Ethernet or that require a deterministic, one-way distribution — many transient recorders and legacy DAQ systems fall here. PTP serves the modern Ethernet-connected measurement path: high-speed cameras, PTP-capable DAQ chassis, and the event controller. NTP is relegated to supervisory and administrative devices.

The engineering decision is driven by the required timing uncertainty. For a crash test where the primary correlation requirement is aligning accelerometer channels with video frames, a target of ≤ 100 µs end-to-end is a reasonable starting specification. That budget accommodates PTP with hardware timestamping comfortably, IRIG-B with margin, and excludes NTP. If the facility must correlate a 10 kHz sampled channel across two separate DAQ systems, the budget tightens to ≤ 10 µs, and only PTP-with-hardware-timestamping or a shared IRIG-B distribution will meet it.

Verification and Common Failure Modes

Whatever standard is chosen, the synchronization must be verified, not assumed. A practical verification procedure is to inject a common electrical pulse — a "sync check" signal — into one channel of every recorder simultaneously, then compare the recorded timestamps of that pulse across systems. The spread of those timestamps is the actual, measured synchronization error, and it should be logged for every test campaign. This is the only way to catch the failure modes that protocol status indicators miss.

Common failure modes and their symptoms:

  • PTP offset creeping upward under network load. Symptom: slave offset-from-master grows from nanoseconds to milliseconds during data transfer. Cause: non-PTP-aware switch or a saturated link. Remedy: deploy transparent clocks, isolate measurement traffic on a dedicated VLAN, and monitor offset continuously.
  • IRIG-B decoder losing lock silently. Symptom: one recorder's timestamps drift relative to others by a fixed offset that grows over hours. Cause: marginal signal level, ground loop, or a decoder that free-runs on loss of code. Remedy: monitor the decoder's lock status line and compare against GPS periodically.
  • GPS holdover drift. Symptom: all systems agree with each other but drift together away from UTC. Cause: antenna obstruction or receiver fault. Remedy: log holdover status and the GPSDO's estimated drift; alarm when holdover exceeds a defined threshold.
  • Leap-second mishandling. Symptom: a fixed 18 s offset between systems that apply the GPS-to-UTC correction differently. Remedy: define and document the convention facility-wide, and validate it in the sync-check log.
A useful rule of thumb for specifying a facility: choose the standard whose typical uncertainty is at least ten times smaller than the smallest timing feature you need to resolve. For a 1 kHz crash pulse, that means a target of ≤ 100 µs; for cross-system correlation of 10 kHz channels, ≤ 10 µs. Document the chosen budget and verify it with the sync-check pulse before every campaign.

The standards are complementary, not competing. A well-architected crash facility uses GPS as the root, PTP for the high-speed measurement network, IRIG-B for legacy and deterministic one-way devices, and NTP for everything administrative — with a documented verification procedure that proves the whole chain meets the measurement budget.

← Previous 📖 Contents Next →