Understanding Timer Synchronization with BLE, using LE Audio Features with Isochronous Channels?

[dmk_weber]

Hello Everyone,

For some time now I'm figuring out the best way to perform timer synchronization with µs-accuracy (+- 20 µ) between several BLE nodes in a star network with one Central and multiple Peripherals. 

In our current project we are using four BLE nodes equiped with the nRF52840 chip and the latest nRF Connect SDK version (2.6). We have one Central node, which is the time reference and three Peripheral nodes which will synchronize their clocks to the Central device, so that we can synchronize data acquisition. The peripheral nodes will acquire signals and send the data to the Central device, so that we need some bandwith for data and cannot afford to much packet overhead for synchronization.

There's a 8 year old post form Nordic on how to synchronize timer with proprietary radio packets (Link), which will be send when the BLE link layer has nothing to do. However this approach is not fesable for us because of various reasons.

With BLE 5.x it seems to be possible to use Isochronous Channels with LE Audio, which apparently can also be used for BLE time synchronization, according to this example code from Nordic (Link). Unfortunately I didn't really get the concept of the Isochronous Channels: According to this Webinar (Link) the Isochronous Channels are a parallel communication channel to the BLE service used in LE Audio, but it's not mentioned how this is done in detail.

I have multiple questions now:

• How is this done on the BLE link layer then? Is data transmission on the Isochronous Channels only performed, when there's no other packet transfer?
• Would this LE Audio approach of time synchronization als work in our setup, where we have to transmit sensor data alongside with synchronization / time data?
• Is there any other standardized time synchronization BLE service to date?
• What's the best way to perform time synchronization over BLE?

Thanks for helping me out.

Best Regards,

Dominik

[Amanda Hsieh]

Hi, 

How is this done on the BLE link layer then?

The short explanation is that incoming packets are timestamped. The timestamps are forwarded to the application as part of the isochronous data. The timestamps are used to set up timed triggers.

Is data transmission on the Isochronous Channels only performed, when there's no other packet transfer?

The time-sensitive data is transferred over the ISO channels. Other data (ATT) can be transferred over the normal Bluetooth link. When using CIS there is always an ACL connection + an ISO connection.

Would this LE Audio approach of time synchronization als work in our setup, where we have to transmit sensor data alongside with synchronization / time data?

The data that is sent over ISO channels has corresponding time data. Data that is sent over regular ACL Bluetooth Connections does not have synchronization/time data.

Is there any other standardized time synchronization BLE service to date?

No, this Bluetooth spec-defined way. 

What's the best way to perform time synchronization over BLE?

Bluetooth: ISO time synchronization demonstrates how to perform time synchronization over Bluetooth.

However, this question also depends on application requirements:

• How accurate do you want time synchronization to be?
• How often do you want to perform time synchronization?
• Is the timed/synchronized data flushable or not?
• Does the device network consist of Nordic devices only?

I hope these answers allow you to make a well-informed decision on how to proceed.

Regards,
Amanda H.

[dmk_weber]

Thanks for your reply Amanda. 

I still don't really get how the ISO channels are transmitted on the link layer. I'm totally aware of the concepts of Connection Intervals and Connection Events for the normal BLE link. I also found some information about the CIG/CIG and the ISO interval....

But when does the ISO interval happen when there is also a normal BLE link from a link layer point of view? I'm assuming that it's the same radio, so there is nothing going on in parallel... Is the ISO interval after the "normal" Connection Events within a Connection Interval? I'm asking this because the ISO channels might then affect throughput, when there is a lot of data to transmit within the Connection Events... (similar to the Timer Synchronization example from Nordic) Or are the ISO channels transmitted in a "normal" Connection Event?

Thanks!