The symptom
BLE tags five centimetres from the antenna, powered, advertising, and whitelisted in the gateway’s configuration. The gateway received nothing, and there were no errors anywhere. A clean build, plausible code.This is the class of bug that makes embedded work hard. Software that fails loudly tells you where to look. Software that is wrong about the physical world runs perfectly and reports success.
Layer one: the application log
Over RTT, the nRF52840 reported exactly what you would hope: scanner started, Bluetooth up, scanning running. Then not one advertisement. A log can only tell you what the code thinks happened. It cannot tell you whether the antenna is connected.Layer two: the air
The agent asked for an over-the-air capture, its own decision. It configured and flashed the nRF Sniffer for Bluetooth LE firmware onto a spare dongle itself.
Strong signal, right next to the gateway. The tags were transmitting. Our receiver was deaf.
The cause
This board has a radio front end between the antenna and the chip, and it was never switched on. With it off, the antenna is effectively disconnected. The radio has to drive it, and that configuration was missing.After the fix
The agent rebuilt and flashed. Same board, same tags, same position: advertisements arrived, the dashboard showed live MAC addresses and signal strength, and the data landed on MQTT.If your board does this
- Tell the agent what is on the bench: board, probe, any spare dongle. That is what lets it reach for a capture instead of re-reading the source.
- Ask for the air before the code. On the air and not in the log is a receiver problem, not a parser problem.
- On any board with a front-end module, check its control pins are driven; the curated board knowledge carries them.
3-layer debug
The same method as a workflow, with a guided sample that needs no hardware.
CRA readiness check
Next: proving the firmware that now works, in the same session.