Skip to content
Docs
foxborne.comRequest a pilot

Topic stall

Flags a logged uORB topic that goes silent for five times its usual interval. It observes that the flight log stopped getting samples, not which link in the chain stopped sending them.

Rule referenceMarkdown
On this page7
topic_stallv1.0On by default
Detects
A logged uORB topic stops updating at its expected rate.
Threshold
No sample for 5 times the median period
Reads
Flight log
Report wording
Observed: topic stopped updating

What it reads#

The rule reads the uORB topics in the flight log, where each sample carries a timestamp in microseconds since boot. For each topic, the rule takes the median interval between samples as its usual rate. It then watches for a silence far longer than that.

In the example dataset the topic that stalls is obstacle_distance, which comes from the companion computer. perception_node streams MAVLink OBSTACLE_DISTANCE at 10 Hz, and PX4's MAVLink receiver turns each message into an obstacle_distance sample. PX4 stamps that sample with its own clock when the message arrives, so a stall means messages stopped reaching PX4.

When it fires#

A finding is produced when a topic has no sample for 5 times its median period. For obstacle_distance at 10 Hz the median is 100 ms, so the rule fires after 500 ms of silence. The event sits on the last sample before the silence.

ValueExample from INC-0142
Last sample14:32:04.079
Median period before100 ms (10 Hz)
Next sample14:32:11.604, 7.525 s later
Stall threshold5 times the median period

The finding's title gives the silence: Last obstacle_distance sample before a 7.5 s stall. On the timeline, the flight controller lane marks it No obstacle_distance for 7.5 s.

Wording and evidence level#

Every finding reads Observed: topic stopped updating. The flight log shows the missing samples directly, so the level is observed.

What the finding does not mean#

  • It does not say which link stopped. The publisher, the companion's router and the serial link to the flight controller all sit in the chain. In INC-0142 the publisher was killed and the router stopped within 73 ms of the last sample, and either could explain the silence.
  • A logger dropout looks the same. When the logger loses data, samples go missing from the log for the length of the loss. Check for a log_dropout finding at the same time.
  • Its order against companion events can be unknown. In INC-0142 the last sample and the kernel's kill line sit 39 ms apart, inside their 46 ms combined bound. In INC-0139 the companion clock had no anchor, so no order is claimed at all.
  • A topic that was never logged cannot stall. The run page's Flight log topics panel lists an expected topic that is missing as Not logged.

Threshold and overrides#

The threshold scales with each topic's own rate. At 10 Hz it comes to 500 ms, and for a topic at 1 Hz it would come to 5 s. The scope is All vehicles.

Change the threshold under Rules with Edit. The rule saves as topic_stall 1.1, and findings already produced keep version 1.0 and its threshold. See Thresholds, scopes and overrides.

Example finding#

In INC-0142, UAS-04 was on the return leg of Route Iron. The last obstacle_distance sample came at 14:32:04.079 and the next at 14:32:11.604, 7.525 s later. The Findings row labels it obstacle_distance stalled.

The kernel's kill line at 14:32:04.118 is 39 ms from the last sample. That is inside the 46 ms combined bound of the flight log and the journal, so the report lists the pair under Limitations. It claims no order between them.

In INC-0139, UAS-07 went without obstacle_distance for 71 s, from 14:17:05.310 to 14:18:16.540, and held position. perception_node crashed on the companion, but the companion clock was never synchronized, so the crash cannot be placed before or after the stall. The report writes its finding as unknown and keeps the question open: did the stall start before the crash?