8 Replies Latest reply on Sep 12, 2015 3:35 PM by userc_7511

    DiscReason 08



      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.

        • 1. Re: DiscReason 08

          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?

          • 2. Re: DiscReason 08

            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.

            • 3. Re: DiscReason 08

              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.

              • 4. Re: DiscReason 08

                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?

                • 5. Re: DiscReason 08

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

                  1 of 1 people found this helpful
                  • 6. Re: DiscReason 08

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

                        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,
                                                                                       supervisorTimeout ) ;

                    • 7. Re: DiscReason 08

                      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.

                      • 8. Re: DiscReason 08

                        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.