Loss of connection between rf24 transmitter & receiver

[mikebyrne]

Loss of comms between nRF24L01+ transmitter and receiver after successful data transfer.

One rf24 is configured as a PTX (sensor device) communicating in a simple point-point link with a second in PRX mode (base unit) over pipe 0. Both are connected to a small

microcomputer (not an Arduino). Example Code used for them to ping-pong between each other works well. But modified code when used in this Tx ->Rx mode fails after a random period?

My intended operational mode is for the PTX to send a radio code when a sensor is triggered - which could be every few minutes to every few hours.  At first this works on the bench with

PTX and PRX side by side, but despite a sequence of successful transmissions over a period between 5 minutes to 30 minutes, the PTX generally freezes first, sometime it's the Base PRX

which freezes first.  So my code seems to work ok until it suddendly doesn't. As far as I can tell, my code correctly implements the RF24 state diagrams, the registers appear to be correctly 

configured and the TX-FIFO & RX-FIFO are flushed as necessary. After device power up I do leave the PTX in Tx mode and the PRX in Rx mode the whole time and don't set the

power-down but? This random freezing of communication suggests a timing issue somewhere, but I've tried various code modifications without success. 

Question: Could there be an un-documented issue with these radios that may explain the sudden freezing of communication after a sequence of good operation, or am I missing

sometime more obvious.  Your help would be greatly appreciated!

I can send the configs if there's not an obvious answer.

thanks

[Håkon Alseth]

Hi Mike,

 

I am glad to hear that the problems have disappeared!

 

mikebyrne said:

- in former “p_out()” subroutine (subr), I swopped the order of  the open_tx_pipe(A1) and stop_listening() subrs (so that Open now proceeds Stop).  I don’t know whether this had any effect, but please comment if it could have.

You normally want to configure the device before starting the specific mode (it being TX or RX). For this specific routine, it does not matter much.

 

mikebyrne said:

- the unnecessary CRC() subr was removed, with CRC for 2 bytes set in the init_radio() subr.

- I changed the any_rx() subr from interrupt scanning on the RX_EMPTY bit in FIFO_STATUS to scanning on the RX_DR bit in STATUS.

- in former “p_in()” subr, I (a) swopped the order of  the open_tx_pipe(A1) and stop_listening() subrs (so that Open now proceeds Stop), (b) added a check on the received packet length to be <32 bytes using R_RX_PL_WID with a break out of the infinite loop if >32, (c) encapsulated the Receive() subr  in a loop testing for more than 1 received payload per interrupt  .. by using a loop test on RX_EMPTY in FIFO_STATUS.

I therefore note that for my code to have started working, is that my PTX completes a (PWR_UP & PTX) state mode followed by a (PWR_DOWN & PRX) state mode cycle.  Whereas my PRX always stays in a (PWR_UP & PRX) state mode.  Of course, it’s possible that further code modification might also be successful, but I don’t have the time to explore further.

Thank you again for your detailed interest and help!!

 Always happy to help!

Good to hear that you added checks for handling the dynamic payload approach. This will save you debugging hours in the future.

 

mikebyrne said:

PS – once my particular nRF24L01+ application has been completed, I might investigate using some of your other similar products, so I would find a copy of your algorithm for the C based API for the whole nRF24L-series devices very helpful if your offer is still valid.

 Its just a simplistic API, and the real work is getting the logic up-and-running, with catching the corner-cases (like >32 byte payload), which the API does not show. I would recommend that you stick with the setup that you already have running, and rather contact us if any issues/questions  pop up.

 

Cheers,

Håkon