# Logger dropout URL: /rules/log-dropout Flags a dropout that the PX4 logger wrote into the flight log after losing data for 50 ms or longer. It observes a hole in the log, not a fault on the vehicle. ## What it reads [#what-it-reads] The rule reads the dropout messages in the flight log. Besides topic data, a ULog file carries a dropout message, message type `O`, wherever the logger lost data. Each one holds the length of the loss in milliseconds, and Foxborne places the event on the flight log's clock. The ULog file format describes a dropout as lost logging messages. They happen when the logger cannot keep up, for example when the storage device is not fast enough. ## When it fires [#when-it-fires] A finding is produced for a dropout of 50 ms or longer. The event sits where the dropout falls in the log, and its title gives the length, for example **Logger dropout, 140 ms**. | Value | Example from INC-0133 | | -------------- | -------------------------- | | First dropout | 140 ms at 13:44:02.551 | | Second dropout | 60 ms at 13:44:09.102 | | Threshold | Dropout of 50 ms or longer | ## Wording and evidence level [#wording-and-evidence-level] Every finding reads **Observed: flight log has a dropout**. The dropout message states the loss directly, so the level is observed. A dropout inside an incident window belongs in the report's **Limitations**. The editor for that section asks for "Missing topics, dropped data, clock uncertainty and manual assumptions", one per line. ## What the finding does not mean [#what-the-finding-does-not-mean] * **The vehicle did not stop.** The data is missing from the log, not from the vehicle. Nothing in a dropout says the vehicle or its sensors stopped working. * **Topics lose samples too.** A dropout can remove samples from any topic for its length, and a long one can look like a [topic\_stall](/rules/topic-stall). The 140 ms dropout in INC-0133 is too short for that on a 10 Hz topic, whose stall threshold is 500 ms. * **It does not say which data was lost.** The dropout message carries a length, not a list of topics. * **It does not give the cause.** In INC-0133 the report traced the dropouts to the SD card's write rate under a high-rate logging profile. That conclusion is the engineers', not the rule's. * **Collector drops are a different thing.** When the companion collector's spool budget fills, it drops the oldest low-priority samples and writes a lost-data marker. The **Vehicle collectors** tab counts those under **Dropped**, and they never touch the flight log. The example dataset shows both kinds on one vehicle. UAS-05 carries the INC-0133 logger dropouts, and its collector row shows 1,204 dropped samples after its spool budget filled on 25 Sep. Only the first kind produces this finding. ## Threshold and overrides [#threshold-and-overrides] The threshold reads **Dropout of 50 ms or longer**, applied to **All vehicles**. Shorter dropouts stay in the log and produce no finding. A change under **Rules** with **Edit** saves as `log_dropout 1.1`, and findings already produced keep version 1.0 and its threshold. See [Thresholds, scopes and overrides](/rules/configure). ## Example finding [#example-finding] In INC-0133, UAS-05 ran a high-rate logging test on Pad A. The flight log recorded dropouts of 140 ms at 13:44:02.551 and 60 ms at 13:44:09.102, 6.551 s apart. The **Findings** row labels the finding **Logger dropout**. The report records that the dropouts appeared once the logging profile included high-rate IMU topics, and that the SD card's write rate saturated. Moving to the default logging profile fixed it. The report is approved, and the incident is closed. The report keeps the two parts apart. The rule saw holes in the log, and the engineers found why. ## Related [#related] * [topic\_stall](/rules/topic-stall) flags silences in single topics, which a dropout can mimic. * [PX4 ULog](/collect/formats/px4-ulog) describes the flight log sections Foxborne reads. * [Check a run](/investigate/runs) shows the import job and the topics a flight log contains.