Skip to content
Docs
foxborne.comRequest a pilot

Clock uncertain

Warns when a source has no trustworthy anchor to UTC or its error exceeds the ordering bound. It is always on, because every before and after claim between sources depends on it.

Rule referenceMarkdown
On this page8
clock_uncertainv1.0Always on, locked
Detects
A source has no trustworthy anchor, or its estimated error exceeds the ordering bound.
Threshold
Anchor missing or error above 2 s
Reads
Every source
Report wording
Warning: ordering between sources is uncertain

What it reads#

The rule reads what alignment produced for each source in a run: its clock, its anchor and its error bound. The run page shows the same values in Source files, under Clock and anchor and Bound. The other rules each read one source, and this one checks them all.

Two cases in the example dataset leave a source without an anchor:

  • A flight log with no GPS fix. The indoor run R-0936 shows the anchor None: no GPS fix during the run, and Foxborne marks it Elapsed time only.
  • A companion clock that chrony never synchronized. Run R-0922 shows None: chrony never synchronised for both the journal and the process samples.

When it fires#

The threshold reads Anchor missing or error above 2 s. The rule warns when a source has no trustworthy anchor, or when its estimated error exceeds the ordering bound, 2.0 s by default. Above that bound, Foxborne makes no before or after claim between sources, whatever the times say.

The warning changes what the console claims about the source. For a companion clock without an anchor:

  • The journal and the process samples stay on their own clock, below a Companion clock divider that reads "Own clock. No order is claimed against the lanes above."
  • Their events get no place on the map: "No position. This event is on the companion clock, which is not aligned, so it cannot be placed on the track."
  • Order against nearby events shows No claim for them, because "The companion clock has no shared anchor with the flight log."
  • The report's Clock line reads "The companion clock is not aligned. No order is claimed between the companion and the flight log."
  • Findings on the companion's own clock get no flag in the Findings row.

Wording and evidence level#

Every finding reads Warning: ordering between sources is uncertain. It is the only rule whose wording starts with Warning. It speaks about the evidence, not about the vehicle.

What the finding does not mean#

  • The companion's events are not wrong. Events on one clock keep their order, because events on the same clock are always ordered. In INC-0139 the CUDA error came 57 ms before the core dump, on the companion's clock.
  • The other rules still run. A source on its own clock still produces findings. INC-0139's process_exit finding sits on the companion's own axis.
  • It says nothing about the vehicle. In INC-0139 the flight log stayed anchored to GPS time at ±40 ms. Only the companion's evidence lost its place on the shared timeline.

Threshold and overrides#

The rule is locked, and its Edit button is disabled. Its Enabled switch is disabled too, with the tooltip "Always on. Every ordering claim depends on it."

The scope reads All sources. The ordering bound is a setting of its own, which admins change in Settings under Time and position. The choices are 0.5 s, 1.0 s, 2.0 s and 5.0 s.

The console's hint for that setting reads "Lowering it makes more pairs unknown. Raising it is recorded in every report produced afterwards."

Aligning a clock by hand#

An engineer can place an unanchored companion clock on UTC by hand, from two events that happened at the same moment on both clocks. In INC-0139 the pair is mavlink-routerd opening the flight controller's UART and PX4 seeing the first onboard controller heartbeat on TELEM2. The proposal gives an offset of +11:03:04.916 with a bound of ±1.04 s, from the 1 s heartbeat period and the 40 ms GPS anchor.

That bound sits under the 2.0 s ordering bound, so before and after claims become possible, each marked as manual. After Apply alignment, the incident's clock chip reads Manual ±1.09 s. That is the 1.04 s bound plus 6 ms for the journal and 40 ms for the flight log.

The report lists the alignment under Limitations, with the pair it came from. Remove alignment restores the original state.

For future runs, collector 0.8.1 records SYSTEM_TIME pairs, which give companion evidence a shared anchor with the flight log. The Vehicle collectors tab tags older versions No SYSTEM_TIME.

Example finding#

In INC-0139, UAS-07 flew pass 3 of the berm line survey. chronyd on its companion logged No suitable source for synchronisation at boot, and collector 0.7.3 does not record SYSTEM_TIME. The journal and the process samples had no shared anchor with the flight log.

The incident's Activity tab records the result as a Foxborne entry: "rule clock_uncertain 1.0 flagged the companion clock: no anchor". The incident list shows the clock chip Not aligned, and the run page shows the note The companion clock is not aligned.

The investigator wrote the report's finding as unknown. perception_node crashed with a CUDA illegal memory access, but the crash cannot be placed before or after the 71 s obstacle data stall. The next check is to align the clock from the matching pair, then upgrade UAS-07 to collector 0.8 so future runs carry SYSTEM_TIME.