In a FHSS system like Bluetooth, how is synchronization to the hopping sequence done? For example, for a specific hop sequence, is a special code sent at the beginning of a frame on the initial hop channel by the FHSS "master" and all slaves listen in and synchronise? Is short-term stabilty assumed good enough that synchronization can be mantained through all channels in the hopping sequence, or do the slaves synchronize at the beginning of each channel? Am I making sense? -- Randy Yates Embedded Linux Developer http://www.garnerundergroundinc.com
Timing Synchronization in FHSS Systems
Started by ●October 31, 2018
Reply by ●October 31, 20182018-10-31
Randy Yates <randyy@garnerundergroundinc.com> wrote:>In a FHSS system like Bluetooth, how is synchronization to the >hopping sequence done? > >For example, for a specific hop sequence, is a special code sent at the >beginning of a frame on the initial hop channel by the FHSS "master" and >all slaves listen in and synchronise? Is short-term stabilty assumed >good enough that synchronization can be mantained through all channels >in the hopping sequence, or do the slaves synchronize at the beginning >of each channel? > >Am I making sense?You're making sense. Yes, no, and yes. In Bluetooth frequency hopping is determined by the master, occurs only between packets, and each packet contains a header to which one synchronizes. So you're not in the situation where the hopping timing is on the same order as the baud timing. It is not that critical. Steve
Reply by ●November 1, 20182018-11-01
spope384@gmail.com (Steve Pope) writes:> Randy Yates <randyy@garnerundergroundinc.com> wrote: > >>In a FHSS system like Bluetooth, how is synchronization to the >>hopping sequence done? >> >>For example, for a specific hop sequence, is a special code sent at the >>beginning of a frame on the initial hop channel by the FHSS "master" and >>all slaves listen in and synchronise? Is short-term stabilty assumed >>good enough that synchronization can be mantained through all channels >>in the hopping sequence, or do the slaves synchronize at the beginning >>of each channel? >> >>Am I making sense? > > You're making sense. Yes, no, and yes. In Bluetooth frequency hopping > is determined by the master, occurs only between packets, and each packet > contains a header to which one synchronizes. > > So you're not in the situation where the hopping timing is on > the same order as the baud timing. It is not that critical. > > SteveSo each packet within a frequency hop channel gets a synchronization preamble/header? All "slaves" are constantly listening for the preamble and if a good header is decoded, and find they are being addressed, respond appropriately? That's makes a lot of sense, simple and effective. Thanks Steve. -- Randy Yates, DSP/Embedded Firmware Developer Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●November 7, 20182018-11-07
onsdag den 31. oktober 2018 kl. 15.37.35 UTC+1 skrev Randy Yates:> In a FHSS system like Bluetooth, how is synchronization to the > hopping sequence done? > > For example, for a specific hop sequence, is a special code sent at the > beginning of a frame on the initial hop channel by the FHSS "master" and > all slaves listen in and synchronise? Is short-term stabilty assumed > good enough that synchronization can be mantained through all channels > in the hopping sequence, or do the slaves synchronize at the beginning > of each channel? > > Am I making sense? > --every packet has a preamble and accessword you use to find the start of packet, once they are connected a slave maintain a copy of the master clock and can calculate what the next frequency is from that afair it's been 15 years since I did bluetooth
Reply by ●November 7, 20182018-11-07
<lasselangwadtchristensen@gmail.com> wrote:>onsdag den 31. oktober 2018 kl. 15.37.35 UTC+1 skrev Randy Yates:>> In a FHSS system like Bluetooth, how is synchronization to the >> hopping sequence done? >> >> For example, for a specific hop sequence, is a special code sent at the >> beginning of a frame on the initial hop channel by the FHSS "master" and >> all slaves listen in and synchronise? Is short-term stabilty assumed >> good enough that synchronization can be mantained through all channels >> in the hopping sequence, or do the slaves synchronize at the beginning >> of each channel? >> >> Am I making sense?>every packet has a preamble and accessword you use to find the start of >packet, once they are connected a slave maintain a copy of the master >clock and can calculate what the next frequency is from that > >afair it's been 15 years since I did bluetoothThe part I have difficulty understanding is, when a slave fails to receive and decode a packet, or at least the header of a packet, does that throw the slave's hopping timing off? Or can it recover? Steve
Reply by ●November 8, 20182018-11-08
torsdag den 8. november 2018 kl. 04.39.19 UTC+1 skrev Steve Pope:> <lasselangwadtchristensen@gmail.com> wrote: > > >onsdag den 31. oktober 2018 kl. 15.37.35 UTC+1 skrev Randy Yates: > > >> In a FHSS system like Bluetooth, how is synchronization to the > >> hopping sequence done? > >> > >> For example, for a specific hop sequence, is a special code sent at the > >> beginning of a frame on the initial hop channel by the FHSS "master" and > >> all slaves listen in and synchronise? Is short-term stabilty assumed > >> good enough that synchronization can be mantained through all channels > >> in the hopping sequence, or do the slaves synchronize at the beginning > >> of each channel? > >> > >> Am I making sense? > > >every packet has a preamble and accessword you use to find the start of > >packet, once they are connected a slave maintain a copy of the master > >clock and can calculate what the next frequency is from that > > > >afair it's been 15 years since I did bluetooth > > The part I have difficulty understanding is, when a slave fails to > receive and decode a packet, or at least the header of a packet, > does that throw the slave's hopping timing off? Or can it recover? >the channel is calculated from the masters clock, each slave maintains a copy of that updated every packet, so it'll stays in sync until it has not received a packet for so long that the differences in clock frequency has caused them to drift apart