Latency question on NRF24

I am constructing an instrument that should collect data at 1,000Hz. The main unit is an RPI 3B+. It is connected to a number of nodes that have ATMEGA1284P and FT232R. I am trying to synchronize the data collection by sending "start" from RPI to all nodes at 1KHz.

Apparently the best way I can think of is to have an RPI digital pin going to all nodes to sync. But that means a big mess with wiring that reduces flexibility (say take one node out, add two more) in the field.

I've tried syncing over USB-UART by writing "start" to one USB serial port at a time. I am using 2Mb/s rate and each serial send seems to take about 0.04ms of CPU time. Not too bad but the best latency setting I can get for FT232R is 1ms, exactly on the 1KHz sampling frequency I'm trying to get. I was testing with software loop-back on ATMEGA1284 default 20ms latency setting and it wasn't good enough.

So I'm thinking. What about adding NRF24 modules to RPI and nodes? But what is the latency of NRF24? Does it have a broadcast mode (I vaguely remember there is). So my exact question is when NRF24 is on broadcast mode with little WiFi (2.4GHz) interference, what is the latency between you send a message to NRF24 and it sends it out?

If the answer is not very good, is there any other RF product that has better latency?

Thanks.

Any number of NRFs can listen to the same pipe address,
in this case you would normally use no acknowledgement.

IIRC there is a mode where the NRF transmits a preloaded packet by asserting a pin (see REUSE_TX_PL),
but loading a short packet via SPI does not take too long.

Great! I shall investigate this in case my USB serial port sync is not good enough. Another possible method that I have just come up with while writing this response is to try the DTR line. When a serial port is open, FT232R is supposed to assert DTR (making it LOW). I wonder how soon it does that. Will have to do a test with an FT232R adapter (how?). Following this route, I might be able to let FT232R assert a different line that is hardwired to my ATMEGA. Will have to find good way to test latency.

I did some testing on the DTR or RTS toggling latency. Noting that these toggling are still done over the USB, we should see something around a fraction of a millisecond. I did these tests:

  1. Toggle RTS and read CTS that is connected to RTS, on RPI. The average time is 0.9ms, not very good.
  2. Toggle RTS of 7 FT232R adapters, find the time between RTS transitioning on adapter 1 and RTS transitioning on adapter 7, using a logic analyzer. It took 2.1ms, so about 0.35ms to toggle one adapter's RTS. Having only 2 adapters I got 0.31ms, which is consistent.

So the verdict is that trying to sync over USB isn't good. I'll next test NRF24 modules. The multi-cast is a real life saver. I don't have to poll one device at a time.

liuzengqiang:
So the verdict is that trying to sync over USB isn't good.

USB does not perform well for small packages of data. This FTDI paper may be of interest

...R