to save power, our product negotiates a slow connection interval of around 1s (usually ended up being 960ms) when going into deep sleep.
when waking up the device from the app, the device would then renegotiate the connection parameters to get back to a fast connection. Oddly, this took forever! Until the app became useable again, in the worst case 1 minute and 30s would pass.
Most of that was our fault, since we subscribed to lots of characteristics and read them, more or less at the same time as starting the negotiation. so most of the bluetooth events were queued and still happened with the extremely slow connection interval of 960ms. So we made sure this won't happen anymore.
However, even with nothing else happening via BLE, the negotiation from 960ms down to the normal 30ms still takes almost 20 seconds, with an iOS device!
Can I get some feedback from you if this is expected/normal, or if there's something we can optimise. We've already reduced the deep sleep interval to 660ms which improves it greatly, but are still left wondering why it's so slow.
I've attached a screenshot of a capture session using the nrf52 dk as a sniffer.
From the device requesting the connection parameter update until the Master sends the LL_CONNECTION_UPDATE_REQ, it takes 8 intervals (9 including the response immediately following the connection parameter update request)
and from the LL_CONNECTION_UPDATE_REQ util the connection interval actually changes, it takes another 10 intervals!
let me know if you'd like to see the details of any of those packets.
ISTR think there may be limitations in the BLE specs (and/or in mobile OSs) on re-negotiating the parameters ... ?
Could you please upload the whole sniffer log please? That should make it easier to debug.
here you go - I've reduced the capture to the important parts. The write from the app to the device triggers the firmware in the device to wake up and renegotiate the speed. The notifications begin once the negotiation is complete.
These two devzone cases explain things quite well: link 1, link 2.
When doing a connection parameter update request, you need to wait at least 6 connection intervals before doing the update. Therefore, if you have a connection interval of 6 seconds, it will take a while to do the update. However, I am not quite sure while it takes another 10 seconds after the master sends the LL_CONNECTION_UPDATE_REQ. I will continue taking a look & get back to you soon.
Alright, that's already good to know that it's at least 6 intervals. So the first 8 are just over 6, which I'll accept (grudgingly ;-)
but the extra 10 seconds really don't make much sense. I just checked again to make sure that it's nothing of our doing - but the delta time column definitely shows that the interval hasn't changed yet.
btw, we're using an nRF52382 with SDK 15.0, and the counterpart was an iPhone6s