Service Discovery Failed using pc-ble-driver

[mmercier]

I am using an nRF52840 Dongle to try and connect to a product over Bluetooth and communicate with it. I have been able to open this dongle using nRF Connect Bluetooth Low Energy, and can successfully find my product, connect to it, and write to its characteristics. I am now needing to use a C program to do this same thing.

I have downloaded the pc-ble-driver, created a project in my C IDE, and copied the code from the heart rate collector example to be the project's source file. I got the project to build without issue, and following the instructions in the examples github page, have flashed the dongle with the correct firmware to allow the c program to connect to it. I am able to successfully connect to the dongle's COM port and scan for devices.

I did have to make some modifications to the source file. My product I want to connect to doesn't advertise its name, so I was unable to connect to it even when finding it. This product does, however, advertise the Manufacturer Specific Data field, and after some trial and error, I was able to modify the find_adv_name routine to instead check for Manufacturer Specific Data, and I was able to connect to the device this way.

After this, I get output strings that read: "Connection Established", "Discovering Primary Services", and "Received Service Discovery Response". However, I then get an error message saying "Service Discovery Failed. Error Code 0x10A". Stepping through the code, this error is getting set after the "on_connected" routine is finished, but before starting the on_service_discovery_response routine.

I have changed the value of BLE_UUID_HEART_RATE_SERVICE to match the UUID of my product's service, but there was no effect. I had also been told in the past to try changing the srvc_uuid.type from BLE_UUID_TYPE_BLE to BLE_UUID_TYPE_VENDOR_BEGIN, but when doing this, I get a failure returned from the function "sd_ble_gattc_primary_services_discover", with the error code 0x8005, which seemingly corresponds to NRF_ERROR_SD_RPC_NO_RESPONSE. 

Could anyone give me any pointers for where to look for what all to change in the source code in order to connect to my product rather than whatever heart rate monitor it is expecting? Thanks!

[mmercier]

I did end up fixing that, it didn't have an effect.

I'm not sure what you mean about the callback event, I don't have access to the code that is running on the peripheral. I am just connecting to it and monitoring its parallel bus.

I did some experimenting, and I tried setting the write_params.handle value to m_hrm_char_handle1 instead of m_hrm_char_handle2. This is a variable I intend to use for one of the other characteristics, but for now, I'm only discovering the "write" characteristic, which is being stored in m_hrm_char_handle2.

So basically, I tried calling the same command with a non-assigned, zero-value handle as the write_params.handle value, and I got the same response. As in, there was no error code, and the event handler went into the state for BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE. I was surprised to not see some error. This makes me wonder if my command is actually doing anything with the actual handle being used. For what it's worth, I did pause the code to check and ensure my m_hrm_char_handle2 value is set to the characteristic's handle that was discovered, and that the discovered characteristic's UUID is the "write" characteristic I'm wanting to use.

[mmercier]

I think there may be an issue...

I changed my discovery routines to search instead for the first characteristic, which is notify only. I discovered it correctly, and then had my function write to its handle, and I got no error messages, and the handler went into the BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE state. This characteristic does not have write privileges, it is notify only, so I think I should see some failure somewhere. So something is not writing correctly.

[mmercier]

I finally figured it out!

So when I had searched for descriptors after getting my characteristics, I was getting a couple of different values, some with UUIDs that were different from what I expected to see, based on the values in nRF Connect. For each characteristic, one of the descriptors I could receive would have the same UUID as the characteristic, but with a different handle.

Turns out, I needed to pass THIS handle to the write_params, not the handle of the characteristic. Now, my write command is working, and I can see the data on the peripheral's bus!

I also verified my other questions for myself, I was able to figure out how to toggle notifications, and get back the notification data read on a characteristic.

I think I've finally got everything I need for this project! Thanks for the help!