DiscReason 08

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

cross mob
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

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
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

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

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.

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

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

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