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

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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.

0 Likes
1 Solution

In the piconet, the master clock is also the network clock, and therefore all the slaves are sync to this clock, within the limits of their own clock drifts. The slaves are synced back to their master when they received a packet. You query may be addressed at firmware level (I guessed) but I don't think we have an API at apps level to do this.

View solution in original post

4 Replies
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

I am not sure whether can this be done from the application perspective. The smallest fine timer of the application is 12.5ms though.

BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

In a piconet, the master is actually in sync with its slaves with its clock and frequency-hopping pattern. Assuming only one packet is sent in one slot of 625us, then you will need a minimum of 1.25ms for a complete Tx and Rx. And you repeat this for the other two slaves, the turn around would be at least 3.75ms.

Anonymous
Not applicable

Hi btta

Thanks for the comment.  However, your answer above is not quite correct. "Assuming only one packet is sent in one slot of 625us, then you will need a minimum of 1.25ms for a complete Tx and Rx. And you repeat this for the other two slaves, the turn around would be at least 3.75ms"

Your answer indicates the transaction rate between a master and multiple slave devices.  But does not explain how to synchronize devices in Bluetooth --- which is what I am truly interested in.

I had to think about your answer for a few minutes as it almost made since, but consider the following idea.

SYNC EXAMPLE:

Suppose the master and the slave communicate their own local clocks (e.g. unsigned 16bit clocks) to each other.

Similar to what you quoted, the master and slave have a transaction rate = 4 millisec.

Whereby, the master receives the slave clock every 4 milliseconds, and the slave receives the master clock every 4 milliseconds.

Then in the interim between transactions, the master can readily estimate what the current slave clock is...

Current slave clock = last known slave clock  +  time duration after receiving slave clock.

Then as an engineer, I know the clock differences between multiple cpu's do not vary that much, let us say 5% drift every 4 milliseconds.

So Time Drift = 4 milliseconds * 0.05 = 0.2 milliseconds.

Thus based on transaction rate and drift...

one could synchronize clocks to 0.2 milliseconds between devices.

But this is not my issue related to Bluetooth.

The problem with Bluetooth is it has transaction overhead and arbitrary time in which transactions are transmitted.

The cpu may tell the Bluetooth module to transmit a message.  But the Bluetooth module will take a arbitrary amount of time, let us say 0.1ms to 10ms to transmit a message with a clock value in the payload.  And this would not allow me to sync devices.  This is my essential problem with Bluetooth.

Perhaps I'm mistaken.  Maybe I'm misinterpreting how Bluetooth works -- or maybe there is a Bluetooth sync function that will solve my problem.

   _

I hope yourself or fellow readers might comment for further understanding here.  --Ken

0 Likes

In the piconet, the master clock is also the network clock, and therefore all the slaves are sync to this clock, within the limits of their own clock drifts. The slaves are synced back to their master when they received a packet. You query may be addressed at firmware level (I guessed) but I don't think we have an API at apps level to do this.