Skip to main content
The hardest BLE bugs hide between the layers: the app log looks fine, but a notification never arrives, a reconnect drops, or a flow stalls. Adsum correlates all three, so you see exactly where it broke: the app log (what your firmware prints), the HCI bus (what the host told the controller, decoded), and the over-the-air radio (what actually hit the air, on a standard nRF52840 sniffer dongle). Here it is catching a real one, on a production gateway build: clean logs, a tag five centimetres from the antenna, and nothing received.
The bug, the capture, and the fix, written up in full as chapter two of the gateway build.
App logSays scanning. Reports no errors.
HCI busSays scan enabled. Nothing delivered up.
Over the airThirty-six advertisements captured, plainly there.

So the break is between the air and the chip. The radio front end was never switched on. No single layer could have told you that.

​
Try it with no hardware

The fastest way to see it is the guided sample run, on a bundled sample with nothing of your own open:
1

Open the guided 3-layer debug

From the home. No board, no key, no project of your own needed.
2

Watch a real bug surface across the layers

A real one-directional BLE bug: blind on the app log, a gap on the HCI bus, confirmed over the air, landing on the one-line fix.
3

Take it live (optional)

The same debugging runs on your own nRF boards. The guided run covers the sniffer-dongle setup, hardware steps included.
Another bug it catches the same way: BLE notifications that work once, then go silent after every reconnect, usually one missing call, settings_load() after bt_enable(), visible on the bus before it ever looks like a notification bug. It bridges into CRA readiness too: once a BLE flow makes sense, check the same build’s posture in one click.

​
Scope

  • Available for Nordic nRF BLE today (CONFIG_BT detected). Beyond BLE is on the roadmap.
  • The agent narrates the decode and proposes the fix; the last word is yours.