Can I get some clarification regarding pipes and addresses?

[JimR]

Hi,

I've asked a few questions previously regarding programming of the nRF24L01/+ for simple data interchange between two devices, and my questions were answered -- many thanks.

However I still don't seem to be able to get a PTX and a PRX device to 'talk' to each other, and I think it may be because I'm not doing the right thing regarding setting up the pipes and addresses. I've read through the relevant pages in the nRF24L01+ data sheet, but I must be 'thick' because I can't get things straight. I've also looked through the code in the RF24 library (for Arduinos), but to be honest I can't see how the functions work in that library -- or how the 'Getting Started.ino' example works, especially for PTX mode.

At present I'm setting 'Radio 0' to receive using pipe 0, and leaving its TX_ADDR at &H30E7E7E7E7E7, while 'Radio 1' is set to receive on pipe 1 with its address set to &H30C2C2C2C2C2 -- is that wrong? Then when either radio is set to PTX mode or PRX mode, I simply clear or set the PRX bit in the chip's CONFIG register -- with the CE line pulsed high for 20us in PTX mode, after loading the transmit data into the fifo.

There must be something wrong with the above, but I can't see what it is. I guess I'm also confused about the ACK packet which seems to be sent by the PRX device -- this is sent ahead of the returned payload, is it not?

I hope you can make sense of the above, and provide some clarification please.

Thanks, Jim

[Hung Bui]

Sorry, I meant "Appendix A" not "Appendix 1".

The nRF24 can listen to 6 different pipes (6 address) at the same time, you don't have to match the pipe on the PTX with the pipe on PRX. They don't care about pipe, the address is what they use to match.

There are many reasons that your chips don't communicate. We can think of there could be smth wrong with the firmware you use to test the chip. Have you made sure you can write and read the register on the chip normally ? Have you make sure the RF hardware part is done correctly ? Can you send the schematic and layout ? And a close up photo of your board ?

[JimR]

Yes Hung Bui, I have tested that I can write and read the registers on the chip normally, and I'm pretty sure that I am setting it up correctly on the RF side. The RF hardware side is also functioning OK, since I'm using commercial modules with a 'meandering track' PCB antenna -- and the modules work fine with Arduino microcomputers. But you didn't actually say whether the addressing scheme I described in the previous comment was right or wrong -- can you please answer my question! JimR

[Hung Bui]

Yes it's correct. But when a device is in TX mode, it's doesn't mater which RX_ADDR_* are set. Same with PRX, when you are in RX mode, TX_ADDR doesn't take effective. Please try to set on PTX side TX_ADDR to 0xE7E7E7E7E7 and on PRX side, set RX_ADDR_P0 to 0xE7E7E7E7E7 .

Make sure you enable Pipe 0 as receiver pipe.

Please post your code.

If the module works fine with the Arduino, you can try to follow what is used on the Arduino firmware and test on your device.

[JimR]

Thank you Hung Bui, for that helpful reply. I have tried following the code used in both the Arduino program and in the RF24 code library in which its functions are sourced, but this has proved to be very difficult. In the meantime, can you please answer another question. I understand that whenever you send commands or data to the nRF24L01 via the SPI interface, it returns the contents of the status register. But presumably what it returns is the contents of the status register BEFORE the command or data is received -- right? If this is so, it sounds like if you want to know the chip's status AFTER the command or data is received, you need to read from the status register again, straight afterwards. Can you please confirm that this is correct -- or explain why it isn't. Thanks, JimR

[Hung Bui]

@JimR : What you say is correct. It's the status BEFORE the command or data is received. If you want the most upto date you would either read the status register, or do a dummy command (NOP command).

My suggestion is to use a logic analyzer and track down what the Arduino code does on the SPI and you try to do the same thing on your code, then compare why there is a difference in the result.