Time and synchronisation: IRIG-B, GPS and PTP

Why time is not like the other measurements

Every other quantity in an instrumentation chain can be checked, calibrated, and if necessary measured again. Time cannot. A timing error does not look like an error: two curves are simply displaced with respect to each other, both of them perfectly plausible, and the conclusion drawn from them is wrong in a way that no later inspection of the files will reveal.

It is also the only property of the chain that is shared. Every other characteristic belongs to a channel: this sensor is accurate, that filter is set correctly, this converter has enough bits. Time belongs to the installation, which means it cannot be fixed by improving any single box.

Three questions hiding behind one word

Most confusion about synchronisation comes from mixing three requirements that have different solutions and different price tags.

1. What time was it? Absolute date and time, so a recording can be correlated with a radar track, a range log, another aircraft or a weather record. This needs a traceable external reference.
2. Is my clock running at the right rate? Frequency accuracy, which decides how fast two units drift apart and how much your sample rate really is. This needs a stable oscillator, or a disciplined one.
3. Are my channels aligned with each other? Relative alignment inside the installation, which is what almost every analysis actually depends on. This needs a common reference, not necessarily an accurate one.

The practical consequence is worth stating plainly: an installation whose absolute time is out by a hundred milliseconds but whose channels are aligned to a microsecond will produce good engineering results. The reverse will not.

IRIG-B: the classic

IRIG-B is a serial time code with a one-second frame, carrying the day of the year, the hour, the minute and the second, plus optional control fields — the year among them, in the later revisions. One frame, one hundred bits, ten milliseconds per bit, and a distinctive reference marker so a receiver can find the start of the second.

It exists in two flavours you should not mix up. The unmodulated form, often written B000 and usually called DCLS, is a logic-level pulse train: simple, cheap to distribute over a twisted pair, and good to about a microsecond. The amplitude-modulated form on a 1 kHz carrier travels further on coaxial cable and suits existing installations, but you recover the instant by interpolating a sine wave, which typically lands nearer ten microseconds.

Its great virtue is that everything in the test world speaks it: range equipment, older recorders, ground stations, chart recorders that should have been retired. Its limitation is that it is a one-way broadcast — the receiver has no way to tell the source how long the cable was.

GPS: the primary source

A GPS receiver gives you two things, and it matters that they are separate. A pulse per second marks the instant with an accuracy of tens of nanoseconds. A message — NMEA or a binary protocol — says which second that pulse belonged to, and it arrives afterwards, with a latency that varies. Use the pulse for the instant and the message for the label; use the message alone and you have inherited the receiver serial-port jitter.

On an aircraft the practical problems are not about accuracy. They are the antenna and its view of the sky, reacquisition time after a manoeuvre that shades it, and what the equipment does during the gap. A receiver that has lost lock is not wrong about the time — it stops knowing, which is a different and much more manageable failure, provided the equipment says so.

PTP: time over the network

IEEE 1588, generally called PTP, distributes time over Ethernet. A master announces the time, a slave measures the round trip, and the pair converge on the delay so the slave can correct for it. That two-way exchange is the fundamental difference from IRIG-B: the network tells you how long it took, rather than requiring you to know.

It reaches well below the microsecond when the hardware helps — timestamps taken at the physical layer rather than in software, and switches that either participate in the protocol or declare the time they held a packet. Put an ordinary store-and-forward switch in the path and its variable queuing delay goes straight into your time base. That is the single most common way a PTP installation quietly underperforms.

For an Ethernet-based, distributed acquisition architecture it is the natural answer: the same cable that carries the data carries the time, and adding a unit does not mean adding a time cable.

Distributing, not just receiving

The instinct when an installation grows is to give each box a good clock. It is the wrong instinct, and it produces the failure mode that costs the most: two groups of equipment, each internally consistent, separated by a fixed offset that appears in no single file.

So the architecture question comes before the equipment question. One reference, physically distributed to every unit that stamps anything — acquisition, recording, video, and the ground station that will receive the telemetry. Where a unit cannot be reached by the reference, it is a documented exception with a measured offset, not an oversight.

And distribution has its own error budget. A hundred metres of cable is about half a microsecond; that is negligible for most work and dominant if you are chasing bus latencies. If the number matters, measure it once and write it down.

What a properly timed unit actually does

• It disciplines its own oscillator to the reference rather than merely reading it, so its sample rate is right and not just its labels.
• It stamps at the point of acquisition — the instant the sample was taken, not the instant the packet was assembled or the frame left the encoder.
• It records which source dated the data and whether that source was healthy, in the data itself, so nobody has to reconstruct a dropout from memory.
• It has a defined holdover behaviour: on losing the reference it keeps counting, flags that it is doing so, and drifts at a rate you were told in advance.
• And it never silently jumps. A step correction in the middle of a recording is worse than the offset it fixes, because it breaks the one assumption every analysis makes.

Holdover deserves a number rather than an adjective. An oscillator specified at two parts per million drifts two microseconds per second, which is a little over seven milliseconds in an hour. A high-stability oven-controlled part at a hundredth of a part per million drifts some tens of microseconds over the same hour. Both are perfectly usable, and neither is usable if you did not know which one you had.

The check that finds the problem before the flight

There is one test worth institutionalising, and it takes an afternoon. Feed a single sharp event — a switch closure, a pulse, a tone — simultaneously into a channel on every acquisition unit, into the video if you have one, and if possible onto a bus. Record it. Then measure, in the file, the difference between the timestamps of that one event.

Whatever number comes out is your installation alignment, measured rather than assumed. If it matches your requirement, you have a documented result to put in the campaign file. If it does not, you have found the offset while the aircraft is still on the ground, which is the entire point.

Repeat it after any change to the installation, and once during the campaign. It is the cheapest insurance in flight-test instrumentation, and the only one that pays out before the accident rather than after.