iOS and Connection Parameter Update Request Ignored

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
PhGi_2174146
Level 3
Level 3
First like received First like given

We have a peripheral device using the 20736S module and when connected to a central running on iOS we're seeing some issues. I should note that we're using SDK 2.2.0.

We first noticed a problem when sending indications from the peripheral.  We will periodically disconnect with a reason code of 0x08, indicating a timeout.  The only information we can find on this reason code is that the most probable cause (since both devices remain powered and attempting to communicate) is poorly configured connection parameters.  So we took a look at our request to the master to change parameters and we're using what we thought are fairly reasonable values, the same as many Broadcom examples in the SDK:

      lel2cap_sendConnParamUpdateReq(80, 400, 0, 700);

We're requesting the change in the callback for the encryption change.  When the peripheral first connects, we check the connection parameters using :  emconninfo_getConnInterval,  emconninfo_getSlaveLatency, and emconninfo_getSupervisionTimeout.  On iOS (8.1.3, 8.2 and 8.3) the values are always 24, 0, and 72 respectively.

When we check the parameters in the routine processing the indications (called many seconds - minutes after the update request), the values remain at 24, 0, and 72.  No matter what values we use and where we make the request, the values do not change from 24, 0, and 72.  We've also tried with WiFi on and off in case interference is a factor and there is no difference.

When we connect to Android however, the request appears to take and the values change to 400, 0 and 700 as expected.

Has anyone seen this issue or have an idea what it may be?

Thanks,

Phill

0 Likes
1 Solution
Anonymous
Not applicable

Sorry dropped off the thread somehow.  I don't have Air Trace.  Our fine timer is 200 msec.

I managed to find this information on iOS connection parameters.

We are now able to adjust connection interval to desired amount.

Still having problems with random unexpected disconnects (timeout 08).

Have disabled the Idle Timer. No joy.

The frequency of disconnects went down after adjusting the parameters but have now returned (about 1 disconnect every 20 to 30 seconds).  Still investigating what changed to bring back the disconnects.  Happens both with SDK 2.2.0 and 2.2.1 (Windows SDK).  Strangely the behavior is different when compiled on a MAC SDK 2.2.0.

Found some information on the iOS BLE programming guidelines web page as follows:

// Tell iPhone what connection parameters we want
// The connection parameter request may be rejected if it does not comply with all of these rules:
// * Interval Max * (Slave Latency + 1) <= 2 seconds
// * Interval Min >= 20 ms
// * Interval Min + 20 ms <= Interval Max Slave Latency <= 4
// * connSupervisionTimeout <= 6 seconds
// * Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout

    int16 slaveLatency   = 8;   // tolerance for missed connection events
    int16 minConnInterval  = 40;  // 40 * 1.25 = 50 msec
    int16 maxConnInterval  = 40;  //  48 * 1.25 = 60 msec
    int16 supervisorTimeout = 600; // 600 * 10 = 6000 msec

bleprofile_SendConnParamUpdateReq(  minConnInterval,
          maxConnInterval,
          slaveLatency,
          supervisorTimeout ) ;

View solution in original post

0 Likes
9 Replies
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

There seems to be some issues with the iOS 8.1/8.2/8.3 regarding sporadic disconnections. My advice is to upgrade to the SDK2.2.1.

mmp20736 random disconnection over IOS

0 Likes
PhGi_2174146
Level 3
Level 3
First like received First like given

I've upgraded to 2.2.1 and I'm still seeing the same issue.  From the other post you mentioned it looks like an additional release of the SDK may be required to address this.

Thank you for the suggestion.

UPDATE:

The supervision timeout value of 700 will cause the request to be rejected by iOS.  In section 3.6 of the Apple Bluetooth Accessory Design Guidelines, any value over 6 seconds (600) is not considered valid.  When I change to a lower value (300), the parameter request is honored.

I had hoped the disconnect issue would go away with the increased super timeout based upon the fact that we're recently moved into new office space.  In this space there are more than 10 strong (4+ bars) WiFi networks, and between 15-20 BLE devices in scanning range.  With this much noise, I thought 72ms was not be enough time to resolve communications issues.


The disconnects still persist.

Anonymous
Not applicable

Hello Phill

1.  Is this a BCM20736S custom board?

2.  If so, I would suggest trying the same process on the TAG3 board and see if the disconnect persists.

3.  What TX Power level are you using?

4.  Do you see this in a clean environment?

5.  What is the RSSI level do you see from phone.

Thanks

JT

0 Likes
Anonymous
Not applicable

