This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How can 4 devices in a Bluetooth piconet remain time synchronized to within 1 millisecond of each other?

I have 4 devices communicating in a Bluetooth piconet, where 1 device is the master device and 3 devices are slave devices.

I want to time synchronize the 4 devices to within 1 millisecond using Bluetooth communication.

To do this, each device would share and/or compute a "common" time clock such that all devices can be time synchronized for other tasks e.g. infrared data communication, etc.

-Ken Software Engineer

Parents
  • In theory: Both, master and slave keep a 16 bit counter that is incremented with every connection event. A master could sample it's clock just when sending out a write request/command to a slaves characteristic together with this connection event counter (connEventCounter). When a slave receives that write request it can check whether it has the same counter value or not. If the counter value in the write request is the same as in the slave's link layer, the link can apply the received time (possibly adjusted by the time it toke to transmit the request). If the counters are not equal, the first attempt to transmit the request failed and the slave received a request that was at least resend once. In this case, the client should ignore the request.

    In praxis: It will be hard or impossible to get access to the link layers internal counters. But actually it's not the counters that are needed, but the information, how long the a request was on the fly. Maybe hooking into the radio events could yield the information if a PDU was resend or not.

    The SD provides an API (Chapter 11 Radio Notification) that provides notifications to the application before the radio will become active. This could be used by the server to sample the clock.

Reply
  • In theory: Both, master and slave keep a 16 bit counter that is incremented with every connection event. A master could sample it's clock just when sending out a write request/command to a slaves characteristic together with this connection event counter (connEventCounter). When a slave receives that write request it can check whether it has the same counter value or not. If the counter value in the write request is the same as in the slave's link layer, the link can apply the received time (possibly adjusted by the time it toke to transmit the request). If the counters are not equal, the first attempt to transmit the request failed and the slave received a request that was at least resend once. In this case, the client should ignore the request.

    In praxis: It will be hard or impossible to get access to the link layers internal counters. But actually it's not the counters that are needed, but the information, how long the a request was on the fly. Maybe hooking into the radio events could yield the information if a PDU was resend or not.

    The SD provides an API (Chapter 11 Radio Notification) that provides notifications to the application before the radio will become active. This could be used by the server to sample the clock.

Children
Related