RF24

RF24 copied to clipboard

Payload ack example does not work. Not sure if its a Arduino issue (v1.0.5) or the example code.

Would be more useful if you could provide more information about what happens, more than just "doesn't work".  Do the other examples work for you?

---

From: jaywilhelm [email protected] To: maniacbug/RF24 [email protected] Sent: Tuesday, June 11, 2013 4:58 PM Subject: [RF24] Payload ack example does not work (#21)

Payload ack example does not work. Not sure if its a Arduino issue (v1.0.5) or the example code. — Reply to this email directly or view it on GitHub.

I was using a pair of Teensy++ 2.0's and the payload ack example did not work (nRF24L01+, Arduino 1.0.5, and Teensyduino). When I switched to a pair of Arduino Uno's, the exampled worked. There seems to be an issue with Arduino and the Teensy++ 2.0 running at a higher clock rate. Looks like the MCU polls too quick on the Teensy.

Yes, I can confirm it. Although it is NOT on any way related to MCU clocking. Got that very bug when playing with my pure-c port of this library. It seems that RX_DR is set by the module AFTER other bits. This opens a window for a race condition when we've read the status, but RX_DR is not yet set, so we assume no ack payload available. Therefore the dirty solution is to wait a little bit (delay_ms(2)) in rf24_write before actually calling rf24_what_happened.
From the documentation it's unclear whether the ack payload can be lost in case of some interference (or bad luck). But the specs do state yet another possibility for the library to break: if the ack packet is lost, but payload arrives - we get only RX_DR, and the next retransmission screws us up (Double data?) Correct me if I'm wrong - I only got a few minutes worth reading the datasheet. Will be thinking about how to fix it tomorrow.

It looks like the RX_DR bit when ack payloads are available is set a few moments after TX_DS. Therefore it opens up a place for a race condition. I have observed it when working with my pure C port of your library on m328p (16Mhz crystal) and STM32 board running at 72Mhz. Basically it appears as if some packets come with no ack payloads attached to them. Adding a little polling loop fixed that for me, see https://github.com/nekromant/antares/blob/master/src/lib/wireless/rf24.c#L547 for details.