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

Do RF24 radios need a physical reboot every few minutes to maintain a communication link?

Other than busy Nordic engineers (which I welcome a response from of course), is there anybody on this web site that understands how the RF24 radios work please?

I'm trying to use two nRF24L01+ in a simple point-point link, where one is the primary transmitter (PTX) and the other is the primary receiver (PRX). The PTX is expected to send just a few brief transmissions every day.  So far, after dozens of microcomputer code version attempts, the link between them always fails at a random point between 10 and 50 minutes, always after an initial series of successful transmissions.

Obviously, I suspect that my coding is not 100% correct, but until someone can help point me in the direction to solve any coding issue, I wonder whether there's a basic reason for the RF24 link to fail in this way.  So I would welcome an experienced radio person to answer the following simple brief questions, which may help guide me:

The following might seem like silly/provocative questions, but I'm out of coding ideas and wonder whether its a "feature" of the RF24s.

1) Do RF24 transceivers need a regular physical re-boot to maintain their radio link?  And if so how often?

2) If either the PTX or PRX  freezes after first working successfully,should just the failing unit be physically rebooted to re-new the communication link, or do both have to be rebooted? I  have experienced both scenarios but neither helps to keep the link going for more than 10-30 minutes.

3) Once the link has frozen, should both PTX and PRX be powered up together - might this improve some sort of initial synchronization?

4) Although I've set these units up as a dedicated PTX or PRX, should I change this so that *both* actively send/receive a heat-beat transmission to each other on a short regular basis just to  keep their link alive?  I.e. is it a requirement for a regular directional exchange?

5) If RF24s aren't capable of maintaining a low-activity communications link over long periods of time (i.e. 24 hours or more), is there a another radio transceiver that would be suitable?

6) Does there exist example microcomputer coding for a simple point-point link for RF24s ? I've seen example *subroutine* coding on the internet, but nothing that shows how to use those subroutines for a  non-Arduino microcomputer.

I did recently submit my coding issue via the ticket "Loss of connection between rf24 transmitter & receiver", which I hope might still get answered when the Nordic engineers have the time.

if someone could spare a few minutes to help me I would be very grateful.

Kind Regards

Mike

Parents
  • Hi Kenneth,

    Thank you again for your comments.  To answer your points:

    i) OK - I'm pleased to hear that  regular resets are NOT needed for continued communication between the RF24s. This means that it's my code that is at fault.

    ii) No, my code has not been using R_RX_PL_WID to check packet width, even though my code only ever transmits 3 or 4 bytes, but I will now add this check into my receive subroutines  in case an event somehow produces > 32 bytes.

    iii) As my setup is purely one PTX and one PRX, they use pipe0 only with the same address (as per the data sheet).

    iv) My code doesn't need to actively read the pipe information in STATUS because of point iii above.

    v) I will also re-code to reflect the full RX handling procedure described in the RF24 datasheet's table 27, STATUS register footnote (c), which I realise now I didn't implement fully.

    I'll try the above code modifications and let you know how I get on.

    Kind Regards & Thanks again!

    Mike Byrne

Reply
  • Hi Kenneth,

    Thank you again for your comments.  To answer your points:

    i) OK - I'm pleased to hear that  regular resets are NOT needed for continued communication between the RF24s. This means that it's my code that is at fault.

    ii) No, my code has not been using R_RX_PL_WID to check packet width, even though my code only ever transmits 3 or 4 bytes, but I will now add this check into my receive subroutines  in case an event somehow produces > 32 bytes.

    iii) As my setup is purely one PTX and one PRX, they use pipe0 only with the same address (as per the data sheet).

    iv) My code doesn't need to actively read the pipe information in STATUS because of point iii above.

    v) I will also re-code to reflect the full RX handling procedure described in the RF24 datasheet's table 27, STATUS register footnote (c), which I realise now I didn't implement fully.

    I'll try the above code modifications and let you know how I get on.

    Kind Regards & Thanks again!

    Mike Byrne

Children
Related