cancel
Showing results for 
Search instead for 
Did you mean: 

Smart Bluetooth

Anonymous
Not applicable

Hello,

On the BCM90726S-Module in our own design we get the DiscReason 08. Sometimes after some minutes, sometimes after some hours.

But I can't find the reason for this disconnect or how to avoid/solve it, nor what it means.

0 Likes
1 Solution
VictorZ_46
Employee

What device are you connecting to.  8 usually means that if peer is a slave it stops answering polls, or if peer is a master the peer stopped polling our device.  For example if peer is a phone and phone is turned off (or enters airplane mode), you will see that.  If you think peer is not being turned off, you may want to check connection interval/link supervision timeout setup for your link.  For example if connection interval is half a second and link supervision timeout is 1 second if you miss two polls due to the interference the connection will go down with result code 8.  If you are a peripheral make sure that you call bleprofile_SendConnParamUpdateReq after connection is established.  Try to increase the last parameter (supervision timeout) and see if it helps.  Check hello_sensor for details.  If you are the central try to increase blecen_cen_cfg.high_supervision_timeout and blecen_cen_cfg.low_supervision_timeout.

View solution in original post

8 Replies
MichaelF_56
Moderator
Moderator

These error codes are BLE Spec related.  There is one thread here that discusses 08 in detail, along with several possible causes (there could be many): What does 08 returned by emconinfo_getDiscReason() mean?

Anonymous
Not applicable

Thank you for the quick response.

Do you have a hint for me where and how to set the parameters?

I can't find a place where they are set.

0 Likes
VictorZ_46
Employee

What device are you connecting to.  8 usually means that if peer is a slave it stops answering polls, or if peer is a master the peer stopped polling our device.  For example if peer is a phone and phone is turned off (or enters airplane mode), you will see that.  If you think peer is not being turned off, you may want to check connection interval/link supervision timeout setup for your link.  For example if connection interval is half a second and link supervision timeout is 1 second if you miss two polls due to the interference the connection will go down with result code 8.  If you are a peripheral make sure that you call bleprofile_SendConnParamUpdateReq after connection is established.  Try to increase the last parameter (supervision timeout) and see if it helps.  Check hello_sensor for details.  If you are the central try to increase blecen_cen_cfg.high_supervision_timeout and blecen_cen_cfg.low_supervision_timeout.

View solution in original post

Anonymous
Not applicable

I think this issue is solved now. Two days without any disconnection.

But I have another question about bleprofile_SendConnParamUpdateReq.

I can't find information about the unit of the parameters. Are they all in [ms]?

In the hello_sensor-example I found the following:

// We are done with initial settings, and need to stay connected.  It is a good

// time to slow down the pace of master polls to save power.  Following request asks

// host to setup polling every 100-500 msec, with link supervision timeout 7 seconds.

bleprofile_SendConnParamUpdateReq(80, 400, 0, 700);

It seems the timeout is in s/10?

0 Likes
VictorZ_46
Employee

This follows core spec update connection parameters request. Connection intervals are in frames (1.25 msec), supervision timeout is in 10msec.

Anonymous
Not applicable

// For iOS 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

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


bleprofile_SendConnParamUpdateReq(  minConnInterval,
                                                                   maxConnInterval,
                                                                   slaveLatency,
                                                                   supervisorTimeout ) ;

0 Likes
VictorZ_46
Employee

Typically if peripheral requests wrong parameters, the phone will force what it finds appropriate but does not disconnect. Reason 8 shows that connection goes out of synch or devices are too far or interference is too bad.

Anonymous
Not applicable

This is true, a badly formulated connection parameter request will be ignored by the host, and will not by itself cause a disconnect.  However, after many hours of experimentation I have observed that a valid, but poorly designed set of connection parameters does indeed affect the FREQUENCY of disconnects, if you are prone to having them.  Also, I have observed that a long supervision timeout (six seconds) actually triggered system resets during disconnect handling in a system running with a low battery.  The reason for this was outlined in another post, and the solution was to reduce the supervision timeout to 3 seconds.  Also, the propensity for disconnects is hardware dependent.  Some of our boards never have disconnects while others regularly have disconnects every two to 5 minutes.... yes, running the exact same firmware.  Still another factor is that when the firmware is built on SDK 2.2.0 on a Max OSx the disconnects disappear.. but when the same source code is built on Windows SDK 2.2.0 (and 2.2.1) the disconnects magically re-appear.  Disconnects are truly a multi-faceted problem and I hope Broadcom is putting some resources on this problem.. both hardware and software.

0 Likes