ble_advdata_encode and 128-bit UUIDS

RE: ble_advdata_encode and 128-bit UUIDS

Susheel Nuguru — Tue, 17 Nov 2020 07:07:42 GMT

Sorry for the late reply David, Edvin became a new father and is on leave. I am responsible for this thread now.

[quote user="David Ormand"] Is Nordic recommending the use of the Advertising Module over the previous SD calls? (I'm sure the Advertising Module just wraps the SD calls in an easier-to-use framework.)[/quote]

Depends on your experience with Nordic solutions and also depends on your requirement. Advertising Module is a library and is more heavy weight than using the SD calls directly. A new user would find advertising module easier to use as it handles most of the pre and post processing functionality. But if your application does need the pre and post processing of an advertising packet to be more specific, then you can use the SD calls directly.

RE: ble_advdata_encode and 128-bit UUIDS

David Ormand — Fri, 06 Nov 2020 17:43:52 GMT

Yes, well, I used the throughput example as a baseline on the advice from another Nordic engineer in view of our concern about throughput. There's actually not much left of the Central capability left in our Peripheral-only program. I notice that in the UART example, advertising setup is done through the Advertising Module rather than the ble_advdata_encode() and sd_ble_gap_adv_set_configure() API. This is also true of the DFU service (which is included in our custom bootloader) and is presumably Apple-friendly. Is Nordic recommending the use of the Advertising Module over the previous SD calls? (I'm sure the Advertising Module just wraps the SD calls in an easier-to-use framework.)

RE: ble_advdata_encode and 128-bit UUIDS

David Ormand — Fri, 06 Nov 2020 17:36:07 GMT

Thanks, this was the tip I needed. I discovered I was setting up advertising _before_ setting up the custom service. sd_ble_uuid_vs_add() wasn't being called to register the vendor-specific UUID until after the the call to ble_advdata_encode(). Once I swapped those, I am getting the 128-bit UUID displayed in nRF Connect.

Along with a truncated Full Name. If I read the spec right, advertising data is (as you say) 31 bytes max. 128-bit UUID plus 1 byte length plus 1 byte data type* is 18 bytes. Flags is 1 byte data plus 1 byte length plus 1 byte data type, or 3 bytes. Name field plus 1 byte length plus 1 byte data type* is n + 2. Max n = 31 - 18 - 3 - 2 = 8. My program is truncating the name to 8 bytes.

This is interesting. The Apple guidelines say flags and UUID ("Services") are in the minimum recommended set of advertising data items. The guidelines also say that only three "legacy" advertising PDU types are allowed, with the 31-byte limit on advertising data. Therefore devices with vendor-specific UUIDs are limited to 8-byte names (or 5-byte names, if the also-recommended TX Power Level is included). I think the lesson is to just leave out the UUID and let the iPhone get the services through discovery, like everyone else.

RE: ble_advdata_encode and 128-bit UUIDS

Edvin — Thu, 05 Nov 2020 09:17:54 GMT

Hello,

I wouldn't recommend using the ble_app_att_mtu_throughput as a starting point for your application. The reason for this is that this example is a bit complex, and really intended only to test throughput. I suggest you look at how e.g. the ble_app_uart example includes the UUID in it's advertisement.

I know that it only takes BLE_UUID_NUS_SERVICE (0x0001) in advertising_init(), but as long as the service is initialized, there is some softdevice magic that includes the full 128 bit UUID. You can verify this by changing a byte in the UUID, and see that the advertisement changes as well.

Best regards,

Edvin

RE: ble_advdata_encode and 128-bit UUIDS

Turbo J — Thu, 05 Nov 2020 00:31:02 GMT

[quote userid="69444" url="~/f/nordic-q-a/67994/ble_advdata_encode-and-128-bit-uuids"]Or is uuid actually supposed to be an index into some array where the 128-bit UUID resides?[/quote]

Look at the type output value for sd_ble_uuid_vs_add().

Note that "Full Name" and 128 Bit UUID probably won't fit into a 31 byte advertizing data.