It paired fine on the bench. In the field it dropped every couple of hours, never at a useful moment, never reproducibly. We spent three weeks on it. Here are the four causes in the order we found them — and the last one wasn’t the Bluetooth module‘s fault at all.
The sleep clock drifted
A Bluetooth module sleeps between connection events and wakes on a 32 kHz clock. If that crystal is off by a few hundred ppm, the radio wakes late and misses its window; the peer waits, gives up, and the link drops. It looks random, but it tracks temperature. We found one that only failed above 40 °C, which is exactly why the lab never saw it. Put the unit in a heat chamber before you believe any disconnect is truly random.
The rail sags when it transmits
Transmit is a current spike — tens of milliamps in a couple of microseconds. If the LDO, the trace, or the decoupling can’t hold the rail up, VDD dips and the Bluetooth module browns out or resets outright. The tell is that drops cluster when traffic is heaviest, which people usually misread as interference. Scope the rail during a TX burst, not while idle. We fixed one of these by moving a capacitor four millimeters.
Connection parameters nobody agreed on
The host asks for a connection interval the module can’t honor, or sets a supervision timeout too short for a noisy room. In a quiet lab everything is fine; add a few Wi-Fi access points and a microwave and you miss enough consecutive events to time out. Let the peripheral request first, and stop hard-coding 7.5 ms just because a datasheet once called it efficient. A link that survives a crowded room is worth more than a fast one that doesn’t.
The antenna is buried in metal
Keep-out area ignored, the module sitting over a solid ground pour, or an enclosure with a metalized window. Range collapses to a meter and the link thrashes right at the edge of it. This one is obvious on a VNA and completely invisible on a bench two feet from the laptop, which is why it survives late into a project.
The one that wasn’t the module
We chased a “Bluetooth module problem” for a week that turned out to be the host MCU holding the module in reset during an I2C bus lock. The Bluetooth module had been healthy the entire time. Now we read the module’s own reset reason before we believe the host’s story about what happened.
How we debug it now
A sniffer on the air, a scope on the rail, a heat chamber for anything described as random, and the module’s own diagnostics before anyone’s opinion. Most “keeps disconnecting” tickets turn out to be power or clock, not RF — which is lucky, because those are the cheap fixes.
What I’d tell you first
Check the rail and the sleep clock before you touch the antenna or the stack. Nine times out of ten they’re the cheap fix, and the antenna is the expensive thing everyone reaches for first.
