Not receiving ACK payloads about rf24network HOT 25 CLOSED

The first thing that comes to mind is this issue where we corrected issues affecting mixed modules and the use of dynamic acks. The fix was merged into master 3 days ago, and should only affect users that are using a combination of different nrf modules. Just update RF24Network to test it out.

From there, if no luck, I would suggest testing with the included examples (helloworld_rx and tx) to see if the problem persists. If so, I would be very interested to know if there are any problems with the core RF24 examples like gettingstarted and gettingstarted_call_response sketches.

If only RF24Network is affected, maybe there is some other problem with acks?

from rf24network.

I am not really getting it, I need to dive into the library more, but definitely it worked ok after pulling the latest commits. Just like that.

But sometimes it fails. I mean in a very simple program and distance between them about 1m, once every 5-6 times.

EDIT: I watched over the two devices, with two OLEDs on them, continuously checking the result of bool ok = rf24Net.write( header, &payload, sizeof(payload) ); and they appear to lose lots of packets, by keeping them in this close distance. Of course capacitors are soldered on the Vcc/Gnd pins of the NRF modules.

from rf24network.

If they are overpowering each other, then you should notice an increase in reliability once they are at least a few meters apart, and running on separate power supplies (not grounded together).

It seems that if they need to operate in close proximity, the best option is to set teh PA level to RF24_PA_LOW or RF24_PA_MIN via radio.setPALevel(RF24_PA_MIN) ; after mesh.begin() or network.begin() , or this behaviour can sometimes be expected.

from rf24network.

Do we need to wait for some ms in order to receive the ACK packet ? Because it seems to me that bool ok = rf24Net.write( header, &payload, sizeof(payload) ); asks instantly for it. So do you think is sane to declare them separately (and how is this possible ?), meaning that the host writes data to the client, then waits for e.g. 50ms and then listens for the ACK packet? I've read somewhere that it usually takes 60-70ms in order to be received and If not, it returns a false value.

from rf24network.

Do we need to wait for some ms in order to receive the ACK packet ?

Not specifically, RF24Network will wait for acknowledgements as required.

Two forms of acknowledgement are used, the standard radio-ack (auto-ack) functionality for direct communication, and when payloads are routed across the network, software driven (network-acks) are used.

Users can control the behaviour of network acks by defining the payload type to use when constructing the header. A header type of 'M' (decimal value 77) will elicit a network ack from the delivering node to confirm delivery. A header type of '3' (decimal value 51) will not receive a network-ack.

One of the main uses of network-acks (beyond basic acknowledgements) is flow control, as it forces nodes to wait until delivery confirmation before initiating another send.

If two nodes are in direct communication (as with a master node (00) and first child (01) ), they will use the built-in radio auto-acks. The behaviour of network.write would be similar to a standard radio.write() using the RF24 driver, in that the function will wait until an ack is returned or the radio.setRetries() values are exceeded and it fails.

The retry intervals are staggered automatically, so devices in close proximity should use slightly different retry intervals.

Nodes that route traffic utilize software-driven acks (network acks), and will wait up to about 220ms for a response. ie: Node 011 routing traffic through node 01 to the master node (00) will wait for a network-ack if a user-defined payload type of 64-127 is used. It will not wait for a network ack if the user defined payload type is less than 64.

The write function will return false if it fails, or if a network ack fails to make it back. Duplicate payloads are a possibility if a number of retries are attempted, and network-acks fail.

from rf24network.

Sorry to open this again but I feel like I've tried everything but the issue continues. I can't manage to replicate the issue at anytime, it just happens randomly with different nRF24 modules (chinese and not) and two different kinds of PA ones. I have almost no loss in packets but the ACK packets are still false. I've also tried with different distances between them.

from rf24network.

That's the thing with fake modules. Use all fake or use all original, creating a mixed environment will cause problems. You could try implementing your own ACK system that works and don't rely on the chip's.

from rf24network.

@Avamander I've also tried them both in pairs but the same functionality continues. Also, I've ordered 20 of them, I can't just throw them away.

from rf24network.

There is nothing you can do if the chip is faulty and they just don't work together well. You can create an ACK system yourself and I'm quite certain there is nothing more to try. (I have the same problem, but I've got much smaller quantity of fake modules, hopefully one day I'll bother to replace them, any mixed setup did not work at all)

from rf24network.

Is there a chance I might have done something wrong with the code ? I have checked my files 1000 times. The same thing happens with helloworld rx/tx examples.

from rf24network.

If acks are working randomly, with various different hardware, mixed and/or matched modules, and with the included examples as well as your code, my guess would be interference or something.

Have you tried different frequencies/channels? Your initial post showed ch 90, so I would suggest trying the extreme far end of the spectrum (ch 1,2 or 3) and somewhere in the middle (ch 50 or so).

As above, RF24Network mainly uses the radio auto-acks so if this isn't working, I'm thinking you have problems at the physical layer (interference, etc.)

