• State Not Answered
  • Replies 9 replies
  • Subscribers 63 subscribers
  • Views 5100 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 104831
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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,

Parents
  • 0

    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,

  • 0 in reply to Landry

    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.

Reply Children
No Data
Related