This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Using nRF24L01+ in multiple designs - Experiencing a communication window anomaly - Could use some advice

Hey guys, I am currently using the nRF24L01+ (more specifically the module that has +pa +lna), and I am experiencing some odd behavior. I will briefly go over the devices, and then will describe what I am seeing.

I have multiple PCB's using a Parallax Propeller chip to communicate with the nRF24L01+. For the most part, these devices are working and are getting the data across. I started collecting transmission/receiving/echo data for all of our devices and storing them into a spreadsheet so we can compare the reception of each device, and if something improves/decreases the performance it will be somewhat measurable.

One of my tests is an "echo" test. I have a testing device transmit a payload at a certain interval (e.g. 500ms, 200ms, etc.). The other device is programmed to wait for payloads, and as soon as it sees one it will immediately re-transmit the payload back. The testing device keeps track of how many payloads were echo'ed back. This specific test is where I noticed something was not right. It appears there are "windows of opportunity" for communication to occur or not occur. Here is what I mean:

Test Delay, Device Retransmit Delay, Device Received Count, Echoed Back Count

500 0 100% 97%
400 0 100% 67%
300 0 100% 0%
200 0 50% 33%
180 0 50% 25%
160 0 50% 17%
140 0 50% 0%
120 0 50% 0%
100 0 50% 0%
			
500 100 100% 67%
400 100 100% 0%
300 100 50% 50%
200 100 50% 18%
100 100 38% 0%

So the "Test Delay" is the interval in milliseconds that I am transmitting. The "Device Received Count" is how many payloads made it from the tester to the device. The "Echoed Back Count" is how many payloads were echoed back from the device back to the tester.

Every time I run these tests the numbers conform to these very specific numbers (e.g. 67%, 50%, 33%, etc.). It doesn't matter when I start the test, or how long I let the test run, it will be the exact same result every time. (both device received count, and echoed back count).

At first I thought that the re-transmission might have been coming back too fast and the testing device was just missing it (but this would be consistent over all tests is the thing). For a test, I incorporated a small delay on the device that is echoing data back. This is labeled as "Device Retransmit Delay". Normally it re-transmits the payload back instantaneous, so instead I tried adding a 100ms delay to see how the results changed. There are still these "holes" where data will not echo back at that interval, its just shifted slightly.

So it started making me wonder if there is something inside the nRF24L01+ that may be causing this behavior? It almost seems like there is a floating window that transmissions need to pass through otherwise there is data loss?

Has anyone experienced anything like this? I am thoroughly confused and would greatly appreciate any help or advice in figuring this out. Thanks!


p.s. Here are some nRF24L01+ configuration details:

  • I am not using the auto-acknowledgement feature
  • 250kb/s communication speed
  • Payload size is 32 bytes

Here are some hardware details:

  • Dedicated 3.3V 1 amp power rail for the nRF24L01+, sitting directly next to it.
  • Using 10uF, 1uF, 0.1uF SMD(0805) decoupling capacitors across nRF24L01+ power (extremely close to the power pin).
  • Also using a 220uF capacitor directly next to the power pin of nRF24L01+.
  • There is no PCB material under the nRF24L01+ antenna area... it overhands the board for improved reception.
  • Hi, to start debugging this:

    • If there is no receiver, then measure VDD_PA pin on the transmitter and ensure that it only toggle high 1 time for each transmission (0V->1.7V->0V), and that the nRF24L01+ always return TX_DS after transmission. If this is not the case, then you have not successfully disabled the auto-ack feature.

    • To transmit 32byte payload @ 250kbps it will take about ~1400us from CE toggle on the transmitter to TX_DS. Ensure that is the case.

    • I assume that the transmitter will transmit the payload and wait for TX_DS, then switch to receive mode, and set CE high, and stay in receive mode a period of time until RX_DS or timeout (e.g. 2-3ms).

    • I assume the receiver will stay in receive mode and wait for RX_DR, read out payload, switch to transmit mode, write payload, and toggle CE, and wait until TX_DS.

    • Make sure you don't power down (PWR_UP = 0) the radio during a transaction, as that will shut down the crystal.

  • Thanks a lot for the response!

    1. I will double check the auto-ack, but I am almost positive I have it disabled since I have verified the settings from reading the registers back after setting them. I also never get the MAX_RT status indication when I have it disabled... but would occasionally get it when using the auto-ack.

    2. I am going to wrap some of the functions with a code execution time calculator so I can precisely see how long these functions are taking.

    3. Not quite... the device is always sitting in receiver mode by default. When something needs to transmit, CE goes low, then this command is executed to switch to transmit mode "WriteRegister($00,%0000_1110)". TX FIFO is flushed, payload is loaded then CE pin is cycled high for 100us then back to low (to transmit payload). It then switches back to RX mode via "WriteRegister($00,%0000_1111)" then CE goes high again. It then goes back to the main loop where it monitors the IRQ pin and any status that comes over (which generally the next status will be the TX_DS). But it is not necessarily waiting for a TX_DS.

    4. Yes pretty much. It doesn't necessarily wait for a TX_DS, but this is generally the next status that comes out of the nRF.

    5. I verified that the PWR_UP register slot is never powered down (it is only in power down mode during initial configuration and that is it).

  • Let me know how it goes. I am not aware of anything in specific, but in general this kind of radio switching is not straight forward. The recommended way is to use ACK payload when possible, but that might not be possible here if it is not a 1:1 communication.

  • So it turns out my SPI protocol is extremely slow... it was taking 105ms to receive or transmit a payload. I started making modifications to it and was able to drop it down to 19.7ms. I'm thinking this might of been the issue? I was not able to run another comprehensive test at this speed because I now notice that the nRF24L01 module is getting very hot and communication is now intermittent.... /sigh

    And yes its not 1:1 communication, so we have developed a mesh network type scheme which includes device ID's, to & from, acknowledgement, payload forwarding, etc.

  • Have you published the propeller code for talking to the nRF24L01+ ? Just got a few of these and want to use my props to talk to them as well.

Related