3 BLE Sniffer Tools Every Embedded Developer Should Know

BLE packet capture displayed in Wireshark alongside an nRF sniffer dongle on a developer workbench

Your firmware logs say everything’s fine. The BLE stack reports a successful advertisement. Your connection parameters look correct. But the phone sitting 2 feet away can’t find your device. You’ve been staring at printf output for an hour, and it’s all green. Where’s the bug?

It’s probably not in your code. It’s in the gap between what your stack thinks it transmitted and what actually went over the air. You can’t see that gap with on-chip logs. You need a BLE sniffer: dedicated RF hardware that captures raw packets off the 2.4 GHz band and shows you exactly what’s happening. The BLE debug tool that turns a black box into a glass box.

Here’s the thing that trips up developers the first time: you can’t sniff BLE with a standard Bluetooth adapter. Wireshark alone won’t do it. You need purpose-built capture hardware. Once you know that, the question becomes which hardware, which software, and how much to spend.

Here are 3 bluetooth sniffer tools, ranked from cheapest to most powerful, with enough detail to pick one and start capturing packets today.

How to Evaluate a BLE Packet Sniffer

Before the tools themselves, here’s what actually matters when choosing:

  • Hardware cost and availability. Can you order it today? For under $50? Under $500?
  • Software ecosystem. Does it plug into Wireshark? Is it cross-platform?
  • Protocol coverage. BLE 4.x only, or does it handle BLE 5 features like coded PHY and extended advertising?
  • Setup friction. How many steps from unboxing to first captured packet?
  • Connection following. Can it track a connection after the initial advertisement exchange, or does it only see ads?

Here’s how the 3 tools stack up:

| Criteria             | nRF Sniffer    | TI SmartRF       | Ellisys       |
|----------------------|----------------|-------------------|---------------|
| Hardware Cost        | ~$10-15        | ~$20-50           | $5,000+       |
| Software Cost        | Free           | Free              | Included      |
| BLE 5.x Support      | Yes (5.0+)     | Limited           | Full          |
| Wireshark Integration | Native plugin  | Manual export     | Own software  |
| Setup Difficulty     | Easy           | Moderate          | Easy          |
| Connection Following | Yes            | Yes               | Yes (multi)   |
| Best For             | Most devs      | TI-ecosystem devs | Professional  |

Tool #1: nRF Sniffer for Bluetooth LE (Nordic Semiconductor)

This is where 90% of you should start. The nRF sniffer is the default recommendation unless you have a specific reason to pick something else.

Hardware: You need an nRF52840 Dongle (PCA10059). It’s available from Mouser, Digikey, and Amazon for roughly $10 to $15. If you’ve ever worked with a Nordic dev kit, you might already have one in a drawer. Once flashed with Nordic’s sniffer firmware, it becomes a dedicated BLE packet sniffer.

The software stack has three pieces that work as a chain. The sniffer firmware runs on the dongle and handles the actual RF capture. A Python extcap script sits in the middle, bridging the dongle to Wireshark. Then a Wireshark plugin dissects the incoming BLE packets. Firmware talks to script, script talks to Wireshark. The Wireshark BLE integration is genuinely good: advertising PDUs get color-coded differently from data PDUs, and the protocol dissectors break every field down to the bit level.

Setup, condensed to 4 steps:

  1. Flash the nRF Sniffer firmware onto your dongle (Nordic provides a pre-built hex file).
  2. Install the Wireshark plugin and the Python extcap script into your Wireshark directories.
  3. Open Wireshark, select the nRF Sniffer interface from the capture list.
  4. Hit capture. You’re sniffing.

Nordic’s official setup guide covers the details. Budget about 30 minutes the first time, mostly spent on Python dependencies (which can be finicky on Windows, fair warning).

Strengths: Cheapest viable option on the market. BLE 5 support for 1M and 2M PHY. Wireshark’s full filtering engine at your disposal. Active community on Nordic’s DevZone forum means someone’s probably already hit whatever issue you’ll run into.

Limitations: It’s a single-radio device, so it captures one channel at a time. During an active BLE connection, packets hop across 37 data channels. The sniffer firmware follows along as best it can, but it will miss some packets during channel hopping. For most debugging, that’s perfectly fine. If you need packet-level timing analysis or compliance testing, though, you’ll want a multi-channel tool.

Pro tip: Use the Wireshark display filter btle.advertising_address == aa:bb:cc:dd:ee:ff (substituting your device’s address) to isolate your device’s traffic from the noise. In a busy office, you’ll see dozens of BLE advertisers. Filtering is essential.

Tool #2: TI SmartRF Packet Sniffer 2 (Texas Instruments)

A solid alternative if you’re already building on TI silicon.

