0

I have a number of RPis that communicate with Arduinos via BLavery's lib_nrf24.py (which appears to be derived from Barraca's pynrf24). Recently several of the RPis automatically updated via apt-get upgrade/update (a Pi2 and a Pi3 both running Jessie) and the communication code for those devices immediately ceased to function correctly (the code still runs but the messages are no longer recognised by the recipient [assuming they are received at all]). Other RPis that did not update continue to communicate as normal. All RPis have identical code, but for pipe definitions and channels etc...

The NRF24 code has a python command 'radio.printDetails', which outputs various parameters related to the NRF24's status. For the still-functional units, the output of this command appears stable. What I mean by this is that things like the radio channel number, transmission pipes or transfer rates match those specified in the code (and do not alter unless changed with the code). However for the non-functional units these parameters seem to be random and often change between two consecutive attempts to run the identical code. Also, the code may specify 1MBPS, but the status command might output 250KBPS (or it might output 1MBPS or some other number).

So to setup the RPIs to run the NRF24s I did use py-spidev_master...

wget https://github.com/Gadgetoid/py-spidev/archive/master.zip

I will be honest, I don't really know what this does or how it does it, but I am curious if some incompatibility with this might be causing my problems. I have also tried additional sudo apt-get upgrade/update, but they have not resolved the issue. I have checked hardware and that does not seem to be the problem (the Arduinos and non-upgraded RPIs are all still happily chatting away with one another). Finally, not sure if this is important but my /boot/config does contain an active dtparam=spi=on.

Any ideas as to how I might fix this or even what else I might try? Also has anyone else seen any problems like this in the last few months?

Thanks for reading and thanks in advance for any suggestions...

2

I have exactly the same problem. Two different NRF24L01 modules. Raspbian stretch worked in the beginning, since the last update no more.

I use https://github.com/Gadgetoid//py-spidev/archive/master.zip together with https://github.com/BLavery/lib_nrf24

This seems to be on the SPI level. This thread: https://www.raspberrypi.org/forums/viewtopic.php?t=191540 indicates that the speed of the SPI bus might be set wrong.

The problem is that I use Python to access the bus and it is not evident how, when and where I should set the speed of the SPI bus.

Did you make any further progress?

EDIT:

I found it: In lib_nrf24.py in function:

def begin(self, csn_pin ... after self.spidev.open add:

self.spidev.max_speed_hz = 4000000

(in my case 5 MHz did not work)

  • To be honest, I had stopped thinking about it once I got the units to begin communicating again. So adding this line corrected the issue? Also how did you determine to use a value of 4000000 for the speed? – Ravingly Rabbit Nov 19 '17 at 15:51
0

So this isn't a perfect solution, nor does it either identify nor address the cause of the problem, but reverting to 4.9.26-v7+ enabled the unit to begin communicating again.

sudo rpi-update b3df66512cfecc82aa3da850879f4eb3ed94deef

0

i also working with nrf24l01 and raspberrypi it works before after update it is not working crc length disable gettingenter image description here

  • Hi and welcome. We generally avoid "me too" as answers, as you are not really helping the original poster with their problem. – Vincent P Apr 23 at 7:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.