• State Verified Answer
  • Replies 2 replies
  • Subscribers 87 subscribers
  • Views 894 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 258393
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE reconnection time after an already established bonding

astella

To the kind attention of Nordic support team,

we are building some demo program for evaluation purposes using your sdk16 examples with freertos, ble, usb.

But we also added many other features that should be needed in our custom application. What we are observing right now, is that if we have a device that is

ble bonded with a host PC , and then we switch off/on the device, we can notice a great variability in reconnecting times (in roughly a couple of seconds Windows tools feedback a connected device, in ten seconds our device is still blinking and advertising).

Is that a clear symptom that we are disturbing softdevice operations during advertising? Is there always a certain variability for a softdevice that is perfectly

working too, depending on external conditions, antennas performance? And should it be the case, what is this range? Is it possible to speak in a general way about that?  

Is there a practical/theoretical suggestion you could give about this particular subject?

Thank you for your kindness

Parents
  • +1

    This sounds like an issue in your demo application (maybe you have a state machine that doesn't update the leds as it should depending the softdevice events for advertisment, connection, and disconnect), do you observe the same using any of the nRF5 SDK examples? They typically use LED's to indicate advertising and connected state. 

    If that is not the case, then you may check that you are advertising without whitelist, in case you have whitelist enabled which may prevent peers to connect. Also have in mind that if you power cycle a device that is connected, the other peer will typically wait a supervisor timeout until it consider the link is lost.

Reply
  • +1

    This sounds like an issue in your demo application (maybe you have a state machine that doesn't update the leds as it should depending the softdevice events for advertisment, connection, and disconnect), do you observe the same using any of the nRF5 SDK examples? They typically use LED's to indicate advertising and connected state. 

    If that is not the case, then you may check that you are advertising without whitelist, in case you have whitelist enabled which may prevent peers to connect. Also have in mind that if you power cycle a device that is connected, the other peer will typically wait a supervisor timeout until it consider the link is lost.

Children
Related
Terms of service