I am seeing a similar problem.  Custom board with BCM20736S. Tx power level 4 and 0.  When I disable low power modes the disconnects do not occur.  With low power enabled (not deep sleep/HIDOFF which we do not allow) I see reduced current draw, but then the disconnects start, about 1 per minute at least, but randomly, and the reconnection is immediate.  The disconnects only occur when low power is enabled.  During connection with the iPhone (iOS 8.x but also occurred with iOS 6.x) I see current spikes every 30 milliseconds.  I assumed this was the connection interval, and like  Phil, I tried to request the phone use different connection parameters, but the iOS seems to ignore or reject my request and the 30 mSec activity remains (see attached screen shot).

I would really appreciate some help with the disconnects. If I can't use low power mode our design fails to meet requirements and the project is DOA.  Also the 30 mSec. activity is wasting valuable battery power.  We only need to send data every 200 milliseconds.  Does the BCM module have a problem waking up fast enough to satisfy the iOS? or... what could the trouble be?  I thought changing the connection interval might help, but this failed.  I will try reading the iOS documentation also.

Eric30msecActivity.jpg

0 Likes

JT,


We see the problem with our custom board and with the TAG3.


We are at full power (4 dbm) during connections and we see this problem across a wide spectrum of RSSI (-31 to -78).


What seems to have reduced the frequency of the problem by getting the supervision timeout to a much higher value (3 s).  Additionally, removing the wires from the board for the UART Rx/Tx seems to be helpful, even though the wires are 14mm from the module and are inside the ground plane area.  Disabling/enabling the UART does not seem to have an impact.  It is difficult to know for certain if/how impactful these factors are since the disconnect can happen after on the 1st indication or the 50th.  With the changes, the disconnects seem to happen much close to the 50th indication than the 1st.


Just to reiterate, we only see disconnects on indications (or notification if we use those).  We can leave the device connected to a central for days with no disconnects (no idle timeout), and the central can read and write the characteristics with no problems.  Also, using SDK 2.2.1 vs 2.2 does not seem to make a difference.


ehoffman mentions deep sleep as a factor in their case, but it does not seem to matter in ours.


We have not yet been able to test in a clean environment to see if RF interference is a factor.  We have sent a board out to another company to use a hardware sniffer to see if they can see what is happening.


Phill

Anonymous
Not applicable

Phil,

Thanks for your update.  Just to clarify.  we do not use Deep Sleep.  But we expect our device to be using low power mode as much as possible in between sending data samples every 200 msec.

The fact that you were able to get 3 second supervision timeout is encouraging.  Did you have to do anything to the phone App to get iOS to accept your connection parameter update request?

Thanks

Eric

0 Likes
Anonymous
Not applicable

Hello Eric,

1.  Can you get an Air Trace for what you are seeing?

2.  What is your Fine Timer Interval?

Thanks

JT

0 Likes
Anonymous
Not applicable

Sorry dropped off the thread somehow.  I don't have Air Trace.  Our fine timer is 200 msec.

I managed to find this information on iOS connection parameters.

We are now able to adjust connection interval to desired amount.

Still having problems with random unexpected disconnects (timeout 08).

Have disabled the Idle Timer. No joy.

The frequency of disconnects went down after adjusting the parameters but have now returned (about 1 disconnect every 20 to 30 seconds).  Still investigating what changed to bring back the disconnects.  Happens both with SDK 2.2.0 and 2.2.1 (Windows SDK).  Strangely the behavior is different when compiled on a MAC SDK 2.2.0.

Found some information on the iOS BLE programming guidelines web page as follows:

// Tell iPhone what connection parameters we want
// The connection parameter request may be rejected if it does not comply with all of these rules:
// * Interval Max * (Slave Latency + 1) <= 2 seconds
// * Interval Min >= 20 ms
// * Interval Min + 20 ms <= Interval Max Slave Latency <= 4
// * connSupervisionTimeout <= 6 seconds
// * Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout

    int16 slaveLatency   = 8;   // tolerance for missed connection events
    int16 minConnInterval  = 40;  // 40 * 1.25 = 50 msec
    int16 maxConnInterval  = 40;  //  48 * 1.25 = 60 msec
    int16 supervisorTimeout = 600; // 600 * 10 = 6000 msec

bleprofile_SendConnParamUpdateReq(  minConnInterval,
          maxConnInterval,
          slaveLatency,
          supervisorTimeout ) ;

0 Likes

Thoughts on victorz response to the same information posted here: Re: DiscReason 08

0 Likes