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:
...
Code: Select all
Class: 0x00240404
Icon: audio-headset
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).