The challenges of radio synchronization

There are really only two ways to synchronize the DW radios using some other low-power option: 1)  Don’t!  i.e. listen out at low-power all the time for data packets, or 2) synchronize all the uC clocks so that listeners and senders only listen during agreed windows. 

In case 2, the peers’ window can be opened at:  (a) a GMT time, or  (b) after some mutually agreed period. 

1 means we need to have a very low-power wake-up radio. At least we know that the lowest achievable threshold for that seems to be around 1,9mA with the ZL radio.

2a needs some locally accurate, accurate broadcast clock – like GPS (but nA power)

2b is what BLE does within a connection. 

In a BLE connection, the sender and receiver can adjust the time they open, and close their communication windows based on their anticipated combined, worst-case clock slippage.  Then presumably, the listener resyncs based upon how early, or late the last successful packet arrived.

BLE assumes that clocks slip against one another by a known amount determined by the crystal. This is why during initialization of the BLE stack you have to tell it the properties of the crystal 

  

Two non-critical things to NB:  

1. During connection, the peers exchange clock characteristics). 
2. It probably has to be the listener that adjusts because the transmitter may only be a broadcaster, and never listen.

The downside of the 2b technique hits when you have to have to listen out for multiple peers, as we do.  Once you have enough peers transmitting in an un-synchronised way, the listener needs to manage multiple windows, which will start to overlap. (I suspect n=4) Then the receiver ends up listening all the time anyway.  If the senders transmitted, not at random times, but in a perfectly synchronized way to all hit the receiver’s small window, then there would be a packet storm, and no packets would get through.