RF24 could not send radio packet in (Any Address)

[nicholaspeng86]

Hi, I'm trying to get this on my Raspberry pi working, but I've encountered some problems. I have a Raspberry pi 3B+ with Raspbian Buster fresh installed with the official NOOBS from RPi website. (Also tried with RPi 2B+, same result.)

I installed the RF24 library and node in ~/.node-red directory with following commands in terminal: cd ~/.node-red npm install nrf24 npm install node-red-contrib-nrf24

What I'm trying to do basically is a simple receive/transmit flow, the inject node sends a string (in this case "Hello world") to the RF24 output node But this is where I'm having problems, when the string is injected to the output node, I keep getting the warning "RF24 could not send radio packet in 0x72646f4e32" popping up in my node-red debug window. I also tried disabling auto-ack, same results.

I've also configured the configuration node accordingly to my setup

NRF24 & RPi pin layout configuation

V+ -> 3.3V(pin01) GND -> GND(pin06) CSN -> CE0 (pin24) CE -> GPIO27(pin13) MOSI -> MOSI(pin19) SCK -> SCLK(pin23) MISO -> MISO(pin21) IRQ -> not connected

Got any ideas why it is not working? I've been debugging this for the past 2 months, but still haven't found a solution. Thanks.

[ludiazv]

Hi Are you using only 1 radio? or do you have other device reponding on the defined Pipe?

[nicholaspeng86]

Hi Are you using only 1 radio? or do you have other device reponding on the defined Pipe?

I'm planning on using the radio to communicate between my Raspberry pi and Arduino Mega2560, the Arduino side works fine, I've tested with another Arduino, but the case with Rpi is neither transmitting nor receiving anything.

[ludiazv]

Software response seems ok as the radio is detected and is able to send to commands to the radio. If the radio works with another Arduino then the radio is ok.

To discard first a hardware problem I would try 2 things first:

• Provide the 3.3v for the radio not using the RPI 3.3V output but other external supply (for example the arduino where the radio worked fine). DONT forget o connect the GND of the external power supply to the one of the GND pins on the PI. or/and
• Solder a capacitor in the power pins as show here: https://www.instructables.com/id/NRF24L01-Fixing-Connection-Issues/

If this fails let me know. There as testing script inside the nrf24 module that will test the radio using an arduino as remote location that can test if the radio is working fine on the PI more easily than in node red.

[nicholaspeng86]

I tried the solution above soldering a 10uF capacitor between the power pins and used the Arduino as a power supply (powered by a USB cable connected an Apple iPad 10W 5.1V 2.1A USB power adapter), but the problem persists.

And I also noticed that when I re-deploy the flows, it detects the radio like before, but there is an extra line saying "[info] [RF24radio:RF0] nRF24 listeing stop. rid= 30c50a77.357386 stop=true , by_user=false,error count=0" in the node-red logs, this message doesn't show up on node-red startup, it only shows if I re-deploy the flows.

[ludiazv]

When restarting flows this message is normal as the radio module is restarted. This not happen on start up as the radio is configured for the first time.

To test if your radio is working with the Pi you can use a testing script without using node-red:

1. Stop node red to be sure that your flow is not trying to use the radio.
2. Follow this commands:

   ~:$ mkdir -p test_nrf24
   ~:$ cd test_nrf24
   ~/test_nrf24:$git clone https://github.com/ludiazv/node-nrf24.git
   ~/test_nrf24:$cd node-nrf24
   ~/test_nrf24/node-nrf24:$ npm install

   This will compile the base module for you with the latest version. It could take a few minutes.

now edit the file examples/GettingStarted.js changing the lines 6 with your wiring value for the CE pin and 9 to disable IRQ pin to -1. Then launch the example script with node examples/GettingStarted.js.

This example will work with the default sketch in arduino in the NRF24 library called also "GettingStarted".

You can remove the test_nrf24 folder after the test. This version do not install anything in your system.

[nicholaspeng86]

Here's what I did:

