Sorry, I have no Arduino on hand to test the "scanner" sketch. But I have a question on the performance of the Arduino sketch. Please first confirm the test setup is as summarized below. (1) First setup Arduino and run the receive message sketch, which is an infinite loop waiting for message from Rpi, and prints the message at the serial monitor, and also the message "Turning off radio",

(2) Then setup Rpi and run the its "send message" python program, as often as you like. Now every time you run the Rpi send message, only if Arduino side got the Rpi message, then it will print the received message, then the "Turning off radio".

No if Rpi sends message "Hi" three times, and only if Arduino receives "Hi" every time, it will print the "Hi" on the serial terminal, then followed by "Turning off radio". This is the part I don't understand.

To debug, I would suggest to insert the following confirmation message something like, "Serial.println("yes, I got the message") BEFORE the statement. "Serial.println(receivedMessage)" This way, even if Arduino gets an empty message, it will still print the "yes, I got the message", before the "Turning off radio". I guess this is also your question. I am just making a quick and dirty, brainstorming reply. Nothing urgent to reply now, perhaps only after you exam.

By the way, I tried to google for a more up to date nRF24L01 python library, but no luck, I only found similar libraries forked from the same source, Brian Lavery Oct 2014. Perhaps I should google harder, but it is unlikely I could find more useful things, as this nRF24L01 library stuff has been non active for a couple of years, and all the original or forking authors said they don't support their libraries any more, and that a couple of thins not yet tested, so it is discouraging, :(

So I will pause for now, and perhaps see your opinion after your exam. By the way, I studied the python library github.com/BLavery/lib_nrf24/blob/master/lib_nrf24.py and found it not that complicated. Perhaps in the long run, I would buy a new version of nRF24L0-1+ (my modules in hand are very old!)

One more thing, if I am going to fork/modify the BLavery library, perhaps I would consider two Rpi python program, one send message, another receiver message. Then I can use two Rpi's , or one Rpi controlling two nRF24 at the same, time, one using Spi0.0, the other Spi1.0 say. But that is a long term project, at least not for these couple of months. Cheers.

The Module143 Tutorial #13 has two nRF24L01 demo python programs, one for transmit, another for receive. So I guess it is easier to test both transmit and receive using two or just Rpi's, without bothering Arduino. By the way, I am curious to know why you start with Pi and Arduino, but not Pi to Pi?

As I said earlier, I do not have an Arduino in hand to test the nRF24L01 receiving mode, so I am thinking of using Rpi to test the receiver. A more ambitious goal is to use one Rpi running in multi-processing/multi-threading mode, one transmitter and one receiver. Another thing is to use a scope to display the no modulation carrier waveform, to see how to change the nRF24 options to get the highest output power, as shown in the following picture: (sorry, cannot upload, will try later, :()

The above picture is one of the many summary screen captures of my datasheet reading summary. I am compiling a gallery of those pictures perhaps I might show you later. These pictures help refreshing my memory of datasheet reading.

There you are, my datasheet reading summary: penzu.com/p/fb5096a7.

Now I am reading more carefully the Transmit and Receive python programs, both for Rpi. I found it easier to understand what is going on each side, if both program are written in Rpi python, because there is many sections in common, and in the first transmit program, the mirroring parts are commented out, so it should be easy to compare and contrast the two programs. I still find the listening part confusing. So I need to read the library now, which is much longer than the demo programs.

Now I have read the nRF24L01 library in python. I am happy to find that the program is very well structured, and self documented, so it is easy to do any maintenance or modification. Earlier I said that I am not interested to use this library which is no longer maintained by the original author, and not all features are tested. Now I have changed my mind, because now I think that this library seems well developed, and so it is a good idea to play with it.

@StevenCellist @StevenCellist, as I said earlier, I think it is worth my time to test without Arduino, but just use two Rpi's, one to transmit, the other to receive. And everything goes well, we can try one Rpi, two multi-processing functions, one transmit, another receive. But I am tied up with other toy projects and would not be able to start playing now.

So if you are using my suggested one Rpi two python programs, I am interested to join in. Nothing urgent, no need to reply, until you finish your exam. So see you on Wednesday or later. Cheers.