RE: Best timing accuracy between iOS device and peripheral device

tesc — Tue, 02 Feb 2016 13:26:01 GMT

Hi,

You will inevitably experience multiple delays from the initial call from the tx side application to when the message is received at the rx side application. You may also experience large differences in the delay (jitter).

You will have roughly the following sources for delay:

Preparing the packet
Waiting for transmission
Transmission time
Propagation delay
Reception operations
Propagating message to application

Points 1, 5 and 6 may take several ms on a smartphone, depending on system state. It varies from system to system, and I do not have the numbers for this. It would probably be best to test it yourself on the smartphone you are using. If you do it would be great if you could share your findings. Point 2 is on average half the connection interval. Point 3 can be calculated from BLE transmission rate and packet size. Point 4 is negligible due to the short range of BLE (signal propagates 10 meters in ~33 ns).

The initial suggestion was to let the smartphone write a characteristic on the nRF device. Using 1.5 ms as a rough estimate for the sum of transmission time and nRF side delays, and 10 ms average for waiting for transmission (20 ms connection interval), one would expect a delay of x + 11.5 ms, where x is the smartphone side delay. The jitter would be substantial (± 10 ms from connection interval, in addition to smartphone and nRF stack jitter.)

If the smartphone API signals the application when the BLE packet is sent, you can do better. Instead of points 1-3 adding to the delay and jitter, you will get a delay for propagating the signal of "packet sent" to the smartphone app. This would happen concurrently with reception related operations and propagation to application on the nRF side. In this scenario, time used for notifying the application on the nRF side (~1 ms range) is probably shorter than that on the smartphone side, meaning the nRF is triggered a few ms before the application on the smartphone. In any case you have eliminated the connection interval related delay and jitter.

Depending on your needs and on the application, you may have a look at algorithms for clock synchronisation similar to the one used for Network Time Protocol (NTP). The basic idea is packet exchanges back and forth between devices A and B, that are timestamped using the RX side clock on RX and the TX side clock on TX. The delay is assumed to behave the same in both directions, and an estimate is calculated for the time difference between the two clocks. When the clocks are synchronised, the devices can perform simultaneous actions. The synchronisation process is kept running (using a longer interval) to keep the clocks from drifting out of sync. The accuracy will often be high compared to network delay and jitter.

For other options, I suggest that you have a look at these other related questions:

Synchronisation with advertisement
Multiple Peripherals accepting a packet from Central (The questioner needs 1 ms accuracy.)
NRF51 time synchronize sensors
"synchronize" two devices

Regards, Terje