nrf24L01+ strange behaviour

Hello,

I trying to use nrf24L01+ modules, I used maniacbug library.
At first, with default helloword I got many send errors, but packets got received many times. So I feel it’s a problem with ack.
But the strange thing is, I tried to lower speed (250kbps) , and it got worse. so I tried 2Mbps and… it works with no errors at all !!!

I have an arduino nano and a duemilanove.

I tried lowering power, in case 3.3v on-board regulator is to weak. but did not change anything.

also tried coperland fork : GitHub - gcopeland/RF24: Arduino driver for nRF24L01, that work a bit better at 1Mbps but still not well.

Anyone got that kind of problem ?

But the strange thing is, I tried to lower speed (250kbps) , and it got worse. so I tried 2Mbps and... it works with no errors at all !!!

Try to put a cap 220uF in the 3.3V line.It improve the stability of the nrf Post results

with the cap, the arduino nano fail to communicate with rf24.. thNO still work, I will try with a good 3.3 voltage.

I got it working now, the cap is very useful to improve quality, but the problem had something good : I think the rf24 library does not calculate timeout right, and then it cuts too early. the formula used is : (retransmit count +1) x Retransmit Delay

it does not take actual transmission time into account. I came with a formula that match pretty well :

 (retransmit count +1) x ( Retransmit Delay +  (total message lenght + 10bits) / Datarate + 130us )

with total message length to be calculated from datasheet but max is 329 (58 bits + payload by default) if my calculation is good. 130us are for pll startup. for the 10bits, I don't know but it work well at any rate.

please note that the problem is with gcopeland fork, original manicbug version had 500ms which is far higher than the max message send duration (a bit less than 30ms on my calculations) . Anyway the timeout is there only to deal with local communication problem with the device which should never append. But in gcopeland version timeout is too small and reduce actual retries count.