• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 712 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Connection disrupted after connection parameter updates

jun wang3
Prodigy 190 points


Hi,

After a connection between an iOS device and a BLE device was established, an update for connection parameter was sent to save more battery power. The update was successful. And then some requests sent by the iOS was not responded by the BLE device from time to time, and the connection would be cut off when timed out thereafter.

Is this a known bug for iOS 6? Is there any work-around?

#define DEFAULT_DESIRED_MIN_CONN_INTERVAL     200        // 1.25ms*200 = 250ms
#define DEFAULT_DESIRED_MAX_CONN_INTERVAL     800      // 1.25ms*800 = 1000ms
#define DEFAULT_DESIRED_SLAVE_LATENCY         0
#define DEFAULT_DESIRED_CONN_TIMEOUT          600           // 10ms*600 = 6s

#define GAPROLE_NO_ACTION                                   0 // Take no action upon unsuccessful parameter updates
#define GAPROLE_RESEND_PARAM_UPDATE          1 // Continue to resend request until successful update
#define GAPROLE_TERMINATE_LINK                         2 // Terminate link upon unsuccessful parameter updates

GAPRole_SendUpdateParam( DEFAULT_DESIRED_MIN_CONN_INTERVAL,DEFAULT_DESIRED_MAX_CONN_INTERVAL,DEFAULT_DESIRED_SLAVE_LATENCY, DEFAULT_DESIRED_CONN_TIMEOUT, GAPROLE_RESEND_PARAM_UPDATE);

  • 0
    Intellectual 555 points

    Hi Jun,

    I have been dealing with the same issue - it was also present in iOS 5, but I have been able to reproduce it 2540 to 2540, so I do not think it is iOS specific.  I am using an ugly work-around for now.  T.I. employee Tim asked me for more details in the thread below, but I have not had time to revisit the issue.  Perhaps you could provide Tim with the requested info so he can look into the issue.

    see this thread  -> http://e2e.ti.com/support/low_power_rf/f/538/p/183876/672158.aspx#672158

    -Tyler

  • 0 in reply to tylerw
    Prodigy 190 points

    Hi Tyler，

    In the problem, the parameter update has been done successfully( where the interval has been changed to 1 second from default value), and communication went on with the new parameters, as sniffed below:

    However, the following problem occurred during:

    The picture shows that, with the new parameters, the Master sent requests in several continuous connect events but the Slave would not respond, leading to termination of communication.

    Is this problem the same as the one you encountered? Would you please elaborate on your solution?

    Jun

    Best Regards！Thank you！

  • 0 in reply to jun wang3
    Intellectual 555 points

    Hi Jun,

    I don't have much experience with the T.I. protocol sniffer so it's hard for me to tell exactly what is going on in your captures.  

    In my case, the LL_CONNECTION_UPDATE_REQ was received, but no communication occurred after the connInstant when the new parameters were to take effect.

    The key to my work-around is the realization that the connection parameter update never fails in the absence of other data on the link.  You just need some mechanism that tells both peers not to send any data until the parameter update has completed.

    -Tyler