RE: nRF51 Softdevice Bluetooth Clock Access

Austin Glaser — Thu, 21 Jan 2016 20:16:53 GMT

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!

RE: nRF51 Softdevice Bluetooth Clock Access

Hung Bui — Thu, 21 Jan 2016 12:20:12 GMT

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.