time synchronization of multiple nrf24s

[meyiao]

• Background Suppose we have 6 wireless inertial trackers, each tracker is composed of an arduino controller, an IMU sensor (like mpu9250), and a nrf24l01+ module. We put these sensors onto human body to do motion capture. Each tracker will send IMU data to a receiver at 100fps. When fusing these data to calculate human joint angles, timestamp synchronization is very important, especially when the motion is fast, several milliseconds time misalignment could lead to large joint angle error.

• Question Is it possible to achieve milliseconds or even microseconds level time synchronization? If possible, how to implement it? Any suggestions will be sincerely appreciated!

Thanks

[2bndy5]

The MulticieverDemo example is a good starter for general connection. However, the elapsed time for transmission would be tricky. See the docs for

• RF24::setAutoAck() (especially the important notes about data loss if disabling auto-ack)
• RF24::setRetries() (especially the delay parameter). This only applies when auto-ack is enabled.
• RF24::setCRCLength() can be useful to expedite the post-reception processing by the radio. This is force-enabled by the radio when using auto-ack.

Each tracker will send IMU data to a receiver at 100fps

You may find this difficult with any wireless solution (excluding the time it takes to get the data from the IMU sensor, assuming it uses I2C). The nRF24L01 requires 10 us to ramp up on first transmission. Therefore, use a less-blocking write*() (see writeBlocking() or writeFast()/txStandBy()) to avoid repeatedly waiting the mandated 10 us.

There's no definitive equation to optimize transmission time. You will have to play with the above configurable API and payload lengths to get the best solution for your application.

[TMRh20]

As Brendan advised you will probably want to disable auto ack and modify settings to reduce overall processing time etc.

In thinking about this, you could implement an algorithm that keeps track of the last received position and the timestamp. With the sending device sending at set intervals, you could determine with rough approximation, the general position of the device if a payload is missed, by looking at the current position of the device vs the position before and putting the missed position somewhere between the two. WIth auto-ack disabled and the devices in close proximity, you shouldn't miss too many payloads, but you can also extrapolate the details to a certain degree when payloads are missed.

[2bndy5]

Intervals is also a good idea because (as I forgot to mention) OTA collision can be caused when a transmitting device spams the receiver without a set interval (effectively hogging the specified channel).

[meyiao]

Thanks so much for your detailed explanation @TMRh20 @2bndy5, I'll do some experiment and post results here next week. But it seems that your advises are about how to achieve high speed many-to-one communications, could you also give some suggestions on how to achieve accurate time synchronization? I've found a blog from Nordic: https://devzone.nordicsemi.com/guides/short-range-guides/b/bluetooth-low-energy/posts/wireless-timer-synchronization-among-nrf5-devices , but I don't know whether it's suitable for nrf24s.

[2bndy5]

some suggestions on how to achieve accurate time synchronization?

The blog post's concept is applicable, but the Timeslots API does not apply to nRF24L01 (only nRF5x devices which are full blown SOCs). This means you have to come up with your own way of synchronizing clocks with a RTC peripherial or soft-implemented data. The sync data is usually handled as part of a handshake operation.

There's nothing specific to the RF24 lib or nRF24L01 transceivers that offer time sync functionality.

[meyiao]

Thanks @2bndy5 . Final question, how long will it take to send a packet, let's say, the time between these two events:

• calling write() function from transmitter,
• interrupt signal triggered on receiver

[2bndy5]

There's no definitive equation to calculate transmission time because it involves too many variables (including ambient temperature). You really do have to get your hands dirty to find the answers you seek.

[Dylan-Floyd]

You might consider using GPS modules just for getting time at each transceiver. GPS requires extremely accurate timing. If adding the modules isn't feasible, I would research how GPS achieves timing synchronization.

[2bndy5]

1. Setting aside the cost of adding a GPS sensor to each node, an accurate timestamp is only available after the GPS fix is established. This might make sense for a network of nodes that span large areas, but it doesn't make sense for tightly grouped nodes.
2. I doubt you can emulate how GPS time is caclulated without access to the GPS satelites.

Following the above 2 points brings us back to sending the timestamp from the master node to child nodes.

Also, to be clear, "time synchronization" doesn't have to refer to using UTC. If you wanted that, then I'd suggest using WiFi to get a timestamp from a NTP server. Still, it is more cost effective to have the timestamp transmitted from master node to child nodes.

[TMRh20]

I don't see why the sending nodes can't just use the other sending nodes signal as a timestamp. This is what I had in mind when I mentioned intervals. With AA disabled, each device can listen to the same address and use the transmissions of the other nodes to adjust its own timing signal. IMHO this would make for a fairly simple solution involving timed intervals.