Fleet Reset Diagnosis

What this asks

Devices across the fleet reboot with boot (brown-out & hard reset). A brown-out is a momentary collapse of the supply rail, so the obvious suspects are battery and radio current draw — and the obvious confounder is firmware, since a reset that only happens on one build is a software problem wearing a hardware costume. This page tests all three against every device that reported in the window.

The verdict

The 11.3.1 Notecard rollout

The whole fleet was moved to notecard-11.3.1.17696 on 2026-08-26 19:00 UTC. Taking a DFU reboots the device, so each unit’s own update reboot is excluded below — counting it would make the rollout look like a reset spike.

Resets per day

Fleet-wide count, with the number of devices reporting that day as the denominator. Bars marked with a dot are days a host-firmware rollout landed.

Host firmware

Resets per device-day, by the host build each device was running.

Controlling for location

Most units on the old build sit in the Boulder lab, so the raw lab-versus-field gap is confounded. This splits each build by location: the comparison that matters is lab on one build against lab on the other, same bench, same power.

Notecard firmware

The boot message quotes the Notecard build number, so it is the natural first suspect.

Cellular signal and battery

Correlation of each device's reset rate against its own median signal and supply measurements. These come from session records, which Notehub retires sooner than health records — see the window note above.

Voltage at the moment of reset

Every device

Sorted by resets. Lab is anything whose serving tower is in Boulder.