nRF51822 / nRF24L01 compatibility with auto retransmission ?

RE: nRF51822 / nRF24L01 compatibility with auto retransmission ?

Simonr — Fri, 09 Jun 2023 10:25:50 GMT

As this ticket is 8+ years old, I'd recommend that you create a new ticket instead, where you describe your issue in detail, and potentially link to this ticket if necessary.

Best regards,

Simon

RE: nRF51822 / nRF24L01 compatibility with auto retransmission ?

Jonas Hoefer — Fri, 09 Jun 2023 09:52:25 GMT

I have excactly the same problem as you Landry using the nRF Connect SDK. Could you figure out any help. I know this is already 8 years old but still I hope you could help me if you find out what the problem was.

RE: nRF51822 / nRF24L01 compatibility with auto retransmission ?

Landry — Wed, 25 Feb 2015 16:29:25 GMT

I definitely thought of priority issues. So I wrote a simple piece of program, with no RTX, no interrupt, etc... Just the minimum necessary to run my system and cause this behaviour.

But unfortunately, the test program shows that even with no rtx and no interrupt activated, I still got similar issues.

So I hardly think it is related after all.

I opened a new support case, referenced 20480, with the demo program. Unfortunately I can't give you the code for the sensors but there are indications about what the receiver is expecting.

I hope this will focus the origin of the problem. Please be sure that I really, really appreciate your help.

Regards,

RE: nRF51822 / nRF24L01 compatibility with auto retransmission ?

Asbjørn — Tue, 24 Feb 2015 13:11:43 GMT

We've been discussing this case here at tech support now and it occurred that it might be caused by interrupt priority. It sounds like from your screen shots and descriptions that the FW isn't able to update the memory point in between RX and sending the ACK. This is something we test in our software builds, but if your application FW is running on the same interrupt priority as the ESB lib, something like this could happen. It's important that the ESBlib is running alone at highest priority level. Could it be that you have your application running at the same interrupt priority? Make sure that the application is running on at least one level lower than the ESB-lib.

RE: nRF51822 / nRF24L01 compatibility with auto retransmission ?

Landry — Mon, 23 Feb 2015 14:58:04 GMT

Here is what I get:

correct behaviour: Sensor send packet, Recorder acknowledge http://1drv.ms/1En4MfI
nrf51822 in pause: VDD_PA is a mess for nrf51822. The µc linked to the nRF24L01 receive an RX_DR signal with the packet that has just been sent. http://1drv.ms/1En4TYD (zoomed: http://1drv.ms/1En4ZzB )
sensor slightly out of reach (no nRF24L01 vdd_pa on the screenshot, because the sensors is too far). Strange behaviour on nRF51822's VDD_PA (some pulses under 1.8V ? pulses close to each others ?). µC connected on nRF24 receives an RX_DR signal with the packet that has just been sent. http://1drv.ms/1En53iU and zoomed : http://1drv.ms/1En58Dc

Please note that when I stop the transmitter prior to pausing the nRF51822, there is no activity at all on the nRF51822 VDD_PA.

RE: nRF51822 / nRF24L01 compatibility with auto retransmission ?

Landry — Mon, 23 Feb 2015 14:57:54 GMT

Thank you again for your help.

Absolutely, these pulses on VDD_PA are 1.8V, the duration seems to fluctuate whereas there is a payload in the ack.

OK I understand better for the ARD differences I observed.

I indeed can reproduce in an "exaggerated" way the behaviour I observe when being slightly out of reach, when I put the nrf51 paused in debug mode.

To check this, I put a scope probe on the VDD_PA of the nrf51822 (blue channel) and on the VDD_PA of my sensor with nRF21L01 (in yellow).

RE: nRF51822 / nRF24L01 compatibility with auto retransmission ?

Asbjørn — Mon, 23 Feb 2015 11:59:03 GMT

The pulses on VDD_PA that you see on the nRF51 is the ACKs being sent or ACKs for the re-transmits and you should see 1.8 V.