Hardware options: The older CC2540 USB dongle handles BLE 4.x and is cheap (under $30 on various distributors), but it’s aging. The CC26x2 LaunchPad supports BLE 5.x and doubles as a development board, which is nice if you’re prototyping on TI’s platform anyway. That’ll run you $30 to $50.

Software: TI’s SmartRF Packet Sniffer 2 is a standalone capture application. It works well enough, but the workflow is clunkier than nRF Sniffer’s native Wireshark integration. You can export captures to .pcap files and open them in Wireshark after the fact, but there’s no live-streaming into Wireshark’s UI. That two-step process adds friction the nRF Sniffer doesn’t have.

The big limitation: Windows only. If you’re on Linux or macOS, this tool is off the table without a VM. For embedded developers who live in Linux, that’s a dealbreaker.

Best for: Teams deep in the TI ecosystem. The sniffer tool’s UI maps well to TI’s terminology and register conventions, and staying in one vendor’s toolchain has real value when you’re debugging CC2640 or CC2652 firmware.

Pick this if: You already own a CC26x2 LaunchPad, or your company has standardized on TI tools.

Tool #3: Ellisys Bluetooth Tracker / Analyzer

This is the professional-grade bluetooth analyzer. I’m including it so you know what exists at the top end, even if you won’t buy one this quarter.

Hardware: Ellisys makes dedicated capture hardware (the Bluetooth Tracker, Vanguard, and Explorer models). These are purpose-built RF capture devices with multiple radios. That’s the key difference: simultaneous multi-channel capture.

What that means in practice: Where the nRF52840 dongle listens on one channel at a time, an Ellisys unit captures all 40 BLE channels simultaneously. Every packet, every channel hop, every timing relationship, all recorded with nothing missed.

Software: Ellisys Bluetooth Analyzer is proprietary and purpose-built. It’s far more powerful than Wireshark for BLE-specific analysis: protocol compliance checks, sequence diagrams, error detection, and coexistence analysis with Classic Bluetooth and Wi-Fi.

Cost: Pricing starts above $5,000. For daily firmware debugging, it’s overkill.

Pick this if: Your company is pursuing Bluetooth SIG qualification. You’re hunting intermittent connection failures in production. You need to analyze interference between BLE, Classic, and Wi-Fi on the same product. If any of those apply, an Ellisys pays for itself quickly in engineering hours saved.

What a Captured BLE Packet Looks Like

Having a sniffer is step one. Reading what it shows you is step two. Here’s the stripped-back structure of a BLE advertising packet:

| Preamble | Access Address | PDU Header | Payload (AdvA + AdvData) | CRC |
| 1 byte   | 4 bytes        | 2 bytes    | 6 + 0-31 bytes           | 3 B |

In Wireshark, this gets fully dissected. You’ll see individual fields: Advertising Address, AD Type, AD Length, the actual service UUIDs, manufacturer-specific data, and TX power level.

A practical example: if your phone can’t discover your device, filter for btle.advertising_address == aa:bb:cc:dd:ee:ff and check whether ADV_IND packets are actually present. Then verify the flags byte and service UUIDs match what your phone app expects. Nine times out of ten, the bug is a mismatched service UUID or a missing flags field, and you’ll spot it in 30 seconds flat.

Wireshark filter cheat sheet:

| Filter                             | What It Shows                         |
|------------------------------------|---------------------------------------|
| btle                               | All BLE packets                       |
| btle.advertising_address == XX:... | Packets from a specific device        |
| btatt                              | ATT protocol (GATT operations)        |
| btle && !btle.adv                  | Data channel packets only             |
| btsmp                              | Security Manager Protocol (pairing)   |

Packet interpretation is a deep topic on its own. If you’re building BLE devices that transmit custom data through Hubble’s network, their custom payload guide covers how payload structure maps to what you’ll see in a sniffer.

The Decision Tree 

Do you need multi-channel capture or SIG qualification testing?
  YES → Ellisys Bluetooth Analyzer
  NO  → Are you building on TI CC26xx silicon?
          YES → TI SmartRF Packet Sniffer 2
          NO  → nRF Sniffer + Wireshark (start here)

For most of you, the answer is the nRF52840 dongle. Order one today. The $12 you spend will save you hours of guessing at BLE behavior you can’t see.

Everything you learn with the nRF Sniffer transfers directly to any other tool: Wireshark filters, PDU structures, channel behavior. If you later move to an Ellisys for qualification work, you’ll already know what you’re looking at. And if your BLE devices need to communicate through infrastructure you don’t control, like satellite or terrestrial networks, understanding the advertising packet structure at the raw level becomes even more valuable.

Go order the dongle. Flash it. Capture your first packet. Once you’ve seen your own device’s advertisements dissected field by field in Wireshark, you’ll wonder how you ever debugged BLE without it.

Hubble Network connects BLE devices directly to satellites—no gateways, no extra hardware. See how it works →