Last characters received of last receive repeated n times in the following message about rf24 HOT 10 OPEN

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

from rf24.

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.

from rf24.

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).

from rf24.

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)

from rf24.

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.

from rf24.

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.

from rf24.

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

from rf24.

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

from rf24.

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

from rf24.

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

from rf24.