2.4GHz ISM Research
Requires: NM-RF-HAT with DIP 2 ON.
Hardware: Nordic nRF24L01+ with AT2401C PA + LNA. TX output ~+20 dBm. The AT2401C is always in the RF path — it cannot be bypassed in software.
The nRF24L01+ covers 2400–2525 MHz in 1 MHz steps (126 channels). This band is shared by WiFi (channels 1–13), Bluetooth (79 channels), Zigbee, and a wide range of proprietary protocols used in wireless keyboards, mice, game controllers, industrial sensors, and RC systems.
Steps across all 126 channels (2400–2525 MHz), measures carrier presence on each channel - a one-bit threshold detector (above approximately -64 dBm = detected, below = not detected) - and plots a real-time bar graph. Tap any bar to read the frequency and detection hit count for that channel.
Locating non-Bluetooth 2.4 GHz transmitters
WiFi and Bluetooth are easy to identify with their own scanners, but the nRF24 Channel Scan finds everything else: proprietary keyboard/mouse dongles, 2.4 GHz RC car controllers, baby monitors, wireless game controllers, and industrial telemetry links. Anything transmitting between 2400–2525 MHz appears as elevated carrier detect on the relevant channel.
Identifying nRF24L01+ protocol channels
Many consumer wireless keyboards and mice use nRF24L01+ directly (the ESB/GFSK protocol family). They typically occupy a small cluster of channels (often around ch 25, 50, 74 for common dongle implementations). The channel scan locates the active cluster before you switch to the Sniffer for packet-level capture.
Interference survey
The 2.4 GHz band is heavily contested. A channel scan during a site survey reveals which sub-bands are congested, which are clean, and whether any wideband interferers (microwave ovens, video senders) are active. Useful baseline before deploying 2.4 GHz sensor infrastructure. Note: the RPD threshold is approximately -64 dBm - signals below that level are not detected. This is a presence indicator, not a calibrated power map. For signal-level measurements use a spectrum analyser.
Pre-capture channel locking
Run the channel scan first, identify the target channel cluster, then lock the Sniffer to a specific channel for sustained packet capture. The scan saves time compared to sweeping the Sniffer manually.
Listens on a configurable channel using Enhanced ShockBurst (ESB) auto-acknowledge promiscuous mode. Captures packets and saves them to /sdcard/lab/nrf24/ in timestamped CSV files.
- Payload bytes (hex)
- Pipe address (5 bytes where detectable)
- Channel
- Timestamp
- Packet length
Wireless keyboard/mouse dongle research (MouseJack surface)
The MouseJack vulnerability class (CVE-2016-10761 and related) affects nRF24L01+-based wireless HID dongles from Logitech, Microsoft, Dell, HP, and many others. The attack surface requires first capturing packets on the dongle's channel to identify the address. CYM's sniffer is the first step: capture a packet burst triggered by a keypress, decode the 5-byte pipe address, then use that address for follow-on research.
Proprietary protocol reverse engineering
Game controllers, drones, and industrial remotes using nRF24 have completely proprietary packet structures. Capture a few hundred packets while operating the target device, then import the CSV into a spreadsheet or script to identify repeating byte patterns, counters, and checksums.
Dongle pairing capture
Many nRF24 devices perform pairing over a known "pairing channel" (often ch 0 or ch 39). Sniffing during the pairing sequence can reveal the device address and sometimes the channel-hopping parameters for the operational link.
Keystroke injection attack research
On vulnerable dongles that accept unencrypted HID reports, injecting keystrokes requires knowing the dongle's pipe address. Capture + decode is the prerequisite step. This attack class has been fully published (RFStorm/MouseJack) — CYM provides the capture capability.
Conference room full of employees, half using wireless USB keyboard/mouse combos. You open nRF24 Channel Scan and watch 126 channels light up. Three show consistent bursty activity clustered around channels 25, 50, and 74 — the classic nRF24 dongle fingerprint. You lock the Sniffer to ch 50. Thirty seconds later someone types their laptop password to unlock it. The raw nRF24 frame capture on your SD card has the pipe address and frame structure. MouseJack-compatible tools (e.g. RFStorm nrfattacker) decode the unencrypted HID reports from those frames to recover keystroke data - the CYM capture is the prerequisite step. This is the published MouseJack attack surface — the vulnerability has been public since 2016. Most organizations never pushed the dongle firmware update.
Dedicated 10-second scan for Futaba S-FHSS frequency-hopping spread spectrum RC links. Hops across the 25-channel S-FHSS hop sequence (2403, 2416, …, 2474 MHz) at 20 ms/channel, capturing the protocol's 16-byte frames.
RC link characterisation
S-FHSS is used in Futaba RC systems common in precision agricultural drones and commercial RC aircraft. Scanning lets you confirm the hop pattern is correct for a given transmitter, verify channel occupancy, and detect any frame corruption during range testing.
Protocol compliance verification
Verify that a Futaba-compatible receiver is hopping in sync with its transmitter and that all 25 channels show consistent signal levels — uneven channel activity indicates RF interference or a misconfigured transmitter module.
Range and link quality testing
Run the S-FHSS analyser while walking away from the transmitter. Dropped frames begin appearing in the log before the link fully fails, giving you a practical range estimate and link margin.
Carrier-detect mode on a configurable nRF24 channel. Displays real-time carrier activity and drives haptic feedback at 100 % motor strength in 150 ms bursts, with pulse rate scaling proportionally to carrier detect rate. More frequent carrier detection = faster haptic pulses. Detection is a one-bit threshold - any carrier above approximately -64 dBm triggers it regardless of signal strength. Haptic rate reflects detection frequency, not calibrated signal level.
Step controls let you move ±1 or ±10 channels while hunting without breaking the carrier-detect display.
Locating 2.4 GHz ISM transmitters by feel
After the Channel Scan identifies active channels, Fox Hunt locks to one and lets you physically walk toward the source using haptic pulse rate as your guide — no screen watching required. Works for any nRF24-compatible or OOK 2.4 GHz transmitter (RC controllers, wireless dongles, proprietary sensors).
Finding a wireless keyboard or mouse dongle
Consumer nRF24 dongles are often plugged into the back of a PC tower or underneath a desk. Once the channel is identified via the Channel Scan, Fox Hunt navigates you to the specific workstation hosting the target dongle — useful in a crowded office where visual identification of the dongle is impractical.
Covert transmitter location in occupied spaces
Same principle as sub-GHz Fox Hunt: haptic-only feedback means you can search an active environment without displaying any on-screen activity or making noise. The variable-rate pulse pattern is intuitive — faster means closer.
Same data center sweep from the Sub-GHz Fox Hunt scenario, but this time the unknown MAC from BLE Observer is on 2.4 GHz ISM, not sub-GHz. You run the Channel Scan and spot anomalous carrier activity on ch 74. Lock Fox Hunt to ch 74, pocket CYM, walk the row. The motor goes from slow taps to a rapid hammering in your hand as you approach rack 22. Behind the cable tray: same story, different radio. An nRF24-based device transmitting on a channel nobody assigned. Found by feel, without a screen.
Lab environments only. Transmitting on 2.4 GHz ISM without authorization is illegal in most jurisdictions. Use only in shielded environments or with explicit written authorization.
Uses the nRF24L01+ CONT_WAVE hardware test mode to emit a 100% duty-cycle unmodulated carrier — no packet overhead, no preamble, no dead zones between bursts. The AT2401C PA+LNA on the NM-RF-HAT pushes output to +20 dBm. The jammer UI matches Bruce firmware (nrf_jammer.cpp) exactly, with 10 selectable band modes, a SEQ/FHSS hop order toggle, and live JAM/STOP button feedback.
Effectiveness note (raised by @eiswolf, confirmed by Jim field testing): The NM-RF-HAT nRF24 jammer works and produces real RF interference (+20 dBm, clearly visible on TinySA). Effectiveness is not consistent across Bluetooth implementations — some devices and BT stacks are disrupted; others are not. It reliably affects weaker or less AFH-capable BT implementations at close range, but does not consistently disrupt robust BT Classic audio streams on capable hardware. Root cause of the inconsistency: the ESP32-C5 is single-core RISC-V — the FreeRTOS main loop shares one core between LVGL, WiFi, BLE coex, touch, and all firmware tasks, so the jammer task cannot maintain the sweep timing needed to outpace AFH on more capable BT implementations. A dual-core ESP32 (D0WDQ6 / D0WD, used in standard CYD boards, Bruce, and Halehound) can pin the jammer to one core, achieving more consistent disruption across BT implementations. SPI bus sharing adds per-hop latency but is a secondary factor. See Bluetooth Disruption Research below for full results.
The mode selector uses two rows of 5 buttons. The active mode highlights red; the JAM button turns bright red while transmitting and dims when stopped.
| # | Mode | Channels | Target |
|---|---|---|---|
| 0 | Test | 40 even ch: 2450-2480 MHz then 2402-2448 MHz | Smoke-test / TinySA verification |
| 1 | BT | 79 ch sequential 2402-2480 MHz | All Bluetooth Classic FHSS channels |
| 2 | BLE | 40 ch sequential 2402-2441 MHz | BLE lower half |
| 3 | BLE Adv | 9 ch: nRF24 ch 1/2/3, 25/26/27, 79/80/81 | BLE advertising channels 37/38/39 + guard |
| 4 | WiFi | 16 ch around 2.4 GHz channel centers | 2.4 GHz 802.11 b/g/n/ax |
| 5 | Zigbee | 48 ch, 3 per IEEE 802.15.4 ch 11-26 | Zigbee / Thread |
| 6 | USB | 20 even ch 2432-2470 MHz | USB wireless dongle band |
| 7 | RC | 20 odd ch 2401-2439 MHz | RC / drone control links |
| 8 | Video | 33 even ch 2460-2524 MHz | FPV video uplink band |
| 9 | Full | 124 ch 2401-2524 MHz | Complete 2.4 GHz ISM spectrum |
A SEQ / FHSS toggle row controls hop order. SEQ sweeps the channel list in fixed order each pass. FHSS applies a Fisher-Yates shuffle after each complete sweep, making the hop pattern unpredictable so Adaptive Frequency Hopping cannot learn to avoid it.
The nRF24L01+ has a hardware test mode (RF_SETUP.CONT_WAVE=1 + RF_SETUP.PLL_LOCK=1, CE high) that outputs a solid unmodulated carrier on the current channel. To hop to a new channel the chip's PLL must retune — and this requires a CE low/high transition:
- CE goes LOW
- New channel written to
RF_CHregister via SPI - CE goes HIGH — PLL begins locking
- 500 µs dwell — minimum for PLL lock (~130 µs) plus AT2401C TX-mode engagement
- Back to step 1 for the next channel
Important: While CE stays HIGH, writing RF_CH does NOT retune the PLL. Versions that kept CE high continuously produced a single spike on TinySA regardless of how many channels were written — the chip locked onto the first channel and stayed there. CE-toggle is mandatory. This is hardware behaviour of the nRF24L01+ in CONT_WAVE mode on the NM-RF-HAT, confirmed empirically.
The AT2401C is a linear amplifier — it amplifies whatever the nRF24 outputs within microseconds. It does not require a power-cycle between hops; CE-toggle + 500 µs dwell is sufficient for it to follow the nRF24 PLL to the new frequency.
SPI bus sharing with the ST7789 display (80 MHz DMA) and SD card adds a small overhead per hop: each nrf24_write_reg takes sd_spi_mutex. At 500 µs dwell per channel, a 79-channel BT sweep takes approximately 40 ms per pass plus a 10 ms yield (~20 full sweeps/sec).
With peak hold (MAXH) enabled on a TinySA, CW spikes build up across the selected band as the sweep progresses — one spike per channel at 1 MHz spacing. In real-time mode the spikes appear briefly and move; MAXH is needed to see the full pattern.
- Test mode produces 40 evenly spaced spikes, upper band first then lower band, making it easy to confirm the jammer is working.
- BT / Full modes fill the entire 2402-2480 MHz or 2401-2524 MHz range with a comb.
- A bright spike near 2417 MHz visible in dense modes is typical background WiFi on channel 2, not a jammer artifact.
TinySA captures in MAXH (max hold) mode — BT mode, AT2401C +20 dBm, ~-20 dBm at TinySA antenna. 1 MHz-spaced CW spikes across 2402-2480 MHz.
After building the nRF24 jammer and confirming good TinySA spectrum coverage, we investigated whether the NM-RF-HAT could disrupt an active Bluetooth Classic link — specifically a JBL Vibe Beam 2 headset in active A2DP streaming.
- CYM v2.13.x on NM-CYD-C5 + NM-RF-HAT — full 10-mode jammer, CE-toggle, 500 µs dwell, AT2401C +20 dBm
- Bruce firmware beta 1.16.1 on the same NM-CYD-C5 hardware (same NM-RF-HAT, same AT2401C)
- Bruce firmware on a CardPuter + Pineapple CAP — CC1101 + plain nRF24L01+ (no AT2401C PA), weaker signal
| Platform | Firmware | Signal | Disruption |
|---|---|---|---|
| NM-CYD-C5 + NM-RF-HAT | CYM | +20 dBm, good TinySA comb | None |
| NM-CYD-C5 + NM-RF-HAT | Bruce 1.16.1 | +20 dBm, matching TinySA pattern | None |
| CardPuter + Pineapple CAP | Bruce | ~0 dBm (no PA) | Minor disruption |
The strongest signal produced no disruption. The weaker setup caused minor disruption. This is counterintuitive and points to fundamental hardware behaviour rather than firmware differences.
Bluetooth Classic uses Adaptive Frequency Hopping (AFH), which hops 1600 times per second across 79 channels (625 µs per hop). AFH monitors error rates per channel and blacklists channels with persistent interference. To force AFH to fail, the interferer must contaminate enough channels fast enough that fewer than 20 clean channels remain — the minimum the spec requires to maintain a piconet.
The NM-RF-HAT constraint is the CE-toggle requirement: each channel hop needs CE LOW, SPI write, CE HIGH, then 500 µs for PLL lock. With 79 channels that is ~40 ms per complete BT sweep — giving AFH roughly 64 hops between our sweeps. AFH has plenty of time to identify our hit pattern and steer around it.
The Pineapple CAP uses a plain nRF24L01+ without the AT2401C PA. Without a PA, there is no amplifier engagement timing to contend with, and the SPI bus has no shared-mutex overhead from an 80 MHz display DMA. The chip may transition channels faster, potentially achieving a higher duty cycle per channel even at lower absolute power — which may be why it achieved minor disruption despite weaker signals.
A secondary factor is the shared SPI bus: the nRF24, ST7789 display (80 MHz DMA), XPT2046 touch controller, and SD card all share SPI2_HOST with sd_spi_mutex. Each hop must acquire the mutex before writing RF_CH, adding latency. This is real but secondary.
The primary constraint is the single-core CPU: the ESP32-C5 RISC-V core runs LVGL rendering, WiFi/BLE coexistence, touch polling, GPS, and all other firmware tasks alongside the jammer task. There is no second core to isolate the jammer from the rest of the system. On a dual-core ESP32 (D0WDQ6 / D0WD) — used in standard CYD boards, Bruce firmware, and Halehound — the jammer task can be pinned to Core 1 with everything else on Core 0, and the sweep rate is fast enough to disrupt active Bluetooth audio streams. This was confirmed by testing the same jammer code on both platforms (raised by @eiswolf, confirmed by Jim across both hardware types).
The NM-RF-HAT architecture produces strong signals (~+20 dBm) clearly visible on a spectrum analyser, matching Bruce firmware's pattern exactly. However, the ESP32-C5's single-core RISC-V architecture means the jammer competes with all other firmware tasks on one core and cannot maintain the sweep rate needed to outpace Bluetooth Classic AFH. SPI bus sharing adds to the per-hop latency but is not the root cause.
Bruce firmware on a dual-core ESP32-D0WDQ6 (standard CYD or Halehound) disrupts active BT audio streams consistently across implementations. Bruce firmware on an ESP32-C5 (NM-CYD-C5) disrupts some BT implementations but not others — the inconsistency is not the firmware, it is the single-core architecture limiting sweep rate. This is a hardware platform difference, not a software tuning issue.
Reliable 2.4 GHz link disruption requires a multi-radio architecture. Dedicated tools like the Nyan Box use 3× NRF24L01+ GTmini (PA+LNA) modules, each with its own antenna, pinned to different channel subsets simultaneously. Rather than sweeping sequentially and racing against AFH, the radios cover the band in parallel — every channel is being jammed at the same time. That architecture is what actually overwhelms Bluetooth AFH; a single-radio sequential sweep, regardless of power or sweep speed, cannot match it. The Nyan Box uses the same amplified nRF24 variant (+20 dBm) as the NM-RF-HAT — the difference is three of them running in parallel, not one running faster.
Practical effect of the jammer:
- BLE advertising disruption: consistently effective — advertising intervals are 100 ms+ and BLE advertising channels have no AFH, so a sweep hitting channels 37/38/39 every 40 ms causes meaningful interference across all BLE implementations
- Bluetooth Classic link disruption: works against some BT implementations, not consistent across all — effectiveness depends on the target device's AFH aggressiveness, proximity, and signal strength. Weaker or less capable BT stacks will be disrupted; robust implementations with aggressive AFH may not be
- Spectrum survey / receiver sensitivity testing: excellent — strong, consistent, calibrated signal at known power
Tip — dual-layer BLE approach: For maximum BLE advertising disruption, run BLE Blaster (BT Attacks menu) concurrently with nRF24 Jammer in BLE Adv mode. BLE Blaster uses the ESP32-C5's native radio to flood the advertising channels at the protocol layer while the nRF24 blocks them at the physical RF layer. The two radios are independent and run concurrently without conflict.
- Receiver sensitivity testing: Inject a known-amplitude swept interferer while your DUT operates. Measure packet error rate vs distance to characterize co-channel rejection.
- Frequency agility testing: Verify that your own nRF24-based or BLE design's channel-hopping or AFH logic reliably avoids a fully-jammed band.
- BLE advertising robustness: Use BLE Adv mode to measure how quickly your device's BLE stack recovers discovery and reconnection after channel disruption.
- Authorized wireless security assessments: Demonstrate 2.4 GHz ISM interference as part of a written-scope physical security engagement.