Bluetooth OTA Updates Need a Packet Loss Stop Rule
A Bluetooth Explorer workflow for firmware teams deciding when an OTA failure is a link problem, a cache problem, or a release blocker.
Short answer: Treat an OTA update as unsafe when loss clusters around the same transfer range twice in a row. Use the rest of the workflow only if the next decision changes what you do, not because another app screen looks busy.
The Failure Window
Treat an OTA update as unsafe when loss clusters around the same transfer range twice in a row. A single dropped packet can be noise; repeated loss near the manifest, image boundary, or verification step is a product signal.
What To Capture
Log connection interval, negotiated MTU, RSSI range, peripheral battery level, firmware build, and the exact byte offset where retry starts. The useful record is not a dramatic screen recording. It is a boring table that lets another engineer reproduce the bad minute.
Cache Or Link
If service discovery changes after the firmware update, clear the GATT cache before blaming radio conditions. If the attribute table is stable and the failure moves with distance, interference, or phone model, the link is the better suspect.
Release Gate
Do not ship when three phones fail in the same offset window, when retry count climbs after the verification command, or when the device needs a power cycle to advertise again. That is not a flaky lab day; that is a support queue forming early.
OTA Debug Checklist
- Run one near-field transfer and one normal-use transfer before changing code.
- Record MTU, interval, PHY, RSSI, battery, firmware hash, and failure offset.
- Separate cache refresh tests from radio-distance tests.
- Stop after two repeated offset failures and inspect the packet window.
- Keep Bluetooth Explorer notes tied to the firmware build, not the tester's memory.
Small Questions
When is a Bluetooth OTA retry acceptable?
One retry in a noisy room is acceptable. Repeated retries at the same offset are a release signal.
Should testers clear the GATT cache first?
Only when the firmware changes services or characteristics. Otherwise cache clearing can hide the actual link problem.
What should the bug report include?
The transfer offset, phone model, OS version, firmware hash, RSSI range, and whether the peripheral advertised again after failure.