-
...
requestDevicevssetScan...
Of course it doesn't matter with precision to seconds but @malaire tried to do moreI 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).
malaire-
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
the total time may be faster but with setScan you get the packet data sooner? As I understand it the
requestDevicesets up a callback to collect data, starts it, collects data, stops it and resolve promise and call your code. setScan first calls your code with the data as the packet arrives and then you do the rest. And with setScan you can get more packets in one scan to do some average on the timestamps and stop when you are happy with the result.Of course it doesn't matter with precision to seconds but @malaire tried to do more