RE: Identifying beacons with 128 bit UUID

FormerMember — Wed, 29 Mar 2017 12:57:23 GMT

@Erblin : The function is_uuid_present() is the function you want to use for identifying a 128-bit UUID.

For custom/vendor specific UUIDs, the UUID should be added to the softdevice using sd_ble_uuid_vs_add(). When using that function, the 128-bit UUID is added to a table internally in the softdevice. The out parameter from sd_ble_uuid_vs_add() is the index in the table where the UUID is located. As stated in the documentation for sd_ble_uuid_vs_add(), the function will disregard byte 12 and 13 of the UUID (they are set to '0' in the internal table).

The struct ble_uuid_t has two members:

type: The index in the table where the UUID can be found.
uuid: A 16-bit UUID (2 bytes), corresponding to byte 12 and 13 that were disregarded when the 128-bit UUID was added to the softdevice.

The example ble_app_uart_c uses is_uuid_present() to identify ble_app_uart peripheral devices.

RE: Identifying beacons with 128 bit UUID

endnode — Tue, 28 Mar 2017 14:06:20 GMT

Hi Erblin,

UUID is name of Service (literally) or in other words name of application (this is not 100% accurate but as GATT Services are used as atomic block by every Application which is using GATT/GAP we can imagine it like that). If your application don't use BLE Connection or is able to workaround uncertainty of name on GATT layer (because you would be assigning different UUID to each device) then you could go that way. However normally device identification is either GAP device name (also possible to include into ADV_IND packet) or even more commonly Adv. address (6-byte MAC visible in every packet on LL layer).

When it comes to UUID usage and management in BLE and Nordic stack (Soft Device) specifically is another wider topic. In short there are always "long" 16-byte (128-bit) UUIDs but BT SIG defines so called "base" UUID (and one specific value is assigned to all BT SIG UUIDs) and then 2-byte (16-bit) range which can be called "short" UUID. So if you see 2-byte UUIDs in actual BLE packet then it means some standard object (Service/Characteristic/Descriptor) UUID defined by BT SIG spec. All other UUIDs should be exposed in "long" form but they can be again imagined as 128-bit "base" UUID (no with custom value) and "short" 2-byte range on top of it. This is how Nordic stack represents (in some APIs like GATT Server) UUIDs and that's what is explained in the code snapshots above. If you want to define your UUID then you cannot use BT SIG hence you define your own "base" UUID and 2-byte "short" UUIDs on top of it and work with these structures on top of Nordic SD GATT API calls/structures.

Cheers