The wearable was already in the market, on athletes, when the reports started. Units power-cycling at random. Unreliable charging while docked. Data going missing during real competition use, which is the worst possible moment. The product was already in customers’ hands. So the two obvious answers, redesign the hardware or recall the units, were both slow and both expensive.
This is the situation nobody wants. It is also where the difference between guessing and root-cause engineering gets very real. We took this device, in exactly this state, and fixed it in firmware. No hardware redesign. No recall.
When a deployed product misbehaves, the tempting move is to chase the symptoms. Add a retry where charging fails. Add a delay where it power-cycles. Patch each visible failure as it gets reported. That road leads to firmware that is a pile of workarounds, and to a problem that keeps coming back in a new shape. We have seen products die slowly that way.
So we went after the cause instead. We stress-tested the device on purpose, to force the failures under controlled conditions, rather than wait for them in the wild. The instability traced back to electrostatic discharge. The device’s input pins did not have enough hardware filtering. And the firmware did not have the signal conditioning to reject the transients that resulted. That single cause explained everything at once: the random power cycling, the charging trouble, and even some inconsistent button behaviour that had been logged as a separate complaint. One root cause, several symptoms. That is usually the shape of these problems. It is also why chasing symptoms one by one never converges.
