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.
BLE synchronization mechanism
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
– e,g, SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, …)
Two non-critical things to NB:
- During connection, the peers exchange clock characteristics).
- It probably has to be the listener that adjusts because the transmitter may only be a broadcaster, and never listen.
Our BLE challenge.
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.
So the 3 connection limit is not actually a software limitation of the BLE softmachine. It is probably a theoretical limit of the BLE protocol that would get relieved by much faster data rates. But such a limit will always exist.
I could dig down into the BLE MAC layer (I presume I can get access somehow) and do something a lot simpler than BLE does, but I suspect that they are already doing the very best they can given the radio physics.
So low-power listening, or clock sync, or a huge battery?