nRF51 Softdevice Bluetooth Clock Access

[Austin Glaser]

I'm exploring the possibility of using an nRF51 for a simple device which must take data samples on a fixed clock and push them to a remote client. The issue I'm investigating is that of synchronization -- there will be several of these devices, and we want reasonably close (~10-50 ms) correlation between their respective data. I believe that I can get close to this number with a simple solution where the client periodically writes a profile characteristic with its current measured time in milliseconds, which the sensor then keeps track of and reports back with sample data. However, we then have to deal with latency, jitter, retries, and all the inherent inaccuracy that introduces which (according to some rough back-of-the-envelope calculations) could well exceed our timing tolerance.

While reading the BLE specification, I noticed that in fact there is a bluetooth clock, which specifically has to be synchronized with the master (in this case, the client and the 'master timekeeper' in our scheme) already.

My question, therefore, is this: Is it possible to query the softdevice for the current value of the bluetooth clock?

[Hung Bui]

Hi Austin,

The Bluetooth clock is a BR/EDR (Bluetooth classic) term, there is no such thing with BLE.

I am not sure I fully understand your requirement. Please correct me if I am wrong, you want to have several sensors sampling data at the same time (10-50ms correlation) ?

I'm thinking of keeping a realtime timer (RTC) on each sensors and synchronize them with the central by using central to write the central's time to all of them, then let them notification their current (updated) time back, check if the times are synced and within time correlation allowed or not. If not, update again. Then you only have to correct (sync) the time once for a while, depends on the accuracy of the RTC on each device.

Another option is to let the central device advertise and the sensor scan for the broadcast packet and start capturing when it receive the advertising packet. Then you have to establish the connection with each of them later on to collect data. This seems to be more complicated.

[Austin Glaser]

Ah, I must have been confused with the section of documentation I was reading. Thanks for correcting me on the clock issue.

You understand the requirement correctly, and my thoughts on a solution were similar to yours. I'm concerned with the latency required to set a characteristic on the sensor, and what innacuracies that will introduce when we need to use the transmitted value as a timestamp. We'll just have to evaluate through testing whether that solution is suitable.

Thank you!