[Question]: Why doesn't examples_linux/scanner.cpp work?

[dreamlayers]

What would you like to know?

I have two nRF24L01+ modules that I purchased from eBay years ago. I just connected them to my PC running Ubuntu 24.04 Linux using a CH341A module and https://github.com/frank-zago/ch341-i2c-spi-gpio

(This required connecting to a GPIO output pin that wasn't originally connected to the headers, for use as a CE pin. The CH341A module is also modified to power the CH341A from 3.3 V instead of 5 V, though that is probably unnecessary because the nRF24L01+ is 5 V tolerant, with input voltage absolute maximum of 5.25 V. The library needs to be built with -DRF24_LINUX_GPIO_CHIP="/dev/gpiochip1" or similar in CFLAGS to choose the GPIO device, and the CE_PIN define in examples needs to be set appropriately. )

I first tried running examples_linux/scanner.cpp. This found signals on every channel all the time. Eventually I saw that pipe 0 address was being set to all zeroes, and tracked this down to stopListening():

RF24/RF24.cpp

Lines 1188 to 1189 in 5b209c5

	write_register(RX_ADDR_P0, pipe0_writing_address, addr_width);
	write_register(EN_RXADDR, static_cast<uint8_t>(read_register(EN_RXADDR) | _BV(pgm_read_byte(&child_pipe_enable[0])))); // Enable RX on pipe0

After commenting out those two lines, I was still getting a signal all the time on every channel. Then I made the data patterns less like a preamble in scanner.cpp:

RF24/examples_linux/scanner.cpp

Lines 77 to 80 in 5b209c5

	// To detect noise, we'll use the worst addresses possible (a reverse engineering tactic).
	// These addresses are designed to confuse the radio into thinking
	// that the RF signal's preamble is part of the packet/payload.
	const uint8_t noiseAddress[][6] = {{0x55, 0x55}, {0xAA, 0xAA}, {0x0A, 0xAA}, {0xA0, 0xAA}, {0x00, 0xAA}, {0xAB, 0xAA}};

This caused the scanner to behave more like a scanner, only seeing signals on some channels, and more frequently on some than on others. I also absolutely never saw RPD asserted, even with my phone using 2.4 GHz WiFi nearby, with a 2.4 GHz wireless headphone sender nearby, or with a wireless keyboard that probably uses 2.4 GHz based on the antenna design.

Maybe the two lines at the end of stopListening() are a bug, because they shouldn't run if there hasn't been any transmission, or if a transmit address wasn't set. But the other things I experienced are so weird that I was wondering if the nRF24L01+ I used was broken. I tried another module, bought at the same time, and got similar results. Then I ran https://github.com/nRF24/pyRF24/blob/main/examples/fake_ble_test.py and that worked surprisingly well with the exact same hardware. I'm left wondering what's going on. Is the nRF24L01+ counterfeit, and because of that misbehaving when I try to use it as a scanner?

[2bndy5]

Lots to unpack here

1. The nRF24L01 VCC pin is not typically 5v tolerant. The other pins usually are, but not the VCC pin.

2. I saw that pipe 0 address was being set to all zeroes, and tracked this down to stopListening()
   Maybe the two lines at the end of stopListening() are a bug, because they shouldn't run [...] if a transmit address wasn't set.

   This may be an oversight since we overhauled the stopListening() behavior on pipe 0. This is definitely worth investigating further because the Linux scanner example does not actually set a TX address.

3. Then I made the data patterns less like a preamble in scanner.cpp

   We should probably make this an promiscuity option. The scanner example I wrote (in TS) for the rf24-rs project's node.js binding also shows A LOT of detected signals; I ended up coloring the output (red being very active) to visually categorize the various amount of reported signals.

   What did you change the address to?

4. wireless keyboard that probably uses 2.4 GHz based on the antenna design

   This may be an accurate assumption, but I don't think the antenna design is a fair form of measure. Antennas are designed primarily based on application and/or environmental expectations, not the RF frequency they transmit.

FWIW, we have never tested this lib in the scenario you have described. I know older Arduino Uno boards (and some old ESP8266 boards) used the CH34x chip as a USB-to-serial bridge, but never as a GPIO/I2C/SPI bridge.