This can improve transmission many times better!

[eos1d3]

During the previous test, I accidentally found out there is a huge problem inherent from maniacbug. In RF24::write mehtod, there is

while( ! ( get_status() & ( _BV(TX_DS) | _BV(MAX_RT) )))

During my tests, the way of testing DS or RT must not be done in this way. It has to test the IRQ pin instead for crazily use of SPI to read STATUS from nRF24L.

From what I found, I believe the massive SPI reading will make nRF24L very unstable (in term of chip busy, voltage fluctuation and noise). With this way of reading, I find there are various different package loss:

1. Clones of nRF24L01+ (SI24R1) modules, there is 90% package loss with PA level using MAX. (Using HIGH will be a less error, but still a lot)
2. Two real nRF24L01+ modules, both has high package loss with PA level using MAX or even cannot transmit at all. And using HIGH PA will help a lot.
3. One real nRF24L01+ which is very good in quality. It will get 1 or 2 package loss in 10K of transaction for any HIGH or MAX PA level.

Now, by implementing IRQ testing and loop only the IRQ pin test without crazy SPI reading, and then follow by ONE get_status to read the TX_DS or MAX_RT status. The above 3 types of modules can do transactions of ping-ping test of more millions of times without causing a package loss!!!

And before, my codes is sensitive to interference. Apple Magic Mouse and Keyboard will easy cause package loss during test. And now, I can turn on my mac and test for a whole day without any error.

The effect is HUGE HUGE difference.

Why I can find this problem is because I got the boards and modules from China re-sellers. And they came with software demos. I found their codes can transmit without package loss while my code create a lot of error. After long time of testing, by adding IRQ pin test before reading STATUS, the transmission is just perfect!

I have a lot different modules and tested with these results.

[TMRh20]

Issues with other libraries are not issues with this library.

See https://github.com/TMRh20/RF24/blob/master/RF24.cpp#L53
&
nRF24/RF24Network#72

[Avamander]

@TMRh20 Did I misread the issue? Because this is about RF24 and this fork.

[eos1d3]

Thanks for pointing out the use of 5us delay in csn.

I simulated the use of delay with my codes and without using IRQ pin test. And test results show the delay helps nothing. I have one poor nRF24L01+ module which cannot transmit anything with 5us delay. But with IRQ pin test, it works fine. (Note: If your module is good quality, you may not able to find the problem, And it is better to setRetries(0,0) during test)

This comment is not invalid for this fork. The write method uses the following loop and will create unstable condition for the nRF24L01+. This is confirmed by another test. The use of IRQ pin test gains huge difference!

while( ! ( get_status() & ( _BV(TX_DS) | _BV(MAX_RT) ))) {

[TMRh20]

@Avamander I don't know? It seems to me that this fork supports interrupts/IRQ and the 5uS delay is there to minimize SPI polling per the above issue.

ie: The above problems should not be an issue in this library if used correctly.

[TMRh20]

@eos1d3

I simulated the use of delay with my codes and without using IRQ pin test.

If you can demonstrate a problem with this library, I would be glad to look at it in detail.