RE: GATT client (ANCS example) : adding ANCS UUIDs on the client app

Hung Bui — Sun, 07 Jun 2015 09:21:52 GMT

@Paolo: Have the answer from ppartierno and endnode answered your question ? If they did, please accept them as answered.

RE: GATT client (ANCS example) : adding ANCS UUIDs on the client app

endnode — Sun, 31 May 2015 00:22:30 GMT

Looks like this thread has some answers;) Cheers Jan

RE: GATT client (ANCS example) : adding ANCS UUIDs on the client app

Bill Siever — Fri, 29 May 2015 21:43:03 GMT

In order to know which service you are connecting to you will need UUIDs. If you take a look at service_disc_req_send() (in ble_ancs.c) you will see that it uses BLE_UUID_TYPE_VENDOR_BEGIN, which was set by the first sd_ble_uuid_vs_add().

(I think the dependencies between the main()/driver and the ble_ancs module are a little messy, since the ancs module depends on the main module setting the ANCS UUID before any others. Maybe it would be better if there were a function to add a new UUID and also get its offset. Then modules, like ancs, could add their own vendor UUIDS and know the index of them)

(an update: I didn't address the last three ble_vs_uuids_assign()s originally)
Some of the other gattc call backs that are used by ancs (for characteristic discovery & service discovery) will return a type of BLE_UUID_TYPE_UNKNOWN if the corresponding UUIDs don't match anything that's already in ble_vs_uuids_assign(). Although the documentation isn't clear, this probably means that the shortened 16-bit identifier wouldn't be valid, which would prevent the if-statements in the ancs module from correctly identifying the characteristics/services that have been discovered. (Given the way UUIDs are represented in the Nordic implementation, returning "UNKNOWN" this is a reasonable restriction that avoids any ambiguity)