You are reading a single comment by @malaire and its replies.
Click here to read the full conversation.
-
Scan response timing seems deterministic only in relation to preceding advertising packet. For that to be useful I'd need to
a) know the exact time when preceding advertising packet was sent
b) set response packet content after preceding advertising packet has been sent, so it's uptodateI don't think either of those are possible with normal APIs since advertising isn't meant to be used for sending time-sensitive data like this. (Sure both would be possible in theory with custom Bluetooth protocol stack.)
malaire
Oh, you are right for the advertising, there is delay indeed. Decribed e.g. here https://www.argenox.com/library/bluetooth-low-energy/ble-advertising-primer/ didn't know this. Makes sense. However it is not like that for the rest, the rest has strict timing so receiver device can wake at the precise moment sender is supposed to send the packet, that is part of the 'low energy'.
But anyway even with advertising the timing for scan response packet may be better. This is with active scanning, it is second packet for advertising data.
EDIT:
Scan response is more deterministic, see https://devzone.nordicsemi.com/f/nordic-q-a/29719/beacon-scan-response-request-and-packet-timing