RF24 icon indicating copy to clipboard operation
RF24 copied to clipboard

Last characters received of last receive repeated n times in the following message

Open pierre83 opened this issue 10 years ago • 10 comments

Hello, I run this library and when there are transmission problems (i don't know exactly what) the last character of the last message is repeated n times (n = payload of the previous message) in the message following this previous one. The problem can be once a day or twice/hour, very erratic, all the rest of the sketch is running fine but nrf24 library stops receiving and talking. My configuration is last library version, nRF24+PA+LNA, Arduino 1.5.6-r2 or 1.0.5-r2 (I tried both) Let me know for more information. Pierre

pierre83 avatar Jul 02 '14 08:07 pierre83

Hi, We have received your e-mail and will get back to you within 24h, should you be having an emergency pls call me or sms your number to 082 22 11 00 5.

Peter Marynowski Cell: 082 22 11 00 5 Web: www.killarneynet.co.za Snr. Technician Killarney Community Internet KIC

PeterCuriosity avatar Jul 02 '14 08:07 PeterCuriosity

Thanks Peter,

----- Original Message ----- From: PeterCuriousity To: maniacbug/RF24 Cc: pierre83 Sent: Wednesday, July 02, 2014 10:54 AM Subject: Re: [RF24] Last characters received of last receive repeated n times in the following message (#49)

Hi, We have received your e-mail and will get back to you within 24h, should you be having an emergency pls call me or sms your number to 082 22 11 00 5.

Peter Marynowski Cell: 082 22 11 00 5 Web: www.killarneynet.co.za Snr. Technician Killarney Community Internet KIC — Reply to this email directly or view it on GitHub.

pierre83 avatar Jul 02 '14 12:07 pierre83

Did you make any progress with this? I have the same problem, apparently when there are collisions (I would have expected the CRC to catch this, if the h/w is correct and the library is correctly turning the CRC on when it says it is).

PeterSewell avatar Aug 14 '14 15:08 PeterSewell

Hello, I do not know if it can help you somehow, BUT when there is a problem with sending/receiving data, then it can stop running. Well, not stop running, but receiving data. The problem may be caused by the FULL RX_BUFFER. (I hope you still can follow my thought.) So, when the RX_BUFFER is full, the RF24 refuses all the incoming data. (I made some little change in my library.)

Look, the sender has a problem with getting an ACK from his recipient, which only means, that there was a problem receiving ACK, not getting data to recipient. So, it sends data multiple times - depending on the Automatic Retransmission Count. I know there is a function for getting info from the RF24 - radio.available(). Instead, I use something like this: if ( radio.rx_fifo_full() || radio.available() ) { // Process the data } Here is the code of "rx_fifo_full" (really simple):

uint8_t RF24::rx_fifo_full(void) { return ( read_register(FIFO_STATUS) & _BV(RX_FULL) ); }

BTW: do not forget to add the proper line to the header "RF24.h" into "public" section.

Best regard Simon Tomek (Sorry for bad English)

simontom avatar Aug 14 '14 16:08 simontom

There's a bug in this library (one of many). When you send something and the transmission fails, the payload is NOT removed from TX fifo. To do a proper retransmit without possibly receiving a dupe packet on the RX side you have to just assert CE for 10 uS. If you transmit the next paket - one gets stuck in TX fifo, and so on. So you end up with up to 3 packets stuck there. See my github, repo antares (src/lib/wireless/rf24.c) for the fixed version.

nekromant avatar Aug 14 '14 20:08 nekromant

Thanks, I'll give that a go. I suspect it's not the cause of the problem I'm seeing, though - I believe I have auto-ack and retransmission turned off. I've got two senders sending real-time data at around 100Hz on the same frequency and channel to a single receiver, in a setting where missed data due to collisions should just be discarded - I was expecting the CRC to do that. This payload-of-copies-of-the-last-byte-of-the-previous-payload looks like a more bizarre h/w or library error.

PeterSewell avatar Aug 14 '14 21:08 PeterSewell

Hi, i changed for a simple nrf24 (without antenna and pa/lna) and the problem disapeared. @Simon Tomeck : is your code working with multiple pipes ? Thanks

pierre83 avatar Aug 15 '14 22:08 pierre83

There is nothing that would not work. It only checks the RX_BUFFER inside the nRF24 and it solves the problem with apparently stuck nRF24.

Btw: @pierre83 : it is "Tomek" not "Tomeck" :-P

Best regard Simon Tomek

simontom avatar Aug 16 '14 07:08 simontom

Sorry Simon and thank you for your reply. I'll try your solution asap. Best regards Pierre

pierre83 avatar Aug 16 '14 08:08 pierre83

You are welcome. I hope it can help you. Look, you can edit the "available" function, but I did not do that this way. I prefer this way of checking the RX_BUFFER.

Best regard Simon Tomek

simontom avatar Aug 16 '14 09:08 simontom