Problem reading custom characteristics using CLI example

[Jchristf]

I'm working with the BLE experimental CLI example in the 15.3 SDK

I'm able to connect and read standard BLE services and characteristics, no problem.

However, discovering a service with custom UUID, the service discovery returns UUID of zero. 

Looking at code, I see that the vendor specific UUID is in fact read and inserted in the SD stack and the UUID type is returned as 2 and 3 (pointers to that table).

However, since the 16-bit UUID is returned as zero, I dont see how it is possible to proceed to select and work with the service?

I expected to see a 16-bit UUID that reflected the custom UUIDs octets 12-13, which I could then use to discover characteristics, and so forth...   Even so, that would seem to require a way to also specify the custom UUID type in subsequent CLI commands, which isnt possible...

What am I missing?

Jacob.

[Kenneth]

This may be a limitation of the CLI example project (I can report this as an improvement for future), but in general you can find the following thread on how to work with 128-bit UUID:

https://devzone.nordicsemi.com/f/nordic-q-a/12203/how-can-i-get-128bit-service-uuid-from-peripheral

[Jchristf]

I added a very simple extension to the CLi example to allow entering in a UUID type when doing "gatt characteristics <address> <uuid/type>"

That allows me to get then handle range and fire of the SD characteristic discovery for custom services as well (they each have unit UUID type)

The problem is that I get an infinite loop on response event from this discover call:  the first has UUID of 0xFFFF and then follows an infinite loop of response events with UUID 0x100.   I can see in nrfConnect that I have 3 characteristics: 0xFFFF, 0x100 and 0x200.  But it keep reporting the 0x100 infinitely. 

Putting in some debug, I can see that handle range is initially 1-8  (yielding 0xFFFF). Then seach continues for handles 4-8, yielding 0x100, which then repeats infinitely...