*edit to add: Either that or addressing problems...

from rf24network.

what is the channel range ?

from rf24network.

Channels are 1-127

from rf24network.

HI TMRh20. I am also receiving the same 'error' - that is payload getting delivered but getting false as a return value from network.write. I have downloaded the repo from github using git (as per instructions) yesterday. (11.12.2015)

As per your comments "I would suggest testing with the included examples (helloworld_rx and tx) to see if the problem persists". I have tested that and the problem also persists and am receiving (on the arduino end as transmiter) that the packet is not received. (RPi2 on the other end IS receiving the packet).

"If so, I would be very interested to know if there are any problems with the core RF24 examples like gettingstarted and gettingstarted_call_response":
Core RF24 library tested:

gettingstarted (Arduino as transmiter RPi2 as receiver) same result:
++On the arduino end++
failed
Failed, response timed out.
Now sending
++On RPi2 end++
Got payload(4) 8746156...
Got payload(4) 9978704...
Got payload(4) 11211216...

gettingstarted_call (Arduino as transmiter RPi2 as receiver) same result:
++On the arduino end++
Sending failed.
Now sending 1
Sending failed.
++On RPi2++
Loaded next response 2
Loaded next response 2

If there is anything i can please do contact me i would like to help solve this issue :)

PS. Both Arduino And RPi2 have the same model (from the same batch i bought) and have custom soldered tantalum capacitors 10uF ( even though when i measure with multimeter the arduino one says 15uF)

If i recall correctly i have tested this library in March i think and it was working correctly. (Only thing was that i had to change the RF24_PA_LOW to RF24_PA_MAX to get it working since on PA_LOW the RPi2 wasn't receiving packages. (gettingstarted RF24 example)

from rf24network.

Try the same between two Arduinos please. Also verify you have original
modules. Please report back what were the results.

from rf24network.

Hi,
I have bought mine from
http://www.ebay.com/usr/alice1101983?_trksid=p2057872.m2749.l2754 at around 8.6$ 10pcs
Meaning they probably are not genuine. Chip number is 1420JB

From here(https://devzone.nordicsemi.com/question/32755/difference-in-chips/) i learned that fake ones can have an AUTO-ACK problem.

2 Arduino uno's test is the same (actually discovered a faulty arduino pin(s) so i got a bit distracted)
One receives other says it didn't send.

While i'm at the subject where do you get nrf modules ? Since ebay and aliexpress seem to be full of 'bad clones' , are there any good clones (for me its ok if it spends a little more current but remains the auto ACK capability , also being stable is important as to not get taken by something like this (http://forum.mysensors.org/topic/1153/we-are-mostly-using-fake-nrf24l01-s-but-worse-fakes-are-emerging)

To sumize: Is there any way to get the Auto ACK capability on a clone NRF Module ? I have read somewhere that thats a "inverted ACK bit". If that was the case that would be fixable ?

from rf24network.

They are not even fakes. They are... something else, with a totally different chip. I bought two of them also and throw them to the trash. And they were European ones - the Chinese were 100% genuine.

from rf24network.

I detected the fake ones by looking at the thickness of the chip and size of the letters. Real ones have larger and more readable text and the chips are a bit thicker (as thick as the datasheet says) but the fake ones are lower.

from rf24network.

Not only this, they have something totally different written on them which of course requires you a magnifier lens to read it.

from rf24network.

Can someone recommend a good clone ? Or if not a place where one can buy relatively cheap nrf24l01 modules ? :) Since i need to get a new batch (of around 10pcs) and auto ack would come in handy :)

from rf24network.

Hi,

A simple question, did you try adding a small capacitor (10uF) between Vcc and GND on the NRF24 board? I got the exact same problem and this fixed all transmission issues I had.

Cheers

from rf24network.

Yes testing radio controllers have soldered capacitors.
UPDATE
When swapped arduino from UNO bought from ebay to UNO original BOTH Auto ACK on RPi and Auto ACK on arduino are working meaning the ebay bought NRF24 is working and DOES HAVE AUTO ACK. My issue now becomes double fold - fake arduinos don't receive the payload as stated here (nRF24/RF24#174) and also auto ack doesn't work with fake arduinos.

I have never heard of such an issue and would like to try and solve it with your help.

from rf24network.

Most probably there is no way to solve the issue. Other than either using software to emulate any functionality broken or replacing the modules.

from rf24network.

Modules are working good. AUTO ACK is working on those modules as well as send/receive functionality (Tested between original RPi2 and original UNO) problem becomes when ebay (fake) arduino's are brought into the picture. Probably a Hardware-software interface issue.

from rf24network.

@Sharan123 The modules are working good with same type. Otherwise you are right, combos of different modules (different and maybe faulty hardware) are a bad idea and only cause issues.

It seems that the original reason for this issue was resolved. Open a new issue or comment in one if you have separate issues.

from rf24network.