~:$ node-red-stop
~:$ cd test_nrf24
~/test_nrf24:$git clone https://github.com/ludiazv/node-nrf24.git
~/test_nrf24:$cd node-nrf24
~/test_nrf24/node-nrf24:$ npm install

And then I get:

npm WARN npm npm does not support Node.js v10.19.0
npm WARN npm You should probably upgrade to a newer version of node as we
npm WARN npm can't make any promises that npm will work with this version.
npm WARN npm Supported releases of Node.js are the latest release of 4, 6, 7, 8, 9.
npm WARN npm You can find the latest version at https://nodejs.org/

> nrf24@0.1.5-beta preinstall /home/pi/test_nrf24/node-nrf24
> ./build_rf24libs.sh

Buiding nrf24 library versions: RF24:v1.3.2 RF24NETWORK:v1.0.9 RF24MESH:v1.0.7 DRIVER:SPIDEV
Cloning into 'RF24'...
remote: Enumerating objects: 171, done.
remote: Counting objects: 100% (171/171), done.
remote: Compressing objects: 100% (135/135), done.
remote: Total 3752 (delta 91), reused 77 (delta 35), pack-reused 3581
Receiving objects: 100% (3752/3752), 1.66 MiB | 1.54 MiB/s, done.
Resolving deltas: 100% (2241/2241), done.
=>RF24...
Note: checking out 'v1.3.2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 56f9bf4 Update library.json
56f9bf4 (HEAD, tag: v1.3.2) Update library.json
===> Activate failure handling .....
#define FAILURE_HANDLING
===> Building...
[SECTION] Detecting arm compilation environment.
  [OK] arm-linux-gnueabihf-gcc detected.
  [OK] arm-linux-gnueabihf-g++ detected.
[SECTION] Detecting target machine.
./configure: line 66: warning: command substitution: ignored null byte in input
[OK] machine detected: SoC=BCM2835, Type=RPi, CPU=armv7l.
[SECTION] Detecting OS.
  [INFO] OS detected:LINUX.
