-
I've been testing to make Bangle.js 2 determine its clock drift and accuracy from advertisements just doesn't seem to be enough to do that (quickly enough).
There is still scan response. I will try the hack with SoftDevice >=6.1 with updating timestamp in scan response static buffer on the fly (there is even BLE_GAP_EVT_SCAN_REQ_REPORT event you get when someone requests scan response, see e.g. this) and see whether it breaks or softdevice will pick up the changes.
next I'm going to test connecting watch to current time device and sending current time via that connection with 1 ms accuracy (custom format).
That may be easier and more predictable after all.
fanoush-
next I'm going to test connecting watch to current time device and sending current time via that connection with 1 ms accuracy (custom format).
That may be easier and more predictable after all.
Strangely this seems to be much worse. Connecting to get few bytes can take several seconds and
BluetoothRemoteGATTCharacteristic.readValue()part of that takes at least 90 ms but sometimes up to 300 ms - much worse than using advertisements.
malaire
I don't think that matters as there is even worse inaccuracy. I've now realized other 0-20 ms inaccuracy in BLE advertisements I overlooked before: Each advertisement is send on 3 channels with up to 10 ms between, and receiver doesn't know which one they received.
I've been testing to make Bangle.js 2 determine its clock drift and accuracy from advertisements just doesn't seem to be enough to do that (quickly enough).
So next I'm going to test connecting watch to current time device and sending current time via that connection with 1 ms accuracy (custom format).