Closed TorstenRobitzki closed 2 years ago
I've added a read handler to the Blinky characteristic and notified the characteristic in the read handler, so that a notification is send out with every connection event:
The problem is not reproducible with this setup.
As soon, as synchronized_connection_event_callback
are added to the scene, it reproduces the issue (not reliable, but with a latency of 60, it becomes reliable reproducible).
when letting radio_hardware_without_crypto_support::can_stop_connection_event_timer()
return always false, this issue does not happen.
Using a connection interval of 7.5ms and a peripheral latency of 60, makes the issue reproducible:
setup_connection_event_limit_us
considerable by 200µs doesn't make the issue vanish.synchronized_connection_event_callback
configuration doesn't make the issue vanish.After reproducible 7 connection events, every further connection event runs into a timeout. Even, when doubling the receive window. The 7th connection interval is responded by the client with an empty PDU for unknown reason. With a peripheral latency of 40, the 8th connection event is then again, responded with a notification by the client,
When there are regular notifications to be send out, with connection an interval of 7.5ms and a peripheral latency of 44, the radio (nrf52) seem to get into a state, where it consumes ~3mA without functioning anymore. I suspect that the canceling of a current scheduled connection event followed by the rescheduling triggers this problem. Using any peripheral latency less than 30 seems to not trigger this.