• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 7481 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Methods for Synchronization in BLE

CM2015
Expert 1060 points

I'm looking into how (very precise microsecond) synchronization in BLE among (slave) nodes might be possible and I've come up with a couple ideas. I'm hoping I can get some input on what looks achievable/unlikely.

1) Advertiser mode: One node acts in advertisement mode to broadcast a 'synchronization' packet with the other nodes (to be synchronized with eachother, the broadcaster node remains unsynchronized) listening. Broadcast packets are assumed to be received by all nodes at approximately the same time. Upon reception of a packet, a node immediately saves its current local time and then adjusts it to be 0 (in the case that after the packet is processed it is found out to be not a synchronization packet, the time can be reset by knowing the saved time.)

Problems/Questions

1a) Do the listening nodes actually receive the packet at the same time? In classic BT this appears to be yes but in BLE it sounds as if the listening nodes are searching over 3 different frequencies which would mean the synch packet might arrive at different times to each of the nodes which would ruin this approach

2a) Connectionless approach...no encryption...Also, would appear that in actual usage the system would alternate between advertisement mode (to get synchronized) and then connection mode (where the slaves transfer data back to the master), not sure how feasible this really is..

3a) Other nearby advertisers could lead to a lot of disruptions in this scenario, perhaps nodes should be synchronized coarsely at first (inside of a connection) which then allows scheduling a fine grain synchronization afterwards?

2) Connection Mode: Say there are 2 nodes to be synchronized with eachother. Node 1 would send a time stamp (created at a low level to avoid delays) to node 2. Node 1 would then immediately send a second time stamp to node 2(to account for the sending delays). Node 2 would use both time stamps (and possibly reception time stamps of its own to compensate for reception delays) to synchronize itself to Node 1.

Problems

2a) Possibly lots of variable delays introduced in this method...Can low level time stamping be easily done with the BLE stack or will it require significant firmware modifications?

Any help or info anyone can provide would be great.

Thanks

  • 0
    TI__Genius 9325 points

    Hi CM2015,

    On Link Layer, time accuracy is very important because connection events are precisely time synchronized. However, since BLE requires up to 500 ppm sleep clock accuracy for both master and slave, 1000 ppm error should be considered by slave at every connection event in the worst case. Therefore, depending on the adv interval or the connection event period, timing error can be up to a few milliseconds. Plus, we cannot predetermine the time latency between the reception of the packet at the link layer and notification to the application because TI BLE stack and application run on priority based multi task environment like OSAL or TI-RTOS. Inserting time stamp info into a packet on Link Layer is impossible within the standard. I don't think microsecond-precise timing synchronization is feasible in BLE.

    - Cetri

  • 0 in reply to Cetri
    Expert 1060 points

    Hi Cetri, thanks for the reply. I think I agree, microsecond precision synchronization is not feasible in the BLE AS IS but I do think with some modifications to the link layer it could be achievable.

    Looking at the BLE Core spec timing requirements, during packet transmission the clock timings will be no more than 2 microseconds from the average timing and thus the start of a packet will be transmitted 150+/- 2microseconds after the end of the previous packet. If we can modify the stack to leverage this info, it seems like we should be able to achieve ~microsecond synchronizations but maybe I'm misunderstanding here.

    The alternative is modifying the stack to insert link layer time stamps and exchanging those messages. 

    Both these approaches have their complexities, and I'm not familiar enough with the stack yet to say if they are truly achievable. On first glance what are your thoughts?

    regards,

    CM

  • 0 in reply to Cetri
    Expert 1790 points
    The Bluetooth organization, in the "HDP Implementation Guidance Whitepaper" documents a CSP "Clock Synchronization Protocol" which is an optional part (but useable separately) part of HDP. (CSP may also be described under MCAP?) The CSP seems to allow clock synch to a few uSec.

    Is the CSP only doable in regular BR/EDR Bluetooth, i.e. not in Bluetooth Low Energy?

    Do any of the TI Bluetooth stacks implement the CSP? Or is that left to the application programmer?

    CSP uses connections (the second alternative described by the original post, i.e. it doesn't work for Broadcast/Observer.) Note that CSP in the high resolution mode (to uSec) requires access from higher layers of the stack to the Bluetooth Clock in the lower layers, via a function in the HCI. If there is such a function in the HCI, I suppose it only makes sense in the context of a connection.

    I wish TI had a white paper describing clock synchronization solutions.