BLE_Uart serviceUUID not visible in client scans

[ThingEngineer]

Running this sketch: https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLETests/Arduino/BLE_uart/BLE_uart.ino
Edit: Or this one: https://github.com/nkolban/ESP32_BLE_Arduino/blob/master/examples/BLE_uart/BLE_uart.ino

The "UART Service" device that shows up in a scan performed by a central mode (client) does not show the serviceUUID in the scan. There for following condition is never met by a client:

if (advertisedDevice.haveServiceUUID() && advertisedDevice.getServiceUUID().equals(serviceUUID)) 

There are testing photos, screen shots, and a further explanation here:
https://github.com/ThingEngineer/ESP32_BLE_client_uart

[FedericoBusero]

Can you check the URL of the BLE_uart.ino ?

• In the error report above, you mention the URL
  https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLETests/Arduino/BLE_uart/BLE_uart.ino
• on your page however, you are referring to
  https://github.com/nkolban/ESP32_BLE_Arduino/blob/master/examples/BLE_uart/BLE_uart.ino

Those 2 examples are currently not in sync. Can you check if the problem occurs in both versions?
The difference is
pServer->getAdvertising()->addServiceUUID(pService->getUUID());
which is exactly a fix for your problem. Can you confirm if it solves your issues?

[ThingEngineer]

Federico,
I do believe I tried both of them and I did not mean to reference both links in (only one). But I will retest both of them right now.

I tinkered with Neil's BLU_uart along with some of my own test code and I specifically thought that the line of code you mentioned above was the key but I got the same results with or without passing the UUID to the addServiceUUID method. I was busy with other things at the time and couldn't chase it any further but I can check it out now. I'll post my finding here in just a few.

[ThingEngineer]

I confirmed the same issue even with the sketch that includes:

pServer->getAdvertising()->addServiceUUID(pService->getUUID());

I compiled and programed an ESP Dev Module with both BLE_uart examples and found the same results when doing a scan on a WiFi Kit 32 programed with a BLE scanning sketch. I also used the nRF Connect app to verify the missing serviceUUID.

I have been compiling and uploading the sketches with PlatformIO but I also tried with the Arduino IDE this time around just to exclude any possible library issues.

Serial output of WiFi Kit 32 BLE scanner:

nRF Connect app scan results:

Connecting to the UART Service (BLE_uart sketch running on the ESP Dev Module) does show the Nordic UART service UUID.

And drilling down does show the two characteristics:

They just do not show up in a scan! :(

Note:
I CAN connect to the BLE_uart in question with the BLE client on the WiFi Kit 32 by removing the if statement that is looking for a particular service UUID, and just fall through to connecting to the first available device (which is the device with no advertised serviceUUID in this case).

[chegewara]

@ThingEngineer Change esp32 name to something shorter (5 or less chars) ans of course add this line too:
pServer->getAdvertising()->addServiceUUID(pService->getUUID());

[ThingEngineer]

Ok that does help, renamed to "test". I can connect to it with the BLE_client (looking for the specific serviceUUID). And I do see the serviceUUID in nRF connect as well. Although it does still look odd/non-standard in nRF connect. Have a look.

The serviceUUID shows up twice. I tried removing the above mentioned line of code to see if maybe it was causing a duplicate but that was not the case, removing that line cause it to have no serviceUUID at all again.

Also, forgive me if this is a standard/expected behavior but it seems wrong. I mean the Adafruit library/device works fine with names longer than 5 characters. And if I do a scan with nRF connect in a busy area I see countless devices with long names and visible serviceUUID's. Is this just a library limitation/issue or an ESP32 limitation/issue?

For now the short name does patch the issue but I wouldn't call it a fix unless that is by design.

[chegewara]

You can search this repo issues to see why you have to use short name.
Advertising packet is 31+31 bytes long. This library is set by default that both advertising packets are the same, but you have BLEAdvertisementData class to set data for both packets independently:
https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/BLEAdvertising.cpp
and those two functions:
https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/BLEAdvertising.cpp#L139
https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/BLEAdvertising.cpp#L156

In this case you have to setup serviceUUID in advertising packet and name in scan response packet.

[ThingEngineer]

Thank you for that extra info Che, this makes more sense now.

I'm fairly new to BLE and to this library so I can't make any assumptions yet but gut instinct tells me something seems off with the advert coming from the BLE_uart compared to other BLE devices I'm scanning. Like, why is the serviceUUID showing up twice causing the LightBlue app to register 2 services for "test" and nRF connect app to show two serviceUUID's in the advert when "test" has only one service. I've got to focus on something else at the moment but I'll dive into the library and this anomaly more later if no one else does. Maybe other devices are only setting regular advertisement date and/or scan response data versus setting both, no idea at this moment, just a first guess. More research is needed...

For anyone else stumbling here this is a good place to start with questions pertaining to BLE advert data, size, etc. The official BLE docs can be a bit daunting.
https://docs.mbed.com/docs/ble-intros/en/latest/Advanced/CustomGAP/

Since this is starting to getting off topic and the original issue here has been covered I'll go ahead close this. Thanks for all your work on this great library guys! I look forward to seeing it mature further.

[chegewara]

You are close. This library is configurable and by default advertising and scan response advertising both are the same, thats why you see 2 serviceUUIDs. To advertise long name with 128 bit serviceUUID there is some kind of trick used, regular advertising is not sending device name, but it is send with scan response. To do this in this library you have to use functions and class i pasted links in other post.

There is at least few topics in this repo with the same issue you asked, just search for short name or serviceUUID. Every answer is wide described why it is happen.

[mitchjs]

Chegewara, id love to see an example using those 2 functions
how to set up the BLEAdvertisementData class
with a long name and 1 128bit uuid

thanks
mitch

[chegewara]

https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLETests/Arduino/BLE_iBeacon/BLE_iBeacon.ino