Unable to discover service

[ilockit_CFR]

Hi,

I'm using SDK5 17.1.0 and SD132 v7.3.0. At the moment I'm developing a central device which scans for a peripheral. I did this a few times before with other devices and never had a problem with it. But now, the central is unable to discover the services of the peripheral. In my db discovery event handler I always get the event IDs for BLE_DB_DISCOVERY_SRV_NOT_FOUND and BLE_DB_DISCOVERY_AVAILABLE. I double checked the custom UUID of the service and it's correct. If I use nrf connect on my mobile phone the discovery is completed without any error. 

My service definition looks like this: 

#define DNC_C_BASE_UUID             {0x48, 0x62, 0x6d, 0x47, 0x20, 0x65, 0x63, 0x6e, 0x61, 0x44, 0x20, 0x20, 0x00, 0x00, 0x00, 0x00} 
#define BLE_UUID_DNC_C_SERVICE      0x1000  // UUID of DNC Client Service

and the service I'm looking for looks like this in nrf connect: UUID: 00001000-2020-4461-6e63-6520476d6248

I found this post, but I'm using the peer manager and I also handled this event. By the way, if I change the UUID and advertising search pattern to another device with a different service, I can find it without problems. At the moment I have no idea what I'm missing. Is there a way in the SDK to see all available services of my device instead of searching for a specific UUID?

Best regards,

Christian

[Turbo J]

You would need to sd_ble_uuid_vs_add() the new UUID in order to be able to discover that service from softdevice. May require linker script changes (RAM_START) in order to make more space available for the SD.

But I strongly recommend ditching SDK17.x.y in order to use the newer NRF connect SDK.

[ilockit_CFR]

Thanks for the hint, but the base UUID is already added with sd_ble_uuid_vs_add().

[Kenneth]

Hi.

Can you send part of your code where you have implemented service discovery?

From my understanding, if you call sd_ble_gattc_primary_services_discover(.., .., NULL) then the softdevice will send ATT_READ_BY_GROUP_TYPE_REQ (similar to phone). Can you check if p_srvc_uuid to NULL when you call sd_ble_gattc_primary_services_discover()?

Best regards,
Kenneth

[ilockit_CFR]

Hi, 

I can send you the code, if we could turn this ticket to private. 

Actually, I call ble_db_discovery_start(&m_db_disc, p_gap_evt->conn_handle); after receiving the BLE_GAP_EVT_CONNECTED event. 

Best regards,

Christian

[Kenneth]

Hi Christian,

This seems like an issue on the peripheral side. But it should be possible to change the behaviour by using sd_ble_gattc_primary_services_discover(.., .., NULL). 

Can you try in \components\ble\nrf_ble_gq\nrf_ble_gq.c to change the last parameter to NULL for test? Should be two places in the file.

Kenneth

[ilockit_CFR]

Hi Kenneth,

I'm very happy to tell you, that your suggestion worked. I was able to discover all services on the peripheral. 

Do you have an idea what's wrong on the peripheral side? If you could explain this to me, I can give the information to the development team of the peripheral so they can fix the issue on their side. 

Thank you very much for your support. 

Best regards,

Christian

[Kenneth]

Hi Christian,

That was good news!

It is a bit hard to tell what exactly is wrong on the Peripheral side, but it looks like a bug in the implementation of the GATT server. According to Core Spec, Vol 3, Part G "4.4 Primary Service Discovery":

There are two sub-procedures that can be used for primary service discovery: Discover All Primary Services and Discover Primary Service by Service UUID.

It looks like the server doesn't support the second sub-procedure (Discover Primary Service by Service UUID) that uses ATT_FIND_BY_TYPE_VALUE_REQ packet.

You might consider report this as a bug and attach sniffer traces you captured to the Bluetooth Host vendor you use.

Hope that helps,
Kenneth