I made it, because my NRF's seemed to work VERY slow. And they actually are! My output is something like : 31532448. We have to divide it by 1000 ( counter incrementations ), and divide once more for micros->milis. So one payload of 32 bytes is send every 32ms! This is ultraslow. Since the radios are set for 1Mbps so its 1000 times slower than it should be Any idea why?
EDIT :
I got something new : the transmitter sends message every 31600 or 31596 microseconds. This can not be a coincidence
Your transmitter code is completely unrealistic. It will be trying to send thousands of messages per second. I can't figure what your RX code is trying to do.
Thanks Robin for your rapid answer. My RX code calculates average delay between recieveing a message (gets 1000 samples, then write it on Serial). The problem is TX'sided - that's for sure. Well, sending thousands of messages per second is my objective actually. As far as I know, the radio.write() will hang loop() untill message is sent, so there shouldn't be any interruptions - in addition, the transmitter should just throw messages, as soon as possible. Im not sure if I know how to use full capabilities of these modules (2Mbps on air data rate). Could you help me since I'm not sure if your Tutorial cover this part?
Gosucherry:
Well, sending thousands of messages per second is my objective actually.
So start slow - perhaps 1 per second and prove that your timing measurement works. Then gradually reduce the interval between transmissions.
IIRC the round-trip time for a message and its acknowledgement is about 6 msecs.
And why not do the time measurement on the transmitting (or master) which is the device in control of the timing. Did you study the second example in my tutorial?
Ok. It was all about acknowledging system, which is reduntant in my project After setting "radio.setRetries(0,0);" and 2Mbps mode I've managed to send 32byte payloads every 740uS, and 1byte payloads every 527uS. Usually all messages comes, and there are no errors in transmission. Difference between sending 32 and 1 byte payload is fairly small. I'm not sure why the "setup" of TX state takes so long. I do not use 3-level TX FIFO buffer (ok, I use it, but only the very first level, so there is always only one transfer per going into TX State) which means my radio should go :
So lets see the timings here. Going from "Standby-I" to "TX Setting" requires CE=1 for at least 10uS, TX FIFO not empty and PRIM_RX=0. I dont think that it will ever take more than 50us. Going from "TX Setting" to "TX Mode" takes obviously max 130uS. TX Mode transmission (after first transmission we exit TX Mode since we have no more data in FIFO) takes times depending on size of payload, but lets say it will take 30uS for 1byte payload. Considering little delays in changes of states sending one byte payload should take 250-300uS MAX in this setup, yet it takes 530uS. Any idea why?
EDIT:
After disabling auto-ack the NRF's can send 1byte payload every 250uS which was expected value. 32byte payload will be sent every 457uS (those are averaged values calculated on 1000 samples). I've come very close to my target, so the topic can be considered closed
Gosucherry:
EDIT:
After disabling auto-ack the NRF's can send 1byte payload every 250uS which was expected value. 32byte payload will be sent every 457uS (those are averaged values calculated on 1000 samples). I've come very close to my target, so the topic can be considered closed
If you try using the nRF24s where there is intermittent radio interference you will appreciate the advantage of the auto-ack feature. Sending garbage fast is not much use.