At jet speed, clock error is distance

On a timeline, ±40 ms is a short bar. On a map it is a stretch of track, and its length is speed times time. At 170 m/s the stretch is 13.6 m long.

That matters whenever an event sits near a line: a ridge that cuts line of sight, a range boundary, the edge of a keep-out area. Near a line, the question stops being when an event happened and becomes which side it happened on.

The Foxborne example dataset has no jet. The jet figures here are arithmetic on the dataset’s clock bounds, not an incident.

The arithmetic

Clock error becomes distance along the track: speed times the time bound. Take the ±40 ms bound that the example dataset carries on its PX4 flight logs, at three speeds:

• Ground robot, 1.25 m/s. UGV-02 drove its lane at this commanded speed in INC-0143, an example from the Foxborne example dataset. 1.25 × 0.040 = ±0.05 m.
• Quad, 12 m/s. The dataset lists its Q4 quad at this speed. 12 × 0.040 = ±0.48 m.
• Jet, 170 m/s, about 330 knots. 170 × 0.040 = ±6.8 m, a 13.6 m stretch of track.

Bounds add when you place one source’s event on another source’s track. A journal line carries ±6 ms and the flight log’s track ±40 ms: ±46 ms in all, or ±7.8 m at 170 m/s.

A ground receive time is worse, and lopsided. In the example dataset the receiver carries ±15 ms plus link latency, 412 ms at the 95th percentile on the INC-0142 run. At 170 m/s the message left the aircraft up to 72.6 m back along the track (170 × 0.427), and at most 2.6 m ahead.

The receipts are sparse as well. With a 1 Hz heartbeat, as in the examples, receipts land 170 m apart.

Clock error runs along the track

A time error moves a point along the path the vehicle flew, forward or back. It never pushes the point off the track. Position error does, in any direction, and PX4 reports it separately in sensor_gps as eph, the horizontal position accuracy in meters.¹

So draw the bound as a piece of the track itself. It runs from the position at the logged time minus the bound to the position at the logged time plus the bound.

On a turn, the piece follows the curve. For a receive time, extend it backward by the latency.

Near a line, ask which side

Range boundaries, keep-out areas and ridge lines are all lines on the ground. If an event’s piece of track crosses one, the log cannot put the event on either side. That is the spatial twin of order unknown, and the report should say “side unknown” just as plainly.

Speed decides how often that happens. At 12 m/s, only an event logged within 0.48 m of the line is in doubt. At 170 m/s, anything within 6.8 m is, and a ground receipt placed up to 72.6 m past the line could have left before it.

Ridge lines matter for links. If the link drops as the aircraft passes behind a ridge, the ground log places the drop only to within its receipt spacing. At 1 Hz, that is 170 m of track.

How GPS time anchors a fast-mover log

A PX4 log counts microseconds from boot. Its sensor_gps topic carries timestamp, the time since system start, and time_utc_usec, the UTC time from the GPS module. A third field, timestamp_time_relative, places that UTC time on the boot clock.¹

Each fix is two readings of one instant, and a flight’s worth of fixes gives the offset from boot to UTC. The pair is only as good as the path the time took. PX4’s documentation notes that time sent over serial carries “latency and jitter from serial communication”.²

A PPS signal gives much higher precision. PX4’s PPS capture driver timestamps each pulse with a hardware timer, at sub-microsecond capture precision depending on the hardware.² It then computes the offset between GNSS time and the autopilot clock, and the pps_capture topic carries the pair:³

uint64 timestamp			  # time since system start (microseconds) at PPS capture event
uint64 rtc_timestamp		# Corrected GPS UTC timestamp at PPS capture event
uint8  pps_rate_exceeded_counter # Increments when PPS dt < 50ms

At 170 m/s, one microsecond is 0.17 mm of track. PPS capture needs a flight controller with a timer input that can capture the pulse, and CONFIG_DRIVERS_PPS_CAPTURE=y in its board configuration.²

How flight test recorders keep time

Flight test recorders that follow IRIG 106 solve the same problem with a counter. The Range Commanders Council publishes the standard chapter by chapter, and the edition on its TRMC page is 106-24R1.⁴ Chapter 11 of that edition puts a relative time counter in every packet header.⁶

The counter is a free-running 10 MHz binary counter, 48 bits wide and common to all data channels. It is derived from an internal crystal oscillator and stays free-running through each session, such as a recording.⁶ One count is 100 ns, which at 170 m/s is 17 µm of track.

Absolute time arrives in time data packets, which the standard treats “like another data channel”.⁵ With a time source other than None, the recorder writes one at least once a second.⁵ A time data packet must also be the first dynamic packet of each recording.⁵

Each time packet carries the time in its body, in formats that include IRIG-B, UTC time from GPS and native GPS time.⁶ The recorder captures the counter for the time packet’s header, so any data packet’s counter can be read against it.⁶

Within one recorder, every channel shares that counter, so a bus message and an analog sample share one clock.⁶ A cross-clock bound appears only when you merge the recording with a log kept on another clock.

Draw it on the map

1. Keep the bound with the event. Store each event with its source’s clock, anchor and bound, not a bare UTC time.
2. Use the speed at that moment. Take it from the flight log, not from a nominal cruise figure.
3. Draw along the flown track. Extend receive times backward by the latency you measured on that link.
4. Test every line that matters. Range boundaries, keep-out areas and the line-of-sight shadow from your own elevation data all count.
5. Write “side unknown” when a piece crosses a line. Then look for a better source: the flight log instead of a receipt, or a PPS anchor instead of a serial one.