BLE disconnects after ~5s of inactivity

[phatpaul]

Environment

- Development Kit: [none, custom product using wrover module.]
- Module or chip used: [ESP32-WROVER 16M]
- IDF version: v3.3.1
- Build System: [Legacy GNU Make]
- Compiler version: xtensa-esp32-elf-gcc.exe (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
- Operating System: [Windows]
- (Windows only) environment type: [MSYS2 mingw32].
- Power Supply: [on-board 3.3V]

Using Bluedroid BLE stack.
Custom GATTS profile based on code from here: https://github.com/eagi223/esp-idf_Blue ... ti-Service
Custom Android/iOS App built with Cordova and uses the Evothings BLE plugin from here: https://github.com/evothings/cordova-ble


Problem Description

Several of our customers are reporting that they are disconnected from our ESP32-based device after about 5s of inactivity. They are able to discover and connect to our device using our App and are able to send commands to our device immediately after connection. But if they don't send any commands for 5s then the connection is somehow broken.

Our App does not report a disconnect (since no disconnect or error callback is triggered from the BLE plugin).
The ESP32 log doesn't show a disconnect until about 30s after the connection stopped working. Then it just shows the messages below. But those are the same messages that would be shown on a normal disconnect, so I don't see any useful clues there.

Code: Select all

I (662439) GATT Server: ESP_GATTS_DISCONNECT_EVT, reason = 19
I (662439) ble gap: advertising start successfully

The users with issues are all using very recent versions of Android and iOS. Unfortunately we don't own these expensive devices for testing, but are working on getting access to them.

Not working: (Bluetooth drops after 5 seconds)
iPhone XR, iOS 13.4.1
Samsung Note 10+, Android 10.?
Samsung S20 Ultra, Android 10.?

Working OK:
iPhone XR, iOS 13.3.1
iPhone SE, iOS 12.4.6
moto x4, Android 7.1.1
Samsung Galaxy S8, Android 9.
Samsung Galaxy S7, Android 8.0.0
Samsung Galaxy Tab A, Android 7.1.1
(We have also tested many other models, too many to list. Also most of our customers are not complaining --yet.)

Steps to reproduce
I was able to borrow a colleagues iPhone XR with iOS 13.4.1 which exhibits the bug. I inspected the app running in Xcode but I found no obvious errors. After about 5s of inactivity, our app believes that it is still connected and communicating to ESP32 even though nothing is being received at the ESP32. There's no disconnect or error callback triggered from the BLE plugin.

I don't have access to an Android 10 device to test with yet.

Further Troubleshooting

I know the Evothings Cordova BLE library that I'm using is not being actively developed (since 2016) and I'm considering switching to https://github.com/randdusing/cordova-p ... luetoothle But that will be a significant effort.

I will try turning on verbose logging in the ESP32 bluetooth library to see if there are any useful messages.

I will try running nRF app to connect to our ESP32 device on the affected phones to see if the connection is stable.

Any thoughts or suggestions are appreciated.

[chegewara]

I (662439) GATT Server: ESP_GATTS_DISCONNECT_EVT, reason = 19

This is reason:

Code: Select all

0x13 Remote User Terminated Connection

Which means that for some reason smartphone is disconnecting.


Past few months i am building ionic apps with this plugin and it works really nicely with esp32:
https://github.com/randdusing/cordova-p ... luetoothle

[phatpaul]

Thanks for the reply and vote for randdusing BLE plugin.

But I'm not convinced that this is an issue with my App (or the Evothings BLE plugin).

I loaded the nRF app (free from Nordic Semiconductor) onto an iPhone 8, iOS 13.4.1 which is exhibiting the bug with my ESP32 device.
The bug is also present when using the nRF app. I'm able to connect but then soon after it stops responding.
At least the nRF app knows that it's been disconnected from my ESP32 BLE device after a few seconds.

I have not had any issue with the nRF App when used with other devices and older software.

So it's looking like there is some incompatibility with my ESP32 firmware and the smartphone OS or firmware.

Next I'm going to try loading some example BLE peripheral project to my ESP32 to see if it shows the issue.
I'll have to keep with the IDF 3.3 for now, since I'm not tooled up with 4.0 yet.

[phatpaul]

Update: I narrowed down the problem to the "Device Info" service. To test I just disabled the "Device Info" service entirely on my ESP32 firmware and now my problem is gone. But of course now my App can't query the firmware version etc from my device.

Thanks to this post where people are reporting very similar symptoms: https://forums.developer.apple.com/thread/129969

I've implemented most of the "Device Info" service, but not all of the characteristics -- since my App didn't need all of them.

The only 2 that I haven't implemented are

Code: Select all

	// IEEE 11073-20601 Regulatory Certification Data List Declaration
//	DEVINFO_IEEE_DATA_CHAR,
	// IEEE 11073-20601 Regulatory Certification Data List Value
//	DEVINFO_IEEE_DATA_VAL,

	// PnP ID Declaration
//	DEVINFO_PNP_ID_CHAR,
	// PnP ID Value
//	DEVINFO_PNP_ID_VAL,

Code: Select all

// IEEE 11073-20601 Regulatory Certification Data List characteristic
/*
// IEEE 11073 authoritative body values
#define DEVINFO_11073_BODY_EMPTY          0
#define DEVINFO_11073_BODY_IEEE           1
#define DEVINFO_11073_BODY_CONTINUA       2
#define DEVINFO_11073_BODY_EXP            254
static uint8_t defaultDevInfo11073Cert[] =
{
  DEVINFO_11073_BODY_EXP,     // authoritative body type
  0x00,                       // authoritative body structure type
                              // authoritative body data follows below:
  'e', 'x', 'p', 'e', 'r', 'i', 'm', 'e', 'n', 't', 'a', 'l'
};
*/
// The length of this characteristic is not fixed
//static uint8_t *devInfo11073Cert = defaultDevInfo11073Cert;
//static uint8_t devInfo11073CertLen = sizeof(defaultDevInfo11073Cert);

// PnP ID characteristic
/*
#define DEVINFO_PNP_ID_LEN	(7)
static uint8_t devInfoPnpId[DEVINFO_PNP_ID_LEN] =
{
  1,            // Vendor ID source (1=Bluetooth SIG)
  0xE5, 0x02,   // Vendor ID (See https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers )
  0x00, 0x00,   // Product ID (vendor-specific)
  0x10, 0x01    // Product version (JJ.M.N)
};
*/

Does anyone know what those are for? Do I have to implement them and if so what data do I put in there?

[phatpaul]

Update 2: the problem doesn't appear to be that I'm lacking some characteristics in the "Device Information Service", since I added all of them and it still doesn't work on iOS 13.4 and Android 10.
Also I looked at several other BLE devices that were nearby and it seems that none of them implement all of the characteristics.

And the BLE spec for the DIS states:

> The Device Information Service may expose one or more of the
> characteristics shown in Table 3.1. It is possible that none of the
> characteristics below are included. Unless otherwise specified, only
> one instance of each characteristic shall be present.

https://www.bluetooth.org/docman/handle ... _id=244369

I also tried removing all of the characteristics except for "Manufacturer Name" (0x2A29) and "Serial Number" (0x2A25), but same results.

So, the only way to get this to work for now is to remove the DIS service completely.

[phatpaul]

I managed to capture the bluetoothd-hci-latest.pklg from iOS 13.4 and opened it in Wireshark.

I don't know exactly what I'm looking for, but here's the disconnect event I think:

1527 372.138000 controller host HCI_EVT 7 Rcvd Disconnect Complete
Connection Terminated by Local Host

I have attached the Bluetooth HCI log from iOS 13.4 (bluetoothd-hci-latest.pklg)

bluetoothd-hci-latest.zip

bluetoothd-hci-latest.pklg

(18.05 KiB) Downloaded 413 times

Can someone please take a look at this capture?

FYI:
The instructions I used to capture the HCI log on iOS: https://download.developer.apple.com/iO ... ctions.pdf

[phatpaul]

FYI: I found the bugfix at https://github.com/espressif/esp-idf/issues/4903

Shame it took me 4 days to find it.

[chegewara]

Thats great you found it and it works, i missed it because i ignore iOS.