nRF51822 / nRF24L01 compatibility with auto retransmission ?

[Landry]

Hi,

We are upgrading our main product which was until now based on nRF24L01 to nRF51822, with software library. But as the firmware implementation is mostly completed, I've discovered 2 unexpected behaviors I would be glad you explain.

An array of 6 sensors with nrf24L01 (in emission) is recorded on a device composed of a nrf51822. But it seems that the nRF51822 is sending back some of the data received to the sensor, and the nrf24 occasionaly get it's payload back. It's not a behaviour implemented on my mcu (at least I didn't intend to), and it didn't occured when I had the nrf24L01 on the recorder.

It seems to happen only when there are retransmission to be done, and the sensor is on the verge of loosing the connection with the recorder. I use the internal auto ART (4max) / ARD (750µs) management system, payload size being 32.

Is it something known, and if so is there a workaround ?

Due to some memory issues, I'm not using the last release of nrf51822 sofware library, and I kept the SDK in version 5.2.0.39364, with esb_sd_resources_arm lib

A second problem I've noticed is that when in rx mode, writing a payload (to be send as ack_payload) while specifying NRF_PACKET_NO_ACK, I still execute the nrf_esb_tx_success handler in the nrf51822 when the nrf24 in TX mode receives the ackpayload. Is that something expected ?

edit of december the 16th:

I've made a bunch of other tests today that have confirmed several points I suspected :

• There is no order from my main mcu to send back the received packet to the nrf.
• The nrf24L01 transmitter seems not to be blamed, because it doesn't receive its own packet when the nrf51822 is shut off.
• However, it sporadically receive its last packet when running and being slightly out of range.
• Auto Retransmissions mechanism seems concerned since it's mandatory to have some kind of packet loss, and when transmitter ART/ARD register set to 0 on nRF24L01 side, no problem appears.
• Each and every of my packets are forwarded back to the nRF24L01 when the NRF51822 is paused (debug mode in my Keil µVison IDE)

I should be able to handle this by upgrading the firmware of every sensors so that it became compliant with the new receiver, but it's really frustrating to have every customers of ours going through such a procedure, for such minor a thing...

I hope you could brighten this up and guide me through a way to avoid this behaviour.

Thank you for your help and concern,

Regards,

[Asbjørn]

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.

[Landry]

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,

[Jonas Hoefer]

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.

[Simonr]

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