what am I trying to achieve: I want to read the value of a characteristic (of which I know the UUID) from a specific service (of which I know the UUID).
What's my approach:
- I scan for devices with gap_discover
- and wait for gap_scan_response and if I find a device, I check whether the advertising data fits my purposes (for simplicity's sake, I check only for now whether my desired service UUID is in the advertising data)
- after I've found it, I stop scanning with gap_end_procedure (here, I often get the first non 0x0000 result; still, scanning stops)
- I then connect with gap_open, which works (result 0x0000), and I receive a connection handle
- next, I tried two approaches, non of them worked: either I try gatt_discover_primary_services_by_uuid immediately, or only after I received the connection_opened event
- in both cases, gatt_discover_primary_services_by_uuid fails with either 0x0101 (invalid_conn_handle) or 0x0180 (invalid_param). It might be, that if in the previous step I wait for the connection_opened event, I only get 0x0180 here, but I am not sure.
However, I don't see why my params should be wrong. This is an example of the full byte array that I send over UART:
20 11 09 02 05 04 dd c0 da 2c ea ee b2 87 4f 17 6f e7 df 3e 4f
- it connects to connection 05
- is tries to discover the reverse of 04 dd c0 da 2c ea ee b2 87 4f 17 6f e7 df 3e 4f (I actually don't construct that manually but take the exact uuid as retrieved from gap_scan_response)
Is there actually something invalid? Or is it another issue of the "outdated" BLE stack?
The last parameter that you pass to cmd_gatt_discover_primary_services_by_uuid is of type uint8array. See the beginning of the API doc for explanation.
It seems to me that you are missing the length byte before the 128-bit UUID. You must also fix the 2nd byte that indicates length of the whole command. Fixed version would look something like this:
20 12 09 02 05 10 04 dd c0 da 2c ea ee b2 87 4f 17 6f e7 df 3e 4f
I was having this problem and it was because I wasn't waiting for the connection_opened event. The response to le_gap_open occurs right away, so there's no way it's attempted to establish a connection yet. I noticed that when I attempted to change connection parameters using le_gap_set_conn_parameters before calling open, the connection would not work. When I took that call out, it all worked fine.
If you're getting the connection_opened event, then you should be good. You should take the connection handle from the event, even though it should probably match the le_gap_open response. If you're still having problems, make sure there aren't any other messages coming in that you may be missing. Perhaps you're connecting and getting disconnected right away. The connection_closed notification will give you a reason code which you can look up in the spec.
If it's a connection issue, then maybe you need to do something different with the connection parameters.