search

nRF24 / RF24

OSI Layer 2 driver for nRF24L01 on Arduino & Raspberry Pi/Linux Devices
https://nrf24.github.io/RF24
GNU General Public License v2.0
2.21k stars 1.02k forks source link

Not setting channels or data rate properly #992

Closed justcallmekoko closed 1 week ago

justcallmekoko commented 4 weeks ago

What radio module do you use?

E01-2G4M27SX (nRF24L01+), E01-ML01DP5 (nRF24L01+PA+LNA)

What driver board(s) do you use?

ESP32-WROOM (ESP32 Dev Kit)

If using Linux, what OS are you using?

No response

If using Linux, what RF24 driver did you select?

None

Describe your problem

The Problem

For context I am trying to create an protocol analysis device powered by NRF24. One of it's features will be to transmit test data to test reception of other 2.4ghz modules. I noticed a few problems when switching from the generic knock off NRF24L01+PA/LNA modules sold on amazon (the ones with the black PCB and SMA connector) to a couple different modules made by Ebyte which allegedly sport NRF24L01 ICs.

The problems I am facing seem to be miscommunications between the ESP32 host and the NRF24 module connected via SPI. The ESP32 and NRF24 boot, the ESP32 runs through its initial configuration of the NRF24, outputs from printDetails and starts transmitting data on random channels.

During the intial configuration, the data rate is set to 2 MBPS. When outputting from printDetails, the data rate accurately reflects 2 MBPS only about half of the time. The other half it reflects 1 MBPS.

While transmitting I output the random number the ESP32 uses to set the NRF24 channel as well as the channel the NRF24 gets set to using getChannel. In theory these should be the same number however they are wildly different during runtime (please see serial output below).

During transmission, I find on the HackRF One that there is only traffic being transmitted between 2428Mhz-2430Mhz even though frequencies are randomly selected between 2400Mhz-2480Mhz. All frequencies outside of 2428-2430 either have VERY light traffic or none at all.

Additionally, I noticed the TX_ADDR changes sporadically between 0xe7e7e7e7e7 and 0xffffffffff every few reboots.

Serial Output

Preparing radios...
Radio One connected!
----------------------------------
RADIO ONE
----------------------------------
SPI Speedz  = 16 Mhz
STATUS      = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1    = 0xe7e7e7e7e7 0xc2c2c2c2c2
RX_ADDR_P2-5    = 0xc3 0xc4 0xc5 0xc6
TX_ADDR     = 0xe7e7e7e7e7
RX_PW_P0-6  = 0x20 0x20 0x20 0x20 0x20 0x20
EN_AA       = 0x00
EN_RXADDR   = 0x03
RF_CH       = 0x02
RF_SETUP    = 0x0f
CONFIG      = 0x02
DYNPD/FEATURE   = 0x00 0x00
Data Rate   = 2 MBPS
Model       = nRF24L01+
CRC Length  = Disabled
PA Power    = PA_HIGH
ARC     = 0
Random Ch1: 48 | Radio One CH: 16
Random Ch1: 69 | Radio One CH: 7
Random Ch1: 74 | Radio One CH: 15
Random Ch1: 35 | Radio One CH: 35
Random Ch1: 13 | Radio One CH: 15
Random Ch1: 23 | Radio One CH: 23
Random Ch1: 58 | Radio One CH: 31
Random Ch1: 73 | Radio One CH: 13

Troubleshooting Steps

Of course I googled my ass off and browsed the open and closed issues seeing if there was anyone else who was experiencing problems with these specific modules. Believe me, opening a new repo issue is the last thing I want to do.

Per the folks of the internet, I have connected a 10uF electrolytic capacitor between voltage and ground on all of my NRF24 modules, working or otherwise. No noticeable changes in performance.

I ensured my SPI connections between the ESP32 and the NRF24 modules is correct.

I ensured my dupont wires were not the issue by using the same wires to connect an NRF24 module which I verified to function properly.

I have created a source code which just executes the initial configuration and loops through randomly cycling between channels 0 and 80.

Question

I believe I have verified the only difference in hardware and firmware configuration is the NRF24L01 module itself. Is there an explanation or even awareness about this strange SPI miscommunication between the MCU and these Ebyte NRF24L01 modules? I say "SPI miscommunication" only because I don't know what else to attribute it to as SPI seems to work with these modules 90% of the way.

TLDR

Ebyte NRF24 modules reporting wrong getChannel after setChannel and wrong getDataRate after setDataRate but other SPI communication functions as expected. See code and Serial Output.

What is the RX code?

No response

What is the TX code?

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>

