Erroneous results during service discovery of custom UUIDs

[Userta]

Hi there,

Background:

I have set-up a gap peripheral device (nRF52832 / SDK 15.0.0) with 1 service with 2 characteristics, each having its own custom 128 bit UUID. i can connect to the peripheral with nRF Connect App and exchange characteristic data  without any problem. All ok so far.

Now i have another central device (also nRF52832 / SDK 15.0.0), which tries to discover these services via the SDK API's  (sd_ble_gattc_primary_services_discover() / sd_ble_gattc_characteristics_discover() etc. ), however i see the first signs of the trouble, when in the discovery response of the first characteristic (on_evtgattc_char_discovery_resp()), i get the following  response logged below (contents of "ble_gattc_evt_t", please see the lines highlighted in red (char-decl-handle: , service-uuid: etc..).

---------------------------------------------------------------------------------------

discovering primary services..
GATT ATT MTU on conn-id 0x0 changed to 247
discovered primary service. uuid: 0x2001, type: 2, start-handle: 0x000E, end-handle: 0xFFFF
--> found a service-uuid: 0x2001

discovering char's (0x000E)..
rcvd char discovery resp, char count: 2
char-decl-handle: 0x000F, service-uuid: 0x2001, uuid-type: 3, value-handle: 0x0010
char-decl-handle: 0x0000, service-uuid: 0x9680, uuid-type: 0, value-handle: 0x001E
read resp for char-decl-handle: 0x000F
char-properties: 0x0C
--> found a char-uuid: 0x0001

discovering char-desc's (0x0011)..
rcvd desc discovery resp, desc count: 1
desc-handle: 0x0011, uuid: 0x2803, type: 1

discovering char's (0x0011)..
rcvd char discovery resp, char count: 1
char-decl-handle: 0x0011, service-uuid: 0x2001, uuid-type: 4, value-handle: 0x0012
read resp for char-decl-handle: 0x0011
char-properties: 0x10
--> found a char-uuid: 0x0002

discovering char-desc's (0x0013)..
rcvd desc discovery resp, desc count: 1
desc-handle: 0x0013, uuid: 0x2902, type: 1
found CCCD
on_evtgattc_write_resp()

discovering char-desc's (0x0014)..
error: on_evtgattc_desc_discovery_resp(): 0x10A

discovering char's (0x0014)..
error: on_evtgattc_char_discovery_resp(): 0x10A

---------------------------------------------------------------------------------------

The Problems:
1. first of all, why there is characteristic count of 2 in first characteristic discovery.

2.  the 1st characteristic index is relatively OK (i.e., service-uuid is correct, although uuid-type = 3? (0=ble, 1=vendor, 2=unknown), but the 2nd line is completely junk.

3. (for later perhaps), the 2nd characteristic had cccd / notifications enabled, the notification payload is partly corrupted, and appears to have the same junk bytes as contained in the junk characteristic discovery index mentioned in point 2.

 
   
how could these results be explained? is there something i need to look into, to avoid this?

much thanks in advance!

[Hung Bui]

Hi Tejinder, 

We need to have you code to know what could be wrong. Also please provide information about your 128 bit UUIDs. 

I would suggest you to test with 1 service and 1 characteristic first before testing with multiple characteristics. You can refer to the ble_app_uart_c for reference

Note that the uuid-type (equivalent to our uuid_type in our code I assume) is the index of your base UUID in the UUID database inside softdevice. 

When you register your first 128 bit UUID base you will have uuid_type = 2 (Vendor begin)

When you register your 2nd 128bit UUID base, you will have uuid_type =3 for that UUID base. And so on for next UUID bases.

You would need to register the UUID base you are expecting to discover on the peer device in advance. Otherwise you would need to do extra step to read the UUID value. It's not covered in the discovery library. 

[Userta]

Hi there,

much thanks for your prompt response. I will get back to you tomorrow with my source-code. Till then,

kind regards,

[Hung Bui]

Hi  Tejinder,

If you need to upload confidential code, you can convert the case to private case. Please click on "Go Private" button above.

Please try to test with one single service and one characteristic first. 

I had a look at your code and could be a little bit hard to understand fully because I'm not very familiar with the code you provided. 

Please be aware that sd_ble_uuid_vs_add() should only be called to add the UUID base into the database, and it's important to use corresponding ble_uuid.type when calling sd_ble_gattc_primary_services_discover() or sd_ble_gattc_characteristics_discover(). 

Make sure you call sd_ble_uuid_vs_add() for all of the 128 bit UUID base you plan to disconver, prior to the service discovery. 

Please follow these message sequence chart for service discovery and characteristic discovery. 

[Userta]

Hi Hung Bui, thanks for your inputs. good to know about the private mode.

My problem is this: i have used by-the-book implementation i.e., the standard GATT procedures as described in the  SDK mesage sequence charts and i have tried to use sd_ble_uuid_vs_add(), whereever possible. But i still have the problem. I will have a look into my source code again and confirm about sd_ble_uuid_vs_add() once again. An additional problem is that the service discovery  of a single service lasts about 8-10 seconds, not sure why it's taking so long (could it be that mulitple GATT read prcoedures done with "sd_ble_gattc_read()"  for custom UUIDs contribute hugely to the time needed to conclude the discovery procedure?)

i have been using the standard service and discovery API's from the Nordic SDK. i am aware that there is also "db_discovery" library module offered in SDK. but i am not sure if this could also work for GATT structure with custom UUIDs. could you pls suggest, if the db_discovery module can be use for custom UUIDs and is it preferable over the standard API's (from the sequence charts above)?

Much thanks for your time!

[Hung Bui]

Hi Tejinder, 

The db_discovery module should work with custom UUID as you can see in the ble_app_uart_c example. 

To increase the speed of service discovery, please make sure you have low connection interval. The fastest connection interval is 7.5ms. 

If you can capture a sniffer trace of the process, it would be easier to identify if there is any other reason why it's slow.