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 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

[ilockit_CFR]

Hi Kenneth,

at the moment I'm working further on my solution for this workaround and have an issue with the characteristics. 

It seems, that your propposed solution only finds the characteristics of the 16-bit standard services. I couldn't find any characteristics of the custom service. I'm also not 100% sure if this workaround can find the custom service at all, because if I check this:

NRF_LOG_DEBUG("Service count = %d", p_ble_gattc_evt->params.prim_srvc_disc_rsp.count);
    
for(uint8_t i = 0; i < p_ble_gattc_evt->params.prim_srvc_disc_rsp.count; i++)
{
    NRF_LOG_DEBUG("[%d]: %.4X",i, p_ble_gattc_evt->params.prim_srvc_disc_rsp.services[i].uuid.uuid);
}

it will give me this result:

00> Service count = 2
00> [0]: 1800
00> [1]: 180A

Is there anything I can do to get the characteristics of the custom service? Unfortunatelly, there's no response from the vendor to fix this bug, so I have to find a solution to get around this. 

Best regards, 

Christian

[Kenneth]

I could find this thread which I think is relevant:
https://devzone.nordicsemi.com/f/nordic-q-a/3656/s130-custom-uuid-service-discovery 

Kenneth

[ilockit_CFR]

Hi Kenneth,

tanks for your reply. If I understood this correctly, it was about setting the service UUID to the stack via sd_ble_uuid_vs_add(). I'm doing this already at application start when I initialise the services. So for me it looks, like the service is still not found at all. In my post above I saw the service UUID and thought that it was found, but I think it was only shown because I set the UUID before with ble_db_discovery_evt_register. Do you have any other idea, that could help?

Best regards,

Christian