I have been having issue with BLE Connection that frequently and randomly disconnect due to timeout. When there is no disconnection, everything else has been working fine: getting data through Notification, sending Write Command to the board, etc.
I'm using BLE Shield from Adafruit (nRF8001) with Arduino, Android 5.1 (API 22), BLE library version 0.9.7 (I think, I can't verify it, it's just based on my notes)
Some questions / thoughts:
-
How do I debug this? What kind of information available when the signal ACI_EVT_DISCONNECTED sent to Arduino? From Wireshark, I see a Disconnect Complete with Reason Connection Timeout (0x08), but I do not see any other clue.
-
I noticed that the ACI_EVT_TIMING (time change) currently has no code. I have a note to call lib_aci_set_local_data, but not sure where to get all of the parameters for that method.
-
Another suspicious is that I'm not pairing nor bonding from Android to the BLE. Is this the reason? I thought this is more of additional security, but not required.
-
Any other advice/suggestions?
[Updated] btsnoop_hci-18.log
I also did some further investigation and here is my findings:
I noticed that there are 2 Handle Value Notification happened consecutively before Disconnect, so I'm tracing them. What I found out, throughout the runs, there are multiple times Android failed in disabling the notification pipe, which causing 2 pipes are available in Arduino side to send data. My code in Arduino will continue sending data through both pipes, but seems Android did not listen to that pipe and hence did not return the credit. At some point (which I'm not sure when), Android seems will response to that data and the credit will be responded.
But having 2 Handle Value Notification happened quite frequently and not always causing disconnect, as the following images from Wireshark shows.
In this case, after the disconnect the BLE will reconnect and continues the operation. Although there are cases when the disconnect happened, Android will get into trouble and setting the notification will stopped. I implemented queueing in Android to continuously in round robin fashion enabling and disabling the notification of 3 different pipes. When the bad situation happens there will be backlog in the queue. I am not able to reproduce that situation now, but will keep trying.
[Update 2] btsnoop_hci-21.log
There was minor bug that was fixed in Android between this btsnoop and the previous one. It doesn't seem it changed the behavior much. This btsnoop has 4 disconnect timeout at the following times:
- 27.822235
- 53.621734
- 74.550170
- 96.323822
while the last one (111.449646) is user triggered disconnect.
I attached the arduino log here: arduino-serial-21.txt I printed the availability of the pipe. There are 3 pipes that being used with Notification, there are 2 credits available, so I used round robin to enable and disable the notification.
I can't find any specific pattern. The previous comment about having 2 handle value notification is just coincidence. I see other type as well. The disconnect somehow happened randomly.
As you can see, there are occasions that the Android failed to disable the pipe, hence there are multiple pipes available (value of 1). The code in Arduino will send to all pipes and shown it arrives in btsnoop. I don't think that is causing the problem. Although in Android it only received the pipe that it enables.
I also checked the hardware settings using nRFgo Studio. I just used the default,
which seems to me is the internal RC oscillator.
[Update 3] Adding btsnoop: btsnoop_hci-26.log and arduino print out with debug turn on: arduino-serial-26.txt
2 disconnects at 56.168152 and 84.473480. User terminated at 105.414795. Arduino print out is also showing 3 disconnects.
Thank you very much. Kunta