The ARD are defined differently on the nRF24L01 compared to nRF51. On nRF24L01 ARD is time after bit is sent, on the nRF51 it is the time from when the transmission started. So there's some slight differences in differences in setup.

You say that you can steadily re-produce this behavior if you keep the nRF51 paused in debug mode? So that as long as the nRF51 is in debug mode and paused, you will constantly get your sent payloads back to the nRF24L01?

RE: nRF51822 / nRF24L01 compatibility with auto retransmission ?

Landry — Wed, 18 Feb 2015 15:16:54 GMT

Dear Asbjørn ,

Thank you for your reply, I really appreciate and I apologize for not getting back to you sooner, but I wanted to have a try on your suggestions before and didn't get the opportunity to do it until now.

You are describing my problem correctly. I detect the reception, on the nRF24lL01 size, because I get a RX_DR flag, and when reading the pending received payload, it contains the packet I previously sent to TX fifo (again, in the nRF24L01, not the nRF51822).

The addresses I am using are default addresses (on 5 bytes): pipe 0 : 0xE7 E7 E7 E7 E7 pipe 1 : 0xC2 C2 C2 C2 C2 pipe 2 : 0xC3 pipe 3 : 0xC4 pipe 4 : 0xC5 pipe 5 : 0xC6

All sensors are using different addresses on only one pipe (pipe0), the other pipes being shut off. Same idea for the receiver but only pipes 6 and 7 are turned off, obviously.

I performed a few more tests today, placing breakpoints in functions nrf_esb_tx_success, nrf_esb_tx_failed and when calling nrf_esb_add_packet_to_tx_fifo in the nrf51822. Again the sensors keeps on receiving it's own packets when slightly out of range, still no breakpoint were triggered on the receiving side.

During this test, I had only one sensor. So no other device could be blamed for.

During the recording, when in range, the VDD_PA of NRF51822 is pulsing regularly (here it's pulsing at 9.14Hz, matching the sending frequency of my transmitter), but I assume it's the acknowledgement. Please tell me if this is not expected.

The strange thing is that I specified an ARD of 750µs and ART of 4 (for both transmitter and receiver), and when out of range I can sometimes see 8 pulses seperated by 1000µs (not 750µs ?), which seems to be the retransmissions. Furthermore, it's actually not always as regular as this. For instance, on the 100ms window I have right under my eyes on the scope now, I can see 17 irregular pulses, where I should have only two, maybe 5 considering max retransmissions.

I hope these additionnal elements will help you to enlighten some new leads, because for my concern, I'm a little confused.

Thank you very much,

Regards,

RE: nRF51822 / nRF24L01 compatibility with auto retransmission ?

Asbjørn — Fri, 02 Jan 2015 20:03:00 GMT

I'm having a really hard time understanding your problem as the description of the issue is not something that I've encountered before. If I understand you correctly you are receiving your own payload back on the nRF24L01 sometime when you are close to being out of range and the you have enable re-transmits? How do you detect the reception of the sent payload? Do you get a RX_DR indicating you got a new payload?

There's no reason for why the nRF51 should send the payload back to the nRF24L01 unless the received payload on the nRF51 is written to the TX FIFO and then re-sent with re-transmission ACK, but the ESB library won't do that unless you do that on your own.

What addresses are you using in your setup? Could it be that one of the other sensors are sending at the same time a different one is in RX to receive the ACK and hence it's receiving the other sensors data? If the nRF51822 is paused/halted in debug mode, it shouldn't be able to do anything, so I find it really strange that it's sending the receive payload back to the sensor in this mode.

It's a bit more complicated, but perhaps it would be beneficial to check who's actually sending. You can scope on the VDD_PA pin on the various sensors and the nRF51822. This pin will go up to 1.8 only when the chip is in radio TX mode. For the rest of the time, including radio RX, the VDD_PA pin will be 0 V. If you receive something and the VDD_PA pin on the nRF51822 is still 0 V, the payload/package wasn't sent from the nRF51822.