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?
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.
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.
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?
1 of 1 people found this helpful
This follows core spec update connection parameters request. Connection intervals are in frames (1.25 msec), supervision timeout is in 10msec.
// 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
supervisorTimeout ) ;
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.
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.