TorstenRobitzki
commented
1 year ago When the nrf52 radio driver was initialized, the HF timer was started. When then the first advertising was started and immediately a connection request was received, the HF timer was captures and mistakenly taken as the offset to the scheduled start of the HF clock.
In Addition, now, when an advertising event is scheduled without delay, the current time is captured as anchor for the next advertisement event, which increases the accuracy of the connection window in case of an connection request. This also fixes #98.
I've tested the fix with a modified blinky on an nrf52840 eval board with a delay (loop) in the startup. I used the nordic sniffer to inspect the connection establishment. I used nRF Connect for Desktop as client. To force a very fast connection request, I've started blinky from within a debugger and started the connection in the client before. From 6 connection attempts at the first advertising event, all succeeded.
To test that this is also a fix for #98, I simply connected and disconnected from the blinky server. Out of 10 attempts, all where able to meet the first connection event after the connection request (3x channel 37; 4x channel 38 and 3x channel 39).
This is emphasized when the application adds a startup delay, before the first ADV is sent. Observed: the first ADV anchor is shifted by the startup delay.