Due to the results of my previous post (Slower nRF24L01 round trip delay than expected) I found out that it will be quite difficult to reach my latency requirements.

I am thinking about using my own protocol (instead of the 6-1 Multiceiver protocol), but that would involve getting some kind of 'clocked' receive and send times for devices, which will not make it simple probably. The time to change from reading to writing is less than expected (startListening takes max 350 us and stopListening 450 us). However, if I need to do this ever 5 ms and making sure no devices are reading/sending to others, that's quite a bit of downtime.

So I was thinking, would it be a good (or stupid) idea to use TWO nRF24L01's per Arduino, one by default in reading mode, the other on writing mode (thus having bidirectional communication) and using two different channels. This means I never have to switch between reading and writing and can read/write simultaneously without message colliding.

(note: later I want to use multiple Arduinos and one STM32 device).

Does anyone see problems in this idea?

Requirement goals:

  • Latency: less than 10 ms to send it from device A to B, process it (excluded, takes a few ms) and send back from B to A (or in some cases B to C). Less than 10 ms is better.
  • Amount of messages: can be theoretically hundreds per second, in practice max 100 (from various devices, but all go through a processor-device).
  • Payload per message: 16 bytes probably, most are shorter, some are longer but I can split or combine them if needed.
  • Range: about 10 meters max, but in a music/band stage environments
  • Channels: I will not use the WIFI channels, but a range of others, also (professional) wireless mics do not work on 2.4 GHz, so I don't expect too many problems.

About channels: I don't expect any problems. I should have enough channels between 2.484 and 2.525 GHz. This gives me about 40 channels for 1 mbps or 20channels for 2 mbps to chose from.

  • 1
    What is your overall wireless communications goal? Bandwidth, latency, etc? NRF24L01 might be 2 Mbps (bitrate) but my guess is that 1-2 KBps is somewhat the limit. They are fine/designed for short and less frequent messages such as from a wireless mouse, e.g. 20 ms update frequency, 16-32 byte payload. Also you might want to try changing channel to avoid noise (message drops) due to WiFi. Commented Aug 1, 2017 at 8:51
  • @MikaelPatel I improved my answer, I think 1-2 KBps would be sufficient, 20 ms is way too long for my needs, payload can vary. I thought I wouldn't have problems with WIFI, I could do an occasional channel check though. Commented Aug 1, 2017 at 9:04
  • @MikaelPatel from 2.484 to 2.525GHz. I should have enough channels (sources: en.wikipedia.org/wiki/List_of_WLAN_channels#Most_countries, first table with red/green items, 2.525: nordicsemi.com/chi/content/download/2730/34105/file/… paragraph 6.3. This gives me about 40 channels for 1 mbps or 20channels for 2 mbps to chose from. Commented Aug 1, 2017 at 9:11
  • 1
    I can see no reason not to use two nRFs concurrently. You may want to turn off auto-ACK and use Enhanced ShockBurst mode though to get better throughput.
    – Majenko
    Commented Aug 1, 2017 at 10:01
  • @Majenko ... that sounds good ... I was already planning to switch off auto-Ack (actually all ACK) and implement the 'ACK' myself. I have to check into Enhanced ShockBurst (if that is the 6-1 Multiceiver idea I will use it). Commented Aug 1, 2017 at 10:08

1 Answer 1


At 2 Mbps, a 32-byte packet (40 bytes with preamble, addresses, CRC) will be approx 160 microseconds long. The round-trip time is likely to be much longer, since the microcontroller or radio will need additional time delays for auto-retry, sending and receiving the response packet, PLL lock, reading the data registers, etc. In my experience a 2 ms round trip is possible, and the best way to do that is make use of the nRF built-in features:

-- IRQ interrupt: interrupts = fast

-- Enhanced Shockburst: this automatically handles lost packets and failed transmissions. You can't get that capability any faster via the microcontroller coding.

On top of this, there is scope to use fast SPI libraries (or use SPDR/SPCR registers directly) to transfer data to and from the radio module. If speed is your goal, don't rely on plug-and-play libraries that others have written. Read the data sheets carefully and minimize unnecessary delays within the Arduino code.

  • I deviated my project slightly, so I will not use nRF's for the time being, and if so, probably on STM32, not Arduino, but good to know it's better to use the builtin way. Commented Aug 27, 2018 at 8:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.