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,

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

[Kenneth]

Double check the problem is not related to endianess of uuid?

Kenneth

[ilockit_CFR]

Hi, 

I double-double checked that the uuid is correct. We had contact with the manufacturer of the hardware and the response was, that "Discover primary service by service UUID" is not implemented in that product. To implement that, their BLE chip supplier has to update the protocol stack and I think that won't happen. 

We then received the following response from the manufacturer, which I don't fully understand. Maybe you can help me with that.

We do have some promising news: After discussing with the MG126 supplier, we confirmed that their current protocol stack supports the “ATT_FIND_BY_TYPE_VALUE_REQ” protocol. Based on our understanding, Nordic’s nRF chip should also support this service.Would you be able to test this approach with your BLE fob development partner? I’d appreciate any feedback on whether this method could work for your setup.

Isn't that exactly what is used in service discovery and doesn't work in our case? In the sniffer logs there is the request "Sent Find By Type Value Request" and the answer "Rcvd Error Response - Attribute Not Found"

Please excuse me for bothering you with the problem which is not caused by the nrf. But it would be nice if we could somehow find a solution.

Best regards,

Christian

[Kenneth]

ilockit_CFR said:

Isn't that exactly what is used in service discovery and doesn't work in our case? In the sniffer logs there is the request "Sent Find By Type Value Request" and the answer "Rcvd Error Response - Attribute Not Found"

Yes, can you send them that log also?

Kenneth

[ilockit_CFR]

They already received the sniffing logs. Could it be a solution to implement that project with nrf connect SDK? Is there a method to discover all primary services, like in the nrf connect app for Android?

[Kenneth]

Strange, maybe you can try the Bluetooth shell:
https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/connectivity/bluetooth/bluetooth-shell.html 

At least that one should be easy to test.

Kenneth