ESP32 Forum

With an ESP32 configured as a BLE 4.2 controller, we are attempting to read the service data in an advertisement packet from a peripheral. We are using the NimBLE HOST GAP interface (ble_gap.h), and have the appropriate event handler/callback set up. Upon receipt of the BLE_GAP_EVENT_DISC event, discriminated by the MAC address, the rssi member of ble_gap_event->ble_gap_disc_desc struct seems to be correct. However, the length_data does not agree with advertisement packets captured by Wireshark, nor does the data pointed to by the *data member.

Is this the proper way to get at the service data? If not, please enlighten....

The mechanisms for "syncing' service data are only available if the "Support BLE 5" NimBLE option is selected in menuconfig. The Bluedroid stack does seem to support mechanisms to access this data, but we cannot use it at this time.

Are there other options? IDF 5.x? NimBLE Update?

Thanks!

HW Platform : ESP32 WROVER-E
Build Env : MacOS / ESP IDF 4.4
BLE Stack : NimBLE 1.3.0

Hello @c3pnr-iot,

I tried running the example blecent with some debug prints for this.

I can see below prints that indicate the value of data recieved.

event->disc.length_data: 26 rssi -27
2 1 6 3 3 11 18 f 9
6e 69 6d 62 6c 65 2d 62
6c 65 70 72 70 68 2 a
3
D (2680) NimBLE: flags=0x06

D (2680) NimBLE: uuids16(complete)=
D (2690) NimBLE: 0x1811
D (2690) NimBLE:
D (2690) NimBLE:

D (2690) NimBLE: name(complete)=nimble-bleprph

D (2700) NimBLE: tx_pwr_lvl=3


Took OTA to confirm what information is being shared and compared it to find same information.


So,

1. can you share more logs from your side to explain the issue.
2. release/v4.4 is EOL. We encourage you to use the newer 5.x versions.

> The mechanisms for "syncing' service data are only available if the "Support BLE 5" NimBLE option is selected in menuconfig.

can you please explain more in this regard. Which sync service is being referred to here ?

Hi irahul -

Thank you for the reply.

Here is some additional data...

Logs:
I (22:28:34.670) ble_driver: Scanning...
I (22:28:34.670) NimBLE: GAP procedure initiated: discovery;
I (22:28:34.671) NimBLE: own_addr_type=0 filter_policy=0 passive=1 limited=0 filter_duplicates=0
I (22:28:34.680) NimBLE: duration=forever
I (22:28:34.685) NimBLE:

18-08-2024 22:28:34.691 GMT-07:00 WARN:BleEventHandler: APP SCAN
RSSI = -3
Data Length = 245
Data : 9d ec 83 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
18-08-2024 22:28:35.610 GMT-07:00 INFO:BleEventHandler: my device: P02 found. Attempting to Connect, RSSI: -3
I (22:28:35.628) NimBLE: GAP procedure initiated: connect;
I (22:28:35.634) NimBLE: peer_addr_type=1 peer_addr=
I (22:28:35.640) NimBLE: df:ff:5c:3f:13:45
I (22:28:35.645) NimBLE: scan_itvl=16 scan_window=16 itvl_min=24 itvl_max=40 latency=0 supervision_timeout=256 min_ce_len=0 max_ce_len=0 own_addr_type=0
I (22:28:35.659) NimBLE:

Wireshark capture:
I will run the the blecent example on my platform as well. Would you mind forwarding the versions of the build environment and NimBLE component for your test?

Thanks

Hello c3pnr-iot ,

HW Platform : ESP32
Build Env : Linux / ESP IDF 4.4
BLE Stack : NimBLE 1.3.0


Please note v4.4 is now EOL. I tested on 5.x also, but they give the same result. If you are able to reproduce the issue using blecent OR by making any modification, please do share your testing code too which will help us reproduce issue and debug this quickly.

Hi ,

I just saw in the log shared has Data len as 245 . Is this correct field being printed ? Legacy adv packets are of maximum size 31.

Hello irahul -

The value 245 returned for length_data is not correct, nor is the data. That is the problem. The RSSI member, however, is correct.

Thanks!

RSSI = -3

c3pnr-iot wrote: ↑

Mon Aug 19, 2024 4:11 pm

The RSSI member, however, is correct.

Are you sure about that? "-3dBm" isn't too plausible.
Can you share the code of your event handler?