Identifying beacons with 128 bit UUID

[Erblin]

Hi,

I am working on a project where I have 4 advertising beacons which will have to trigger some functions in the central side when it gets the advertising data. Now I am currently working on the central(ble_app_uart) side which will have to check each advertising packet, and from this it has to identify which beacon it is. In the beacon program I use the example code ble_app_beacon, what is the best way to identify each beacon? I thought maybe just use the 128 bit UUID but I am unsure how to implement this in the central side or if it is the best solution.

I know about this function: static bool is_uuid_present(const ble_uuid_t *p_target_uuid, const ble_gap_evt_adv_report_t *p_adv_report)

But ble_uuid_t is a 16 bit service UUID for the UART:

typedef struct { uint16_t uuid; /*< 16-bit UUID value or octets 12-13 of 128-bit UUID. */ uint8_t type; /*< UUID type, see @ref BLE_UUID_TYPES. If type is @ref BLE_UUID_TYPE_UNKNOWN, the value of uuid is undefined. */ } ble_uuid_t;

-Erblin

[endnode]

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

[FormerMember]

@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.