- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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".
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The error codes are contained within the Bluetooth Spec. I have included a screenshot below.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When should central call those three? At which callback are they valid?
Yes, can sniff.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.