BLE Central - Discovering and reading custom 128-bit service UUID and different 128-bit characteristic

[PriyeshN]

Hi Nordic team,

My dev environment is as follows:

nrf52840 + s140 +SD6.0.0 + SDK15.0.0 + SES + nrf52840-DK

Here, nrf52840-DK is configured as BLE Central and my peripheral is a third party board with entirely different controller, architecture and stack.

My peripheral has a service with below UUID

Service UUID - fb349b5f-8000-0080-0010-000052fd0000

Characteristic UUID - e29819be-3b9f-24bc-3d45-2bf743ea48d8

So, they are completely different rather than differing just the 12-13 octet.

My concern is that after struggling a lot also, I'm not able to discover the service & characteristic on my central neither I'm able to read the value from characteristic. I went through the posts:

https://devzone.nordicsemi.com/f/nordic-q-a/44979/when-128bit-characteristic-uuid-is-different-form-128bit-service-uuid-how-to-discovery-it

https://devzone.nordicsemi.com/f/nordic-q-a/76515/how-to-read-value-if-service-128bit-uuid-is-completely-different-from-characteristics-128-bit-uuid

https://devzone.nordicsemi.com/f/nordic-q-a/36462/discovering-problem-for-different-128-bit-service-and-characteristic-uuid-as-a-central-device

are among the few posts. It seems likely that Nordic BLE stack does not support discovering and reading such UUID's, but I could not find this answer. Can someone from Nordic help me here, either stating that Nordic stack does not support this, or if we can do this, then how?

I have already added my service UUID and characteristic UUID to attribute table using sd_ble_uuid_vs_add() and also tried everything from multiple posts on similar topic.

Quick help on this is appreciated. 

Thanks

[Jared]

1. No, not that I know of. 
2. It all depends on the third-party device, it should be stated somewhere in the documentation how UUID is sent. Most BLE products send with little-endian, meaning the LSB first. If you compare the ble_app_uart and ble_app_uart_c examples you'll see that the service UUID that the GATT client is looking for and the one that the GATT Server is providing is in the same order. The UUID however is sent in the reverse order, which the GATT client assumes and therefore looks for the UUID in the reverse order.
3. It should be of the non-reversed. But the nRF will look for the reversed when it's actually trying to discover the service.

 

[PriyeshN]

Hmm ok,

Anyway, good news is that now I'm able to discover the services. In the interest of forum members and someone coming with same issue later, here's what I did change:

on nRFConnect - I'm seeing the service and characteristic UUID as below (as mentioned in my query as well)

Service UUID - fb349b5f-8000-0080-0010-000052fd0000

Characteristic UUID - e29819be-3b9f-24bc-3d45-2bf743ea48d8

So, when calling sd_ble_uuid_vs_add() I'm providing the

base UUID as - {0x00, 0x00, 0xfd, 0x52, 0x00, 0x00, 0x10, 0x00, 0x80, 0x00, 0x00, 0x80, 0x5f, 0x9b, 0x34, 0xfb} 

but when registering for discovery using sd_ble_uuid_vs_add() I'm providing the 16-Bit UUID as 

UUID for discovery - 0x9B5F

The same goes true for Characteristic as well, although, for characteristic, we need not give the discovery event

For me, this was quiet tricky as I had to discover two custom service UUIDs

UUID1 - fb349b5f-8000-0080-0010-000052fd0000

UUID2 - fb349b5f-8000-0080-0010-000051fd0000

The differentiating factor here is 0xfd52 and 0xfd51, so, till now I was concentrating on them as unique differentiator for discovering, but it's not the way it is. The discovery UUID should be the 12-13 octet of the base UUID being added in attribute table.

So, anyone coming to this post with some similar issue, I recommend trying out by reversing base service UUIDs and trying both sets of reversed and non reversed UUID for discovery. 

For my third party device, I could not find the documentation regarding how UUID is being sent, so permutation combination helped me.

Thanks Jared