#define H_MISO 4
#define H_MOSI 13
#define H_SCK  14
#define H_CS   21
#define H_CE   22

SPIClass *hspi = nullptr; // Radio One

uint8_t ch1 = 2;

RF24 radio(H_CE, H_CS, 16000000);

uint32_t tick = millis();
uint32_t cur_tick = 0;

void setup() {
  Serial.begin(115200);

  delay(2000);

  Serial.println("Preparing radio...");

  // Radio One
  hspi = new SPIClass(HSPI);
  hspi->begin(H_SCK, H_MISO, H_MOSI);

  pinMode(2, OUTPUT);

  digitalWrite(2, LOW);

  if (radio.begin(hspi)) {
    Serial.println("Radio One connected!");
    radio.powerDown();
    radio.powerUp();
    radio.setAutoAck(false);
    radio.setRetries(0, 0);
    radio.setPALevel(RF24_PA_HIGH);
    radio.setDataRate(RF24_2MBPS);
    radio.stopListening();
    radio.setCRCLength(RF24_CRC_DISABLED);
    radio.setChannel(ch1);
    Serial.println("----------------------------------\nRADIO ONE\n----------------------------------");
    radio.printDetails();
    delay(1000);
  }
  else
    Serial.println("Failed to connect RADIO ONE");

  digitalWrite(2, HIGH);
}

void loop() {
  int rand_ch1 = random(0, 80);
  radio.setChannel(rand_ch1);

  cur_tick = millis();

  if (cur_tick - tick >= 1000) {
    tick = millis();
    Serial.println("Random Ch1: " + (String)rand_ch1 + " | Radio One CH: " + (String)radio.getChannel());
  }
}
2bndy5 commented 4 weeks ago

Did you read the ebyte manual for your particular models? I've heard that the ebyte modules don't respect the specified data rate. There's nothing the software can do about that.

The channel thing is certainly weird. Have you tried reducing the SPI speed?

2bndy5 commented 4 weeks ago 
RF24 radio(H_CE, H_CS, 16000000)

This is your problem. The nRF24L01 only supports a max of 10MHz (the lib default). So, the bits output/input over the SPI bus at 16MHz are not interpreted properly.

We've seen other users have better success with using slower SPI speeds (like 6 or 4 MHZ) on ESP-based MCUs. There seems to be a high impedance on those boards' SPI lines.

justcallmekoko commented 4 weeks ago

@2bndy5 I read through what I could with the ebyte manuals but they are all in chinese. I do see what you are talking about though regarding the SPI speed. It is written in the data sheets that it maxes out at 10mhz. I have gone ahead and adjusted that and it seems to have helped with the improper channel setting as well as the data rate setting. The datasheets suggest both of these ebyte modules are capable of 2 MBPS.

The only issue that still doesn't make sense to me (and this might not be a firmware or lib issue) is the fact that this thing, according to the HackRF, is still only transmitting between 2425mhz and 2431mhz even though I am selecting frequencies between 2400mhz and 2480mhz. The datasheets still corroborate that these modules should have no problem operating in this frequency range.

2bndy5 commented 4 weeks ago

Are you sure your HackRF is sniffing packets from the nRF24L01 radios? I've never used one of those.

You could verify that the channels are properly used by running the examples/scanner/scanner.ino sketch (with Arduino or PlatformIO). That example allows 1 node to transmit a carrier wave on a specified channel, meanwhile another node can be used to scan the entire spectrum. The carrier wave emitted by one node should show in the scanner output run by another node. This is the way most governments mandate hardware certification/tests of radios.

[!caution] The scanner example for Arduino does not handle line endings very well. I've tried to compensate for this, but my recent tests showed it was better to just disable line endings in the Arduino IDE's serial monitor's input field.

I did a quick search for the e-byte manuals:

Not sure if they're the right ones, but they are in English.

justcallmekoko commented 4 weeks ago

Excellent find with the english PDFs! I will give those a more in depth read. I'm very confident the HackRF is picking the traffic from my modules. I'm sitting in my basement with relatively low RF traffic. While the NRF modules are transmitting, big ol' red streaks down the RF feed on the HackRF. As soon as I remove power from the ESP32, the red stops.

When using the black pcb nrf24 modules, the red streaks on the hackrf appear from 2400mhz to 2480mhz as intended. Using the ebyte modules, only from 2425mhz to 2431mhz.

I will give the datasheets a read and find out if there is anymore info in there.

2bndy5 commented 4 weeks ago

Please also verify with the scanner example.

justcallmekoko commented 1 week ago

Switching radio modules did the trick. Not sure if the ones I was using were all crapped out but with some new modules, I am no longer running into any issues