Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Changing SPI speed #19
Edit 24 minutes later. I did find that the SPI clock speed is also set in SPI.h, so maybe that is overriding the NRFLite.h, which is being included after SPI.h? Hmmmm. Also included code, which is being run on Teensy 3.2.
dparson55 edit: fixed the code block formatting so I could read it. 3 back ticks were needed for the multi-line code blocks.
Thanks for the absolutely jaw dropping great library, nice work!!!!
Well shoot, I made a change to the library recently to fix Issue 18 and maybe this caused the problem you are now seeing. Unfortunately this issue was also related to my attempt to help support the Teensy architecture so maybe I fixed it for one person's situation, but broke it for yours. I don't have one of these for testing, so adding Teensy support looks to be problematic.
For adjusting the SPI clock speed, NRF_SPICLOCK is used in https://github.com/dparson55/NRFLite/blob/master/src/NRFLite.cpp#L526 and this is supposed to override any default value assigned in the Arduino SPI library and also override changes other libraries make prior to their usage of the SPI bus (which was issue 18).
Try commenting out the beginTransaction and endTransaction lines so whatever default values the Arduino SPI library is using for the Teensy are preserved. You can also try lowering the NRF_SPICLOCK to 1000000 in case 4000000 (or any other values you have tried) are unsupported on the Teensy for some reason.
Thanks for the note about the 8MHz clock speed being too high based on the capacitive load placed on the crystal. I didn't notice the other tables in the datasheet that showed the max SPI clock being as low as 4MHz, e.g. table 27. I will get this fixed but will wait to hear back from you about the additional SPI troubleshooting.
Thanks for taking the time to look at the problem. I can take a look at problem on my end this weekend and get back to you by Monday latest.
I'll dig into the datasheet of whatever microncontroller the Teensy uses this weekend as well. Maybe manually controlling one of its registers to set its SPI speed is something else that can be tried.
Great info about your ack packet situation as well. Your bad experience with the automatic ack data packets makes perfect sense when so many nodes are involved. Internally the nRF24L01 switches between TX and RX operation each time a REQUIRE_ACK send is performed, and even though it does this much quicker than doing it via the library, having to switch hundreds of times would cause all sorts of packet loss. The radio will retry each send 16 times as well, each time having to switch between TX and RX operation. So it is no wonder why the ack data packets did not work for your situation, what you did to manually control the TX and RX mode is perfect, great work!