What does 08 returned by emconinfo_getDiscReason() mean?

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

cross mob
Anonymous
Not applicable

Is there a list of the errors generated by emconinfo_getDiscReason()?


Central attempted connection (connUP) to peripheral,

but instead of connUP callback, central got connDown callback, in which emconinfo_getDiscReason() reported disconnect reason was "08".

0 Likes
1 Solution

That's a good question.  You can check connection parameters as soon as connection is established.  Slave can request master to change parameters anytime.  So you can also register to process slave request for parameters update by overwriting lel2cap_handleConnParamUpdateReq.  Check blecen code how it is done.

View solution in original post

8 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

The error codes are contained within the Bluetooth Spec.  I have included a screenshot below.

Error-Codes.png

There are 2 common reasons for error code 8.  One is that device on the other side died, or restarted, or was turned off.  The second is that parameters of your connections are not good.  For example if the connection interval (how often to send polls) is 1 second, and link supervision timeout (how long connection stays up without poll/reply) is 1.5 seconds the connection will go down if slave misses one poll from the master or master misses one reply from the slave.  This can easily happen due to the interference from your WiFi or other BT devices.  If you are implementing the central app, please increase the default link supervision timeout to 500 and it will get better.

0 Likes
Anonymous
Not applicable

Our link super timeout has been 1000.

Here's our high scan settings:

scan interval = 96

scan window = 48

scan duration = 30

conn min interval =  6

con latency = 0

con min event len = 0

con max event len = 0

We only use high scan.

0 Likes

If it does not disconnect right away you can check emconninfo_getConnInterval(), emconninfo_getSlaveLatency() and emconninfo_getSupervisionTimeout() to see what is negotiated.  On the other hand slave may request parameter update anytime.  Can you collect over the air trace by any chance. 

Anonymous
Not applicable

When should central call those three?  At which callback are they valid?

Yes, can sniff.

0 Likes

That's a good question.  You can check connection parameters as soon as connection is established.  Slave can request master to change parameters anytime.  So you can also register to process slave request for parameters update by overwriting lel2cap_handleConnParamUpdateReq.  Check blecen code how it is done.

Anonymous
Not applicable

I put the call to request ConnParamUpdate in my connUp() callback...  I was having inconsistent results getting the parameters requested to take.  I put a 100 msec wait in the connUp() before calling the ConnParamUpdate function.  It seemed to help, but I can't say for sure.  Later I took out the wait after things were running smoothly and started having problems again getting the connection interval I wanted.  I put the wait back in and not currently having this issue.

0 Likes

simplifying things a bit every connection interval master sends a poll, and slave sends a reply.  If slave did not receive any polls, or master did not receive any replies within link supervision timeout the connection is dropped with result code 8.  Your polls/replies might not be reaching destination for example because of interference which can be caused by other BT connections, WiFi traffic or microwave ovens.