Trying to find out why "Class of Device" / UUIDs response is delayed

[thefury]

I am working on a custom board for a customer whose application requires a specific Class of Device because they are depending on BlueZ's "icon" field (found to be determined exclusively by the CoD). My ESP32 system seems to respond to it very slowly, in that the Class of Device and UUIDs list does not come up in initial inquiry, and only arrives later (secondary inquiry response? extended inquiry response?). This is different than other devices, such as a phone or a headset, where the class of device and UUIDs appear right away. It also seems to be different than when using the ESP-ADF / ESP-IDF Bluetooth examples, despite my code being originally based on an ESP-ADF example.

I observed this using bluetoothctl in Linux, with both a Bluetooth headset (Sena 10S) and my ESP32-based device in discoverable mode.

Code: Select all

[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:DA:71:10 Discovering: yes
... other devices show up in inquiry ...
[NEW] Device 80:64:6F:FB:D6:4E My device FBD64E
... other devices ...
[NEW] Device 00:01:95:4B:DF:F2 Sena 10S v2.0.1
... other devices RSSI/TxPower reported ...
[CHG] Device 80:64:6F:FB:D6:4E RSSI is nil
...
[bluetooth]# info 00:01:95:4B:DF:F2 
Device 00:01:95:4B:DF:F2 (public)
	Name: Sena 10S v2.0.1
	Alias: Sena 10S v2.0.1
	Class: 0x00240404
	Icon: audio-headset
	Paired: no
	Trusted: no
	Blocked: no
	Connected: no
	LegacyPairing: no
	UUID: Advanced Audio Distribu.. (0000110d-0000-1000-8000-00805f9b34fb)
	UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control Cont.. (0000110f-0000-1000-8000-00805f9b34fb)
	UUID: Handsfree                 (0000111e-0000-1000-8000-00805f9b34fb)
	UUID: Headset                   (00001108-0000-1000-8000-00805f9b34fb)
	UUID: Headset HS                (00001131-0000-1000-8000-00805f9b34fb)
[bluetooth]# info 80:64:6F:FB:D6:4E 
Device 80:64:6F:FB:D6:4E (public)
	Name: My device FBD64E
	Alias: My device FBD64E
	Paired: no
	Trusted: no
	Blocked: no
	Connected: no
	LegacyPairing: no
	ManufacturerData Key: 0x0cf3
	ManufacturerData Value:
...
later
...
[CHG] Device 80:64:6F:FB:D6:4E Class: 0x00240414
[CHG] Device 80:64:6F:FB:D6:4E Icon: audio-card
[CHG] Device 80:64:6F:FB:D6:4E UUIDs: 00001101-0000-1000-8000-00805f9b34fb
[CHG] Device 80:64:6F:FB:D6:4E UUIDs: 0000110b-0000-1000-8000-00805f9b34fb
[CHG] Device 80:64:6F:FB:D6:4E UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Device 80:64:6F:FB:D6:4E UUIDs: 0000110d-0000-1000-8000-00805f9b34fb
[CHG] Device 80:64:6F:FB:D6:4E UUIDs: 0000110e-0000-1000-8000-00805f9b34fb
[bluetooth]# info 80:64:6F:FB:D6:4E 
Device 80:64:6F:FB:D6:4E (public)
	Name: My device FBD64E
	Alias: My device FBD64E
	Class: 0x00240414
	Icon: audio-card
	Paired: no
	Trusted: no
	Blocked: no
	Connected: no
	LegacyPairing: no
	UUID: Serial Port               (00001101-0000-1000-8000-00805f9b34fb)
	UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
	UUID: Advanced Audio Distribu.. (0000110d-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
	ManufacturerData Key: 0x0cf3
	ManufacturerData Value:
...

Note that the headset's class of device was present:

Code: Select all

	Class: 0x00240404
	Icon: audio-headset

My device's wasn't until later, after the [CHG].

The most substantial difference I can think of between an ESP-ADF example "wifi_bt_ble_coex" and my code is that I am setting a manufacturer specific data packet in my BLE advertisement. But taking that out does not seem to help. I can remove WiFi and BLE entirely and the problem seems to go away, but I need those in my application for now to be able to perform OTA updates.

Has anyone else observed a delayed Class of Device / UUID list response? What could cause it? Did you fix it?

I'm wondering if there's an initial inquiry response that's happening with ESP32 specifically that does not contain class of device or any of the service UUIDs, and it only comes in after the first response.

I am trying to retrace steps to see if I can get it to reproduce on an Espressif board so I can post on GitHub, but there's been a few years of changes since my original application based around ESP-ADF pipeline_a2dp_sink_and_hfp, and custom board GPIO, so I've got a lot of extra stuff happening in my application that isn't compatible with the dev boards (ADC & GPIO & different DAC, amps, etc).

[MicroController]

Has anyone else observed a delayed Class of Device / UUID list response? What could cause it?

Might be that CoD and other data (UUID list) are not (automatically) included in your advertisements.

[thefury]

Has anyone else observed a delayed Class of Device / UUID list response? What could cause it?

Might be that CoD and other data (UUID list) are not (automatically) included in your advertisements.

I don't seem to have much control over it. I just call esp_bt_gap_set_cod before becoming discoverable (and also have to remove parts where the stack internally overrides the class of device in order to keep it the way I set it). It doesn't tell me when an inquiry comes in. I presume the UUIDs list is the SDP record which I believe gets updated in the stack as each part (A2DP, SPP) gets initialized.

[MicroController]

If all else fails, you can try to send custom advertisements. Although, from the issue I gather that you're using the libraries own SPP service which may override any custom advertisement...

[thefury]

If all else fails, you can try to send custom advertisements. Although, from the issue I gather that you're using the libraries own SPP service which may override any custom advertisement...

I did try turning off any manufacturer specific data packets from my Bluetooth LE advertisement/scan response packets, but it didn't affect the response. Though it does seem to make sense that the LE response is coming in first and the Bluetooth classic response comes in later. I think LE is advertising more often. I just can't get the same thing to happen when using Espressif example code. The inquiries seem to instantly have the Class of Device and UUIDs when I try ESP-ADF examples (wifi_bt_ble_coex) or ESP-IDF examples (a2dp_sink and a2dp_gatts_coex). My GATTS code is heavily derived from the examples so I'm really confused as to where the problem came in. When I remove LE entirely from the project (i.e. never start up the LE code, or compile LE support out entirely) the class of device comes instantly as soon as it's visible in the list. But I need LE so that my iOS app can send me custom commands (since iOS doesn't allow normal SPP).

[thefury]

Interesting. When I call esp_ble_gap_config_local_privacy(true); and set adv_params.own_addr_type to BLE_ADDR_TYPE_RPA_PUBLIC, the inquiry response gets the class of device right away. BLE has a different address, then, which I think is fine for my purposes. However, now the inquiry scan has two separate devices with the same name. I can't set the Bluetooth LE name to something else, it causes the classic name to change as well. How do I get it so I can either set a different name for the LE, or keep the same address so there's only one device in the inquiry list to choose from, but make it so the classic inquiry always takes priority over the LE advertisement?

I am afraid the only stuff I know about BlueZ is the fact that it derives the icon from the classic CoD. I don't know enough to know how to coax it into using classic only to perform an inquiry...