Some custom characteristic cannot be found

I am trying to using nRF52833 and nRF52840 as a BLE central to connect customer's BLE peripheral.

The attached screenshot is the service discovered by nRF connect Android App.

There are two characteristics in the service dc03900d-7c54-44fa-bca6-c61732a248ef

  1. Uuid: b77acfa5-8f26-4af6-815b-74d03b4542c5
  2. Uuid: 6dfe5997-fd7b-4e31-a609-c2af9cba78cf

However, nRF52833 and nRF52840 can only fond one characteristic b77acfa5-8f26-4af6-815b-74d03b4542c5.
I used the cli command on the ble_app_interactive example to check the characteristic result.
The result shows that it cannot find the characteristic 6dfe5997-fd7b-4e31-a609-c2af9cba78cf.

  

Why the characteristic 6dfe5997-fd7b-4e31-a609-c2af9cba78cf cannot be discovered by nRF52833/nRF52840?

Thanks a lot

Parents
  • Hi,

    I think it's not the issue of the ble_app_interactive example.

    Because later, I used a ble central example, and change the client UUID to the custom service.
    This example using the ble_db_discovery to find the services and characteristics.
    The result is same, ble_db_discovery fond the service 900D with only one characteristic. The debug log as follow:

    <info> app: @@~ Central connected

    <debug> nrf_ble_gq: Registering connection handle: 0x0000

    <debug> ble_db_disc: Starting discovery of service with UUID 0x900D on connection handle 0x0.

    <debug> nrf_ble_gq: Adding item to the request queue

    <debug> nrf_ble_gq: GATTC Primary Services Discovery Request

    <debug> nrf_ble_gq: SD is currently busy. The GATT request procedure will be attempted                       again later.

    <debug> nrf_ble_gq: Processing the request queue...

    <debug> nrf_ble_gq: GATTC Primary Service Discovery Request

    <debug> nrf_ble_gq: SD is currently busy. The GATT request procedure will be attempted                           again later.

    <info> ble_db_disc: on_characteristic_discovery_rsp: @@~ num_chars_curr_disc=1
      =>This log I added is to check when the 1st characteristic was discovered, so we can see that ble_db_discovery has send second characteristic discovery request later

    <debug> nrf_ble_gq: Adding item to the request queue

    <info> nrf_ble_gq: GATTC Characteristic Discovery Request

    <debug> nrf_ble_gq: SD GATT procedure (3) succeeded on connection handle: 0.

    <debug> nrf_ble_gq: Processing the request queue...

    <info> ble_db_disc: on_characteristic_discovery_rsp: @@~ no characteristic status=266
         =>This log I added is to check the status code in the characteristic_discovery_rsp function, since it’s not success result, so ble_db_discovery find the CCCD and then find the next service later.

    <debug> nrf_ble_gq: Adding item to the request queue

    <debug> nrf_ble_gq: GATTC Characteristic Descriptor Request

    <debug> nrf_ble_gq: SD GATT procedure (4) succeeded on connection handle: 0.

    <debug> nrf_ble_gq: Processing the request queue...

    <debug> ble_db_disc: Discovery of service with UUID 0x900D completed with success on connection handle 0x0.

    <info> app: uuid:900D

    <info> app: type:5

    <info> ble_cust_c: count:1

    <info> ble_cust _c: uuid:CFA5

    <info> ble_cust_c: type:3
    => These logs I added is when my db_disc_handler received the BLE_DB_DISCOVERY_COMPLETE.
    the service 900D only found 1 Characteristic (UUID = CFA5)

    As the above log, it seems the 2nd characteristic request has been send after the 1st char response.
    But received the status 266.
    Attached the screenshot, where the log I added in on_characteristic_discovery_rsp function of ble_db_discovery.c :

  • Is there any reason that may cause the 2nd characteristic cannot be correctly discovered by the nRF52840?

    The 1st descriptor of the 2nd characteristic has custom UUID, and I found the UUID is the same as the 1st characteristic.

    Since I'm not so familiar to BLE spec, could custom descriptor and custom characteristic has the same UUID? 

    But why Android App can discovery the 2nd characteristic.

    Because the peripheral is provided by our customer, so if it's a restrictions from the spec.
    Could you help to provide where could I find the restrictions from the spec.

    Thanks a lot,

Reply
  • Is there any reason that may cause the 2nd characteristic cannot be correctly discovered by the nRF52840?

    The 1st descriptor of the 2nd characteristic has custom UUID, and I found the UUID is the same as the 1st characteristic.

    Since I'm not so familiar to BLE spec, could custom descriptor and custom characteristic has the same UUID? 

    But why Android App can discovery the 2nd characteristic.

    Because the peripheral is provided by our customer, so if it's a restrictions from the spec.
    Could you help to provide where could I find the restrictions from the spec.

    Thanks a lot,

Children
  • Hi,

    The log is interesting. Error 266 is BLE_GATT_STATUS_ATTERR_ATTRIBUTE_NOT_FOUND and that indicates that the error could be on the peripheral side. Is that a Nordic product? Do you have access to the peripheral code, even though you did not develop it? Or do you know anything about it? It could be that a sniffer trace would be interesting here.

  • Hi,

    I’ve recorded 2 sniffer log, one is using NRF52833, another one is using Android phone.

    In the 1st log (NORF52833), the fist found characteristic has Attribute handle 0x0028, Characteristic handle 0x002a.

    And ble_db_discovery.c will received characteristic with handle_value 0x2A, and handle_decl 0x28

    And the next characteristic discovery will from handle_value +1, so it start with 2B,

    and then got no attribute response.

     

    In Android sniffer log, after android found the 1st characteristic with Attribute handle 0x0028, Characteristic handle 0x002a. It start 2nd characteristic discovery start from 0x0029 instead of 0x2B

     

    So it can find the 2nd characteristic with attribute handle 0x0029, Characteristic 0x0029.

    Then I tried to change the ble_db_discovery.c, update the next discovery start to from handle_value +1 to handle_decl +1

    And then NRF52833 could found the 2nd characteristic now.

    But since I’m not so familiar with BLE spec, I’m not sure if this modify may cause any other side effect.
    Could you help double confirm this solution for me?
    And according to the BLE spec, should the characteristic discovery should found the next attribute value or next characteristic value? 

    Thanks a lot,

  • Hi,

    jorenaku said:
    But since I’m not so familiar with BLE spec, I’m not sure if this modify may cause any other side effect.
    Could you help double confirm this solution for me?

    I do not immediately see that it is a problem, but I also am not sure why you need to do this. I am wondering if the problem here is how you configure the discovery module rather than the discovery module itself. Can you share your code so that I see how you have done this? (please du not use images but rather share the code as text using either Insert -> Image/Video/File or by copy pasting into Insert -> Code, as that makes it easier to read and search.)

    jorenaku said:
    And according to the BLE spec, should the characteristic discovery should found the next attribute value or next characteristic value? 

    I am not sure what you refer to by attribute value in this context? Everything are attributes, both services, characteristics and descriptors. But there is a hierarchy, so you will have services, and under each service you have one or more characteristics, which has zero or more descriptors. And that is the order you will discover them as well. See A Developer’s Guide To Bluetooth.

Related