Go Down

Topic: Does RF24 lib listen to the writing pipe? (Read 2066 times) previous topic - next topic


Feb 05, 2012, 05:53 pm Last Edit: Feb 05, 2012, 06:23 pm by PeterH Reason: 1
I'm using nRF24L01+ 2.4GHz Wireless Transceivers with the RF24 library to communicate between a bunch of Nanos.

The scheme is that the nanos are organised to form a tree structure. Each Nano has a single address which it listens to by reading pipe 1. Each Nano has a single parent address to which all outgoing messages are sent. Each Nano is designed to act as a relay by forwarding any messages received on pipe 1 to its parent. This works, but has some unexpected behaviour:

In a scenario where there are two Nanos with a common parent (and no other Nanos running), each child Nano receives on pipe 0 the messages which its counterpart sends to the parent. The only way I can explain this is that each Nano is implicitly listening to pipe 0 (the writing pipe) when I call radio.startListening(), even though I have never called radio.openReadingPipe(0,...).

The documentation includes this comment which implies that there is an interaction between reading and writing on pipe 0 but there's nothing to suggest that opening pipe 0 for writing also opens it for reading from the written address:


  * @warning Pipe 0 is also used by the writing pipe.  So if you open
  * pipe 0 for reading, and then startListening(), it will overwrite the
  * writing pipe.  Ergo, do an openWritingPipe() again before write().

The sketch demonstrating this is quite complex and I haven't cut this down to a minimal example yet, but before I do is there anyone  who has used RF24 with multiple senders to a common receiver, and if so did you see this behaviour?

Edited to add: It may be significant that I'm also using Ack payloads for each reading pipe.


If I put this before each call to radio.startListening(), the problem goes away:

Code: [Select]

radio.openReadingPipe(0, 0ULL);

It's not conclusive, but supports the theory that opening pipe 0 as a writing pipe implicitly opens it as a reading pipe to the same address.


Oh yes, that's true.  Opening the writing pipe also opens the same address for listening on pipe 0.  This is just how the chip works, when you write on a pipe it also needs to have the same address open for reading on pipe 0 so auto-ack will work.

So if you then do startListening() you will also be listening on that pipe.  So to avoid this, you can openReadingPipe(0,0) to clear out the address from pipe 0.  Would probably be better to create a closeReadingPipe(0) too.


Aha, that exactly explains what I'm seeing. Thanks for the clarification.

Go Up