Service discovery, attribute not found 0x0001

[laran]

Dear all,

I am having issues with service discovery of two primary services ( Battery and one propriotary based on NUS) I am currently using SDK 14.2 on NRF52832 chip running as central device application trying to discover these services on off-the shelf peripheral devices (thermal printers to be more specific).

I have tried with different devices (different brands with same UUID) and with some of them the service discovery works and I am able to send data to the printer. It also works when I connect using nRF Connect on my Android device.

I have logged the communication with Wireshark however don't understand why I get the "Attribute Not Found, Handle: 0x0001 (Unknown)

Sorry for being somewhat brief in my description. The thing is that I am not sure I am actually looking at this problem from the right angle. I am not certain the service discovery is wrong. It may be that I missed something in the configuration. If so, how do I find out what?

Thanks for any help getting on track with this.

[laran]

Yes, I am still using SDK 14.2 with SD s132 (v5.0.0)

This is what I get when printing out the GATT status:
<debug> ble_db_disc: Service UUID 0x180F not found (GATT Status = 0x010A).

[Bjørn Kvaale]

Sorry about the delayed response. Got a tip from a colleague, which was to take a look at the ble heart rate collector central example. I believe the answer should be quite straightforward if you take a look at the ble_app_hrs example:

 * @brief Battery level collector initialization.
 */
static void bas_c_init(void)
{
    ble_bas_c_init_t bas_c_init_obj;

    bas_c_init_obj.evt_handler = bas_c_evt_handler;

    ret_code_t err_code = ble_bas_c_init(&m_bas_c, &bas_c_init_obj);
    APP_ERROR_CHECK(err_code);
}

uint32_t ble_bas_c_init(ble_bas_c_t * p_ble_bas_c, ble_bas_c_init_t * p_ble_bas_c_init)
{
    VERIFY_PARAM_NOT_NULL(p_ble_bas_c);
    VERIFY_PARAM_NOT_NULL(p_ble_bas_c_init);

    ble_uuid_t bas_uuid;

    bas_uuid.type                = BLE_UUID_TYPE_BLE;
    bas_uuid.uuid                = BLE_UUID_BATTERY_SERVICE;

    p_ble_bas_c->conn_handle                = BLE_CONN_HANDLE_INVALID;
    p_ble_bas_c->peer_bas_db.bl_cccd_handle = BLE_GATT_HANDLE_INVALID;
    p_ble_bas_c->peer_bas_db.bl_handle      = BLE_GATT_HANDLE_INVALID;
    p_ble_bas_c->evt_handler                = p_ble_bas_c_init->evt_handler;

    return ble_db_discovery_evt_register(&bas_uuid);
}

Also, take a look at how the BLE_UUID_BATTERY_SERVICE is discovered in the ble_bas_on_db_disc_evt() in ble_bas_c.c.

I would test with the ble_app_hrs example first & when that works (it definitely should), then you can make the relevant changes in the multilink example. 

Even though the BLE_UUID_BATTERY_SERVICE is included in ble_srv_common.h, it is not discovered in ble_bas_on_db_disc_evt() or ble_bas_c_init().

[laran]

Ok, I am back on this issue and I have my Wireshark up and running gain, so that helps.

Now, when I look at my log in the initial post, the discovery starts with "Sent Find By Type Value Request" starting at 0x0001. All devices that manage to perform a discovery start with a "Sent Read By Group Type Response", then do the "... Find by Type...." based on what was was returned from the "... Read Group Response ..."

My basic question is, if  this is something that can be controlled when initializing the service discovery.

[Bjørn Kvaale]

Sorry for the delayed response. I have been on a business trip the past two weeks. From this message sequence chart, you can see that you can use variant 2: discover a specific service if you want to change how service discovery is done. If you take a closer look at the softdevice API, you should be able to modify the service discovery the way you want to.