Every major silicon vendor shipping a UWB chip in 2026 (Qorvo, NXP, Samsung LSI, and others) will tell you their development kit includes everything you need to bring up a ranging stack.
What the kit doesn’t include is a way to see what the radio is actually transmitting. That gap is the reason UWB firmware teams spend weeks on bugs that would take hours to diagnose if the frames were visible. It’s also why the question “which UWB sniffer should we buy?” has no simple answer: until recently, the honest answer was that no purpose-built option existed.
That’s changing. This guide covers what to evaluate when choosing a UWB sniffer or protocol analyzer: the capabilities that actually matter for FiRa, CCC Digital Key, and IEEE 802.15.4z development, and maps each to the use cases where they’re non-negotiable. The UWB Alliance currently tracks hundreds of millions of UWB-enabled devices shipped annually, and that installed base creates a long tail of firmware teams who need proper debugging tools, not workarounds.
Why UWB debugging is different from every other wireless stack
Understanding what to look for in a UWB sniffer starts with understanding why the standard approach (SDR + Wireshark, dev kit logs, logic analyser) doesn’t work here.
There’s no carrier. UWB operates on impulse radio: bursts of extremely short pulses spread across a wide frequency band. A generic RF sniffer that looks for a carrier to lock onto captures nothing. A UWB sniffer must correlate pulses against the correct preamble code, and if the preamble code is wrong, zero frames are captured, with no indication that capture failed.
The session is negotiated before the session. FiRa, CCC Digital Key, and Aliro all exchange UWB session parameters out-of-band (over BLE or CAN) before the first UWB packet appears on air. A sniffer that only captures UWB frames arrives too late: it sees frames it can’t interpret because it missed the handshake that defined the channel, STS mode, preamble code, and session keys.
The waveform is the ciphertext. IEEE 802.15.4z introduced the Scrambled Timestamp Sequence (STS): AES-128 applied to the UWB waveform itself, not just the payload. In STS modes 1, 2, and 3, the signal as received from the antenna is encrypted. A tool that can receive the frames but can’t decrypt the STS reports meaningless timestamps, and ranging depends entirely on those timestamps.
PHY parameter space is enormous. Channel (1–9), pulse repetition frequency, preamble code (1–32 for HRP UWB), SFD type, data rate, STS mode, and preamble length multiply into millions of configurations. A UWB sniffer needs to either know the configuration or include a smart scan mode that sweeps realistic combinations across multiple probes simultaneously.
Ranging frames are short. A UWB ranging round lasts 150 µs to 2 ms. Miss one synchronisation event (a transmit-side API call that runs too late, a scheduler preemption, and the round is lost entirely. Firmware logs report “ranging timeout”; the frame capture shows exactly which packet was missing.
What most UWB development teams use today
Before evaluating analyzers, it helps to name what teams are actually using and where each approach breaks down.
Vendor SDK logs expose application-layer events: ranging distance outputs, session state transitions, error codes. They don’t show frame content, STS status, CIR data, or the OOB exchange that set up the session. A ranging failure logged as “session terminated” could be a session configuration mismatch, a key desynchronisation, a timing error, or a PHY problem. The log can’t tell you which.
Oscilloscopes and spectrum analysers show that the radio is transmitting: signal energy on the expected band at the expected times. They cannot decode 802.15.4z frames, correlate preamble codes, or produce readable protocol data.
Generic SDRs (HackRF, USRP variants) can capture raw RF in the UWB band, but they lack the real-time preamble correlator required to detect UWB frames. The resulting IQ data contains UWB traffic in principle; in practice, converting it to protocol-level information requires custom DSP work that takes longer to build than the underlying firmware.
Wireshark with 802.15.4 plugins works well for Zigbee and Thread. It does not understand UWB PHY framing, STS modes, or protocol-layer decoders for FiRa, CCC, or Aliro sessions.
No silicon vendor currently ships a dedicated UWB sniffer. Debugging UWB without one means correlating logs from at least two devices, timestamps from the host system, and educated guesses about what happened at the radio layer.
Seven criteria for evaluating a UWB sniffer
These are the capabilities that distinguish a UWB sniffer that can actually close a debugging session from one that adds complexity without insight.
1. PHY-layer preamble capture
The foundation. The tool must correlate the incoming waveform against the correct preamble code and SFD configuration before any higher-layer decode is possible. This means the capture hardware is designed for UWB physics, not adapted from a generic RF platform. Supporting channels 5 and 9 (the primary FiRa channels) and the legacy channel set (1–6) covers the deployed installed base.
2. Protocol decoder coverage for IEEE 802.15.4z and application layers
Decoder coverage maps directly to which products the UWB sniffer can support.
IEEE 802.15.4z is the PHY/MAC foundation: all FiRa, CCC, and Aliro traffic runs on 802.15.4z frames. A sniffer that only decodes the base 802.15.4z layer shows you the frame structure but not the application-layer session data that determines why a ranging session failed.
Application-layer decoders needed:
- FiRa: DS-TWR, SS-TWR, OWR for AoA, DL-TDoA, UL-TDoA, and session lifecycle. Covers smart home, access control, and consumer electronics use cases.
- CCC Digital Key: dynamic STS, multi-anchor O2M TWR, frame hopping, and automatic key extraction from CAN. Required for automotive passive-entry development and HIL bench work.
- Aliro: the Car Connectivity Consortium’s access-control successor to CCC for non-vehicle applications. Spec evolves quickly; check whether dissector updates are included.
- omlox: the open UWB standard for industrial RTLS from the omlox consortium, covering UL-TDoA and DL-TDoA for warehouse and factory positioning.
- IEEE 802.15.4ab: the next-generation amendment adding radar/sensing capabilities, Wake-Up Radio, and MMS ranging. Production silicon is arriving; decoder availability now signals which vendors are tracking the standard in real time.
3. Out-of-band session parameter capture
This is the criterion most often missed in initial evaluations. If your product uses FiRa, CCC, or Aliro, the UWB session parameters (channel, preamble code, STS key, session ID, ranging configuration) are distributed over BLE or CAN before the first UWB frame. A UWB sniffer that captures UWB only is blind from the start of every session.
The minimum requirement is a BLE companion that observes the out-of-band exchange using a provided Link Encryption Key, capturing the BLE advertisements and characteristics that carry UWB session setup. For CCC Digital Key on automotive platforms, a CAN adapter is required to extract session parameters from the vehicle network. Manual configuration via CLI or YAML covers lab scenarios where the application is on a test jig.
4. STS decryption and key injection
For development and validation of products using IEEE 802.15.4z STS modes 1–3, the sniffer must be able to decrypt the STS to see full frame content and accurate timestamps. This requires key injection: providing the session AES key to the UWB sniffer, which then generates the expected STS sequence and uses it to validate and decode captured frames.
STS integrity detection without the key is a secondary capability that allows the sniffer to flag authentication failures (mismatched STS) even when it can’t decrypt. This is useful for verifying that a production device correctly seeds its STS counter without sharing the session keys.
5. Wireshark integration with named protocol fields
Wireshark display filters are the standard interface for protocol engineers doing packet analysis. A UWB sniffer that delivers a pcap file is a good start; one that delivers a Wireshark extcap plugin with custom dissectors and named protocol fields, so that fira.session_id, ccc.hop_channel, or uwb.ranging_distance appear as filterable fields in the Wireshark GUI, which changes the debugging workflow qualitatively. Named fields mean filter expressions work natively, coloring rules can highlight specific session events, and statistics can be computed per session directly from the UI.
The extcap interface also enables live streaming: the sniffer feeds frames into Wireshark in real time rather than requiring a capture file to be offloaded first.
6. CI/CD and automation readiness
UWB protocol testing in a hardware-in-the-loop or pre-certification environment requires the UWB sniffer to be scriptable. A REST or Python API that exposes capture control, filter rules, and frame output as schema-stable JSON allows the sniffer to function as an instrument inside an automated pipeline, not just a bench tool operated by hand. Pass/fail rules that run against the live capture stream and flag specific protocol violations make this a testing tool, not just an observation tool.
Multi-node time-synchronised capture (running multiple sniffer units with synchronised timestamps) is required for TDoA positioning validation, where the timing offset between anchors is the measurement.
7. Form factor options
A single hardware design that covers all deployment scenarios is worth checking explicitly:
- Desktop USB for lab bring-up: host-powered, small footprint, no external power required
- Battery-powered portable with on-device display for field troubleshooting: no laptop required, captures to storage, touchscreen review
- 1U rack-mount with REST API and external RF connectors for automated test benches and HIL environments
The important detail is whether all three form factors run the same firmware and protocol decoders, so a configuration established on the lab unit transfers directly to the production bench.
UWB sniffer options compared
| Capability | Dev kit + vendor logs | Generic SDR | Purpose-built UWB sniffer |
|---|---|---|---|
| PHY preamble capture | Vendor tools only | No (no preamble correlator) | Yes: channels 1–9, all STS modes |
| IEEE 802.15.4z decode | No | No | Yes: base PHY/MAC layer |
| FiRa session decode | No | No | Yes: DS-TWR, SS-TWR, OWR, TDoA |
| CCC Digital Key decode | No | No | Yes: dynamic STS, frame hopping, CAN |
| Aliro decode | No | No | Yes (dissector updates included) |
| omlox / RTLS decode | No | No | Yes |
| OOB session capture | No | No | Yes: BLE + CAN + YAML/CLI |
| STS decryption | No | No | Yes: key injection, integrity detection |
| Wireshark integration | Vendor-specific, limited | No | Yes: extcap, named fields, live stream |
| CI/CD integration | No | No | Yes: REST/Python API, JSON, pass/fail |
| Form factors | Lab only | Lab only | Desktop, portable, rack |
| Time to first capture | Hours (SDK setup) | Weeks (DSP build) | Days (configure + deliver) |
Matching the analyzer to your use case
Automotive digital key (CCC Digital Key): The mandatory capabilities are the CCC decoder with dynamic STS and frame hopping support, a CAN adapter for in-vehicle session parameter extraction, and the multi-anchor session view. The CCC Digital Key specification defines the session lifecycle in detail; the UWB sniffer’s decoder must track it in full to diagnose the frame-hopping failures and key-rotation events that are the most common sources of production bugs.
Consumer electronics and smart access (FiRa): The Apple Nearby Interaction framework exposes UWB ranging to iOS developers through FiRa-compatible sessions. Most consumer UWB products target FiRa SS-TWR, DS-TWR, or OWR for AoA. The required capabilities are FiRa decoder with session lifecycle, BLE companion for OOB session capture, and STS mode 1 decryption. Named-field Wireshark filters for FiRa parameters allow session comparison across devices quickly.
Industrial RTLS (omlox, TDoA): Multi-node time-synchronised capture is non-negotiable for positioning systems using TDoA. The UWB sniffer must support multiple synchronised probes (one per anchor position) with timestamps accurate enough to resolve the sub-nanosecond TDOA differences that the localization algorithm uses.
R&D and protocol research (IEEE 802.15.4z/ab): PHY scanner mode (sweeping channel and preamble code combinations across multiple probes simultaneously) is the key capability for initial bring-up. For 802.15.4ab work, roadmap readiness determines how early the tool becomes useful.
Pre-certification and HIL bench: REST/Python API with pass/fail rules and JSON output is the baseline. The rack-mount form factor with external RF connectors and headless operation supports the physical HIL bench configuration.
needCode’s Modular UWB Sniffer
The only purpose-built UWB sniffer currently available is needCode’s Modular UWB Sniffer. Its decoders cover IEEE 802.15.4z (base capture), FiRa (all ranging modes), CCC Digital Key (including dynamic STS and CAN key extraction), Aliro (with dissector updates as the spec evolves), and omlox for industrial RTLS. An IEEE 802.15.4ab decoder covering MMS ranging, Wake-Up Radio, and SENS packets is on the roadmap.
The out-of-band capture coverage is a BLE observer (using a provided LTK), a CAN adapter, and manual YAML/CLI configuration, with bespoke adapters for proprietary transports available as a professional service. STS decryption uses key injection for dynamic STS (CCC, Aliro) and includes integrity detection for sessions where keys aren’t available. The Wireshark integration is an extcap plugin with custom dissectors (named fields so display filter expressions work natively) plus live streaming. The REST/Python API exposes capture, filtering, and automated pass/fail for CI/CD and HIL integration.
Three form factors run the same firmware and decoder stack: desktop USB, battery-powered standalone with touchscreen, and 1U rack-mount with REST API and external RF connectors.
The tool was built during an 8-year partnership inside Qorvo R&D, developed to support production firmware bring-up across nine UWB hardware platforms before it existed as a product. needCode is a UWB Alliance member and has participated in five or more FiRa interoperability test events across two continents. Configuration is quoted within five business days; a tested unit is delivered in four to eight weeks.
needCode builds the Modular UWB Sniffer, the only purpose-built UWB protocol analyzer for FiRa, CCC Digital Key, Aliro, omlox, and IEEE 802.15.4z development. The tool was developed across eight years of production UWB firmware work at Qorvo and validated at five or more FiRa interoperability test events across two continents. If your team is currently debugging UWB ranging sessions from vendor SDK logs and oscilloscopes, we are happy to talk about what a configured sniffer would enable for your specific protocol stack and use case.
Book a free discovery call or get in touch
Frequently asked questions
A UWB sniffer (also called a UWB protocol analyzer) passively captures, decodes, and displays IEEE 802.15.4z ultra-wideband radio traffic as human-readable protocol frames. Unlike a standard spectrum analyser, it correlates the UWB preamble code, decodes the MAC layer, and applies protocol-specific dissectors for FiRa, CCC Digital Key, or Aliro sessions. The output is typically displayed in Wireshark with named protocol fields. A full-featured UWB sniffer also captures the BLE or CAN exchange that sets up UWB session parameters before the first UWB packet.
It depends on your development stage and the STS modes your product uses. Teams doing initial PHY bring-up in STS mode 0 (no STS) or with static keys can operate without STS decryption. STS decryption via key injection becomes essential for CCC Digital Key (dynamic STS with keys from the vehicle CAN network) and Aliro (keys from BLE OOB exchange). A UWB sniffer that supports STS integrity detection without full decryption still provides value: it can flag when the STS counter is desynchronised without the key material, which covers one of the most common IEEE 802.15.4z ranging failures.
Generic SDRs don’t include the preamble correlator required to detect UWB frames. UWB pulses are spread across a wide frequency band, and without correlating against the exact preamble code and SFD configuration, the received signal is indistinguishable from noise. Building a preamble correlator in software on a generic SDR platform requires custom DSP work that typically takes longer to develop than the firmware it’s meant to debug.
FiRa sessions use BLE for out-of-band parameter exchange and focus on ranging mode, session lifecycle, and STS mode. The key capture requirement is a BLE observer. CCC Digital Key adds CAN-based key extraction (the session AES key is distributed over the vehicle’s CAN bus), dynamic STS with defined key rotation intervals, multi-anchor orchestration, and frame hopping across predefined channels. CCC debugging requires the UWB sniffer to have a CAN adapter and to track the hopping sequence across multiple frames.
Yes, with a REST or Python API that exposes capture control and frame output. The 1U rack-mount form factor is designed for automated bench environments, with external RF connectors for integration into an RF-controlled test enclosure. Pass/fail rules that execute against live frame captures and output schema-stable JSON allow the sniffer to function as a binary gate in a CI pipeline: a protocol violation detected in a commit’s test run produces a clearly labelled failure, not just a timing-out test case.
A configured needCode sniffer is quoted within five business days and delivered as a tested unit in four to eight weeks. Building equivalent capability in-house (preamble correlator, Wireshark dissectors for FiRa and CCC, BLE companion, CAN adapter) is typically an 18–24 month project for a team with RF engineering and protocol expertise. The difference is a year or more of engineering time converted into time-to-first-capture.
Further reading
- Basics of UWB Indoor Location Systems (Indoor RTLS): foundational guide to UWB-based positioning, covering TWR, TDoA, anchor topology, and accuracy trade-offs. Relevant context for buyers evaluating omlox and RTLS sniffer configurations.
- IEEE 802.15.4ab vs IEEE 802.15.4z: What’s Changing in Ultra-Wideband: needCode’s e-book covering the 802.15.4ab amendment, including radar/sensing, MMS ranging, Wake-Up Radio, and what changes for developers moving from 802.15.4z.
- Automated Testing and CI/CD for Embedded Wireless: how the UWB Sniffer plugs into HIL benches and CI pipelines via REST API. The testing infrastructure context for buyers evaluating the rack-mount and automation use cases.
- Dedicated Development Center for RF Solutions: Qorvo Case Study: the Qorvo partnership behind the sniffer, covering 30 FTEs, 9 hardware-platform bring-ups, and 5+ years of development. The context that explains where the tool’s decoders came fro