[SECTION] Preparing configuration.
[SECTION] Saving configuration.
[SECTION] Cleaning previous builds.
[OK] Finished.
arm-linux-gnueabihf-g++ -fPIC -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -Ofast -Wall -pthread  -c RF24.cpp
arm-linux-gnueabihf-g++ -fPIC -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -Ofast -Wall -pthread  -c utility/SPIDEV/spi.cpp
arm-linux-gnueabihf-g++ -fPIC -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -Ofast -Wall -pthread  -c utility/SPIDEV/gpio.cpp
arm-linux-gnueabihf-gcc -fPIC  -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -Ofast -Wall -pthread  -c utility/SPIDEV/compatibility.c
arm-linux-gnueabihf-g++ -fPIC -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -Ofast -Wall -pthread  -c utility/SPIDEV/interrupt.c
[Linking]
arm-linux-gnueabihf-gcc -shared -Wl,-soname,librf24.so.1 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -Ofast -Wall -pthread  -o librf24.so.1.3.2 RF24.o spi.o gpio.o compatibility.o interrupt.o -pthread
ar -rcs ../librf24.a RF24.o spi.o gpio.o compatibility.o interrupt.o 
[Installing Headers to ../include/RF24]
==> RF24 cleaned
=>RF24Network...
Cloning into 'RF24Network'...
remote: Enumerating objects: 89, done.
remote: Counting objects: 100% (89/89), done.
remote: Compressing objects: 100% (64/64), done.
remote: Total 2338 (delta 45), reused 53 (delta 22), pack-reused 2249
Receiving objects: 100% (2338/2338), 1.68 MiB | 1.46 MiB/s, done.
Resolving deltas: 100% (1387/1387), done.
Note: checking out 'v1.0.9'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 2d93030 Update version for release
2d93030 (HEAD, tag: v1.0.9) Update version for release
g++ -Wall -fPIC  -c RF24Network.cpp
ar -rcs ../librf24net.a RF24Network.o 
install -m 0644 *.h ../include/RF24Network
==> RF24Network cleaned
=>RF24Mesh...
Cloning into 'RF24Mesh'...
remote: Enumerating objects: 88, done.
remote: Counting objects: 100% (88/88), done.
remote: Compressing objects: 100% (66/66), done.
remote: Total 715 (delta 51), reused 51 (delta 22), pack-reused 627
Receiving objects: 100% (715/715), 274.64 KiB | 467.00 KiB/s, done.
Resolving deltas: 100% (387/387), done.
Note: checking out 'v1.0.7'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 7760101 Update version for release
7760101 (HEAD, tag: v1.0.7, tag: 1.0.7) Update version for release
g++ -Wall -fPIC  -c RF24Mesh.cpp
RF24Mesh.cpp: In member function ‘bool RF24Mesh::write(const void*, uint8_t, size_t, uint8_t)’:
RF24Mesh.cpp:112:21: warning: comparison of integer expressions of different signedness: ‘uint32_t’ {aka ‘unsigned int’} and ‘int32_t’ {aka ‘int’} [-Wsign-compare]
         if(millis() > lookupTimeout || toNode == -2){
RF24Mesh.cpp: In member function ‘bool RF24Mesh::requestAddress(uint8_t)’:
RF24Mesh.cpp:372:10: warning: unused variable ‘registerAddrCount’ [-Wunused-variable]
  uint8_t registerAddrCount = 0;
          ^~~~~~~~~~~~~~~~~
ar -rcs ../librf24mesh.a RF24Mesh.o 
install -m 0644 *.h ../include/RF24Mesh
==> RF24Mesh cleaned
done!
npm WARN notice [SECURITY] lodash has the following vulnerability: 1 high. Go here for more details: https://www.npmjs.com/advisories?search=lodash&version=4.17.20 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.

> nrf24@0.1.5-beta install /home/pi/test_nrf24/node-nrf24
> node-gyp rebuild

make: Entering directory '/home/pi/test_nrf24/node-nrf24/build'
  CXX(target) Release/obj.target/nRF24/irq.o
  CXX(target) Release/obj.target/nRF24/tryabort.o
  CXX(target) Release/obj.target/nRF24/rf24_util.o
  CXX(target) Release/obj.target/nRF24/rf24.o
  CXX(target) Release/obj.target/nRF24/rf24_setup.o
  CXX(target) Release/obj.target/nRF24/rf24_worker.o
  CXX(target) Release/obj.target/nRF24/rf24_stats.o
  CXX(target) Release/obj.target/nRF24/rf24mesh.o
  CXX(target) Release/obj.target/nRF24/rf24_init.o
  SOLINK_MODULE(target) Release/obj.target/nRF24.node
  COPY Release/nRF24.node
make: Leaving directory '/home/pi/test_nrf24/node-nrf24/build'

> nrf24@0.1.5-beta postinstall /home/pi/test_nrf24/node-nrf24
> rm -rf rf24libs

npm notice created a lockfile as package-lock.json. You should commit this file.
added 124 packages from 85 contributors in 237.842s

and then I edited the GettingStarted.js file pin config to my setup, which is

const CE=27,CS=0;
const IRQ=-1; 

And finally :~/test_nrf24/node-nrf24 $ node examples/GettingStarted.js

but unfortunately, it is still pouring out sending failed messages.

[ludiazv]

If this script fails the probability of a problem in the software is low. Did you tried using the arduino as sender and the rpi as receiver?

[nicholaspeng86]

If this script fails the probability of a problem in the software is low. Did you tried using the arduino as sender and the rpi as receiver?

No, I have not. I am also suspecting it to be a hardware problem, since the error message sometimes fluctuates to "hardware fail check wiring...etc" when I touch the wires, so it might be bad wire quality causing the issue, but I'm not sure yet, so I'm planning to solder the radio module on a perfboard and mounting it on the rpi directly(similar to the BorosRF2 hat) to see if it resolves the problem. I'll let you know when I'm done testing.

[ludiazv]

Long cables and poor contacts can be problem specially at high frequencies. Specially the CE pin causes a lot of problems with the radio interface. Try also to exchange or use new radio modules.

[nicholaspeng86]

I've soldered the radio module on to a perv board along with the 10uF capacitor, and the wires I use for connecting the pins are solid ones instead of the stranded ones, and I also tested the connection with a multimeter. But it still doesn't work. I'm thinking about going back to Raspbian Stretch to try it, maybe something got updated in Raspbian and the library didn't, I'm running out of ideas.

*UPDATE I tried using the Arduino as the transmitter, and the RPi as the receiver, the Rpi is receiving something, not sure if it's working properly
But when the roles are switched (Rpi as the transmitter, Arduino as the receiver), nothing is received.

[ludiazv]

Hi, If your wiring is ok. It seems the problem is quite strange. 1st case Arduino -> RPI As you can seen in the first trace your RPI is receiving the package. But fails to send(or the arduino do not receive) the ACK (as the Arduino do not received it). This is a built-in feature of the radio. Also it fails to send the response.

2nd Case is clear the rpi fails to send the packed.

The problem is that your radio in the RPI can't send neither acks nor data packets.

Send problems can be related CE pin as is the one used to change radio states.

Trying with clean old-stable strech version could be a way to discard any OS interference.

[nicholaspeng86]

Went back to Raspbian Stretch, the problem still persists, and the CE pin you're referring to, is it the pin on the radio module or the CE0 (pin24)on the RPi? should I try with CE1 (pin26)?

[ludiazv]

Well now you have at least now that buster is not the problem.

On the pi MOSI,MISO,SLCK,CE0 must be connected SPI interface of the radio MOSI,MISO,SLCK,CSN pins. This is ok There are two additional pins on the radio. CE and IRQ. IRQ is optional with the library you can set it to -1. but CE is mandatory and you can plug it to the pin you want on the PI. see it here:https://lastminuteengineers.com/wp-content/uploads/2018/07/Pinout-nRF24L01-Wireless-Transceiver-Module.png

You must be sure that in test script is using this correct pin in line const CE=<your pin>,CS=0

when you run the program this pin is exported to user space an is visible here /sys/class/gpio/gpio<yourpin>

If you have logical analyser or oscilloscope you can check if this pin changing when the radio start transmitting. Try to use different pins on the PI to check this out.

[nicholaspeng86]

This is really weird, originally I was using the Arduino Mega2560, was thinking about to try it on other Arduinos since I have so many Nrf24l01 modules lying around, so I borrowed a spare Arduino UNO and wired it with the radio, and uploaded the Gettingstarted code, and I was getting send response in the serial monitor (assuming that the code sets the arduino as receiver in default state before entering T in the serial monitor ), I was first confused, so I check the RPi with the VNC viewer and that's when I realized that I have my RPi running the Gettingstarted code in transmitter role and was receiving responses from the arduino, but I did not touch or change any of the software or hardware on the RPi, all I did was wired up the Arduino UNO, Im guessing somthing is wrong with my MEGA2560 hardware. and I returned to Raspbian Buster, its working fine also.

At this point I thought Node-red would be working fine, transmittting from RPi looks fine, but isnt receiving anything from the arduino, the Getting started code works, but IDK why it is not working in Node-red.

[ludiazv]

Hi, Well you solved the big issue. Your PI is able to talk over the radio. As regards node-red. It's quite strange as the node-red package uses the library you just tested by the script. Are you using the version published in the npm?

[nicholaspeng86]

Nevermind the last receiving problem in node-red, a system reboot fixed it, but now I am getting random texts after my payload, for example, I should be getting "Hello World 6509" sent from the Arduino, but instead "Hello World 6509!��A
P !" is received, any ideas where the problem is?

By the way, Rpi sending to Arduino works fine.

[ludiazv]

Remenber that payloads are fixed size in in base nrf24protocol. By default 32 bytes. I think you are using convert to string in the output the garbage that you see at the end is part of this this execess in the payload. In a real application you should define how to decode the payload by manipulating the incoming buffer.

I have a major release of a new version I think I will include post processing for supporting null terminated strings. But is not a priority.

[nicholaspeng86]

Oh okay, I understand, I think that's all I have to ask, I will close this issue, thank you for your help ; )