How many logs do you need before a pattern emerges?

Usually three. The first event is a data point — could be transient, could be the start of a trend. The second event confirms the same symptom recurring in similar conditions, which is the actual pattern signal. The third investigation is the swap-and-fly test that isolates the cause. Skipping any of the three risks misdiagnosis.

Why is the swap-and-fly test important?

Because the symptom in the log names the position (motor 3, channel C3) rather than the physical component. Multiple causes can produce the same position-named symptom — a worn prop, a failing ESC, a marginal motor, a loose connector. Swapping a suspected component to a different position and seeing whether the symptom follows is the only conclusive isolation test.

Does this pattern work for non-agricultural drones?

Yes. The pattern is the analytical workflow, not the operational context. Any operator running multiple identical or similar airframes can apply the same first-event / pattern-confirm / swap-and-fly sequence. Survey rigs, inspection drones, delivery drones — the workflow is identical; only the symptom and the components differ.

Could the diagnosis have been made from one log?

Probably not conclusively. One ERR Subsys=25 event has too many candidate causes to point at a specific ESC. The pattern across two logs narrows the hypothesis substantially. The swap-and-fly test converts hypothesis to confirmation. Single-log diagnosis works for catastrophic crashes where the failure is unambiguous, not for intermittent component degradation.

Is BLHeli_S more prone to desync than other ESC firmwares?

BLHeli_S in older revisions is known to desync at high throttle on some motor families. Current revisions and the successor BLHeli_32 family handle this much better; AM32 is another modern alternative. If you're seeing desync on BLHeli_S, the firmware update is the first thing to try before replacing hardware.

What's the cost of not catching this pattern early?

An ESC failure during a high-throttle moment without successful thrust-boost compensation produces uncontrolled descent. For a heavy spray drone over a field, that's a crash with lost airframe and payload, plus the regulatory and safety overhead of an incident report. The investigation cost (three flights and a 20-minute bench swap) is trivial against that risk.

How do you tell a real pattern from coincidence?

Pattern: same symptom, same conditions, same drone, repeatable. Coincidence: same symptom but different conditions, different drones, or one-off. A second occurrence with identical conditions usually rules out coincidence; if you're unsure, fly the same airframe in the same conditions deliberately and watch for the third event.

A Pattern Case Study — Catching Recurring ESC Desync in an Agri Drone Fleet

TL;DR: A pattern we’ve seen repeatedly in agricultural drone fleets is recurring ESC desync caught early via cross-flight RCOU pattern analysis. The setup: an agri spray fleet runs ten near-identical 16 kg-MTOW hexacopters with BLHeli_S ESCs. One drone starts producing ERR Subsys=25 ECode=1 events — the firmware’s Thrust Loss Check — intermittently during heavy spray runs. Reading three consecutive logs side by side identifies the problem as one specific ESC, not the airframe. Replacement, re-flight, problem solved. Below is the analytical pattern that turns three logs into a maintenance ticket. Names and identifying details are anonymised; the analytical workflow is real and reproducible.

The operational context

A mid-sized agri drone operator in northern India runs ten hexacopters across two seasonal crops. Each airframe flies 8–15 missions per day during peak season; logs are routinely uploaded to LogHat for the standard per-flight report. The maintenance philosophy is data-driven — anything the autopilot flags gets a ticket; calendar-driven service is reserved for things the autopilot can’t see.

The first signal — one log

Drone #7 returns from a spray mission. The LogHat report flags an ERR Subsys=25 ECode=1 event 14 minutes into the flight, with a matching MSG line “Potential Thrust Loss (3)”. The thrust-boost compensation engaged and the autopilot recovered, completing the mission. From this one log alone, the candidate causes are wide — mechanical disturbance, ESC desync, a brief voltage sag, a prop strike.

The standard response is to inspect the named motor (motor 3) and its prop. Visual check turns up nothing wrong. The drone flies the next day, this time without incident. A single event with no recurrence might be brushed off as a transient mechanical disturbance.

The second signal — pattern emerges

Three days later, the same drone produces another ERR Subsys=25 — again naming motor 3. This is no longer a one-off. The maintenance ticket escalates from “inspect motor 3 prop” to “cross-flight pattern analysis required”.

Looking at the two logs side by side:

Both events occurred at sustained high-throttle segments — matching spray runs where the airframe carries close to full payload mass.
Both events show RCOU.C3 saturating at maximum just before the firmware detects thrust loss.
The diagonally opposite motor (motor 6) saturates at minimum, as expected when the autopilot compensates for one motor under-delivering.
VIBE.VibeZ on both flights is within normal range (under 15 m/s²) — vibration is not the cause.
BAT.Volt during both events stays well above battery failsafe thresholds — voltage sag isn’t the cause either.

The pattern points at motor 3 specifically, at high throttle, on a healthy battery, with no vibration. That leaves ESC desync as the leading hypothesis — the BLHeli_S sensorless commutation algorithm losing track of the rotor at the throttle level where bus current is highest.

The third signal — confirmation

The fleet operator does the smart thing: rather than swap motor 3, they swap the motor 3 ESC with motor 6’s ESC. If the problem follows the ESC, ESC is the cause; if it follows the motor position, the airframe is.

The next day, drone #7 flies a spray mission. The ERR Subsys=25 fires again — this time naming motor 6. The problem moved with the ESC.

What the resolution looked like

The faulty ESC is identified by part marking and reflashed with current BLHeli_S firmware (one revision behind the latest was running). Test flight is clean. Three subsequent flights, no recurrence. The fleet operator notes the ESC’s part-marked unit for retirement at the next overhaul cycle and proceeds with the season.

Total cost of investigation: three flights and a 20-minute bench swap. Total cost of not investigating: one of those high-throttle thrust-loss events without successful compensation, on a 16 kg airframe over a crop field, with a spray load. The math heavily favours the data-driven approach.

The pattern, generalised

What made this resolution possible was the structured log analysis — the same ERR Subsys=25 event in isolation would have prompted a motor swap that wouldn’t have helped. The three steps that made it work:

Treat the first occurrence as a data point, not a verdict. Inspect what the firmware named; if nothing visible, log the event and continue.
Treat the second occurrence as a pattern emerging. Pull both logs and compare side-by-side. Identify the common conditions: same motor, same throttle envelope, same airframe state.
Treat the third investigation as the swap-and-fly test. Move suspected components and see whether the symptom moves. That isolates the faulty unit conclusively.

For an operator running a fleet of identical or similar airframes, this pattern catches faults early and conclusively. The autopilot already names the symptom; the operator’s job is to follow the symptom across enough flights to isolate the cause.

How LogHat fits into the workflow

The per-flight forensic PDF surfaces the ERR Subsys=25 event with the named motor and the matching RCOU pattern, so the first signal isn’t missed in a busy season. Cross-flight comparison — the analytical step that turns the first signal into a pattern — is something LogHat’s fleet view supports via the per-airframe timeline. The bench swap and the actual replacement are still the operator’s job, as they should be.

What we deliberately don’t do

This post is a pattern illustration, not a specific customer claim. The drone counts, mission frequencies, and ESC part markings have been anonymised; the analytical workflow above is reproducible by any operator with similar tooling. If you’re running an agri or survey fleet and seeing the same ERR Subsys=25 pattern, the steps above apply directly to your context.

When LogHat helps — and when it doesn’t

LogHat’s strength is the per-flight forensic report and the cross-flight comparison view. What we can’t replace is the operator’s judgment about whether to swap, retire, or keep flying. The data narrows the hypothesis; the engineer with the screwdriver still owns the decision.