DFU Service in scan response advertising data

RE: DFU Service in scan response advertising data

Hung Bui — Tue, 20 Jun 2017 12:40:51 GMT

Note that the "UUID type", it not really a "type" it's the ID of the UUID base registered in the database in the softdevice, so if you have more than one UUID base , the type will be the the increment , start from BLE_UUID_TYPE_VENDOR_BEGIN = 0x02

RE: DFU Service in scan response advertising data

Guillaume Levant — Tue, 20 Jun 2017 09:28:05 GMT

The problem was solved : I had to split the advertising of the UUIDs between adv_data and sr_data. But there is one thing to know if you want to advertise the DFU Service UUID : You have to set the uuid struct of the device service the following way :

{BLE_DFU_SERVICE_UUID, 0x03}

The type of the UUID 0x03 is not defined in ble_types.h, but when you add trace to check the type of the UUID in the dfu service init, you can see that its type is 0x03.

Thank you endnode for your help !

Best regards,

Guillaume

RE: DFU Service in scan response advertising data

endnode — Mon, 19 Jun 2017 13:07:34 GMT

I'm afraid the only way "in the spirit of BT SIG spec" should be to indicate that your broadcast only partial UUID list and put only one 128-bit UUID there (probably the most "signature" or the most important one which should trigger your GAP/GATT application on Central/Client side). Then each device should do full GATT service discovery after connection and find all remaining services. If you don't like this then you can experiment with putting some of UUID list AD elements to both Advertising and Scan Response data. I believe it could work with Soft Device, it's just question if it won't confuse some of the listeners (mobile phones and similar devices I guess;)... this would need to be validated extensively by you/your team.

RE: DFU Service in scan response advertising data

Guillaume Levant — Mon, 19 Jun 2017 13:03:36 GMT

Hi Jan, Thank you for you anwer. Indeed 2 times 16 bytes is bigger than 31 bytes so I guess than even if the service UUID was the only thing I send through advertising, it would not work, thanks for this point that I forgot. At this moment I am sending the following informations through advertising : adv_data : advdata.name_type = BLE_ADVDATA_FULL_NAME; advdata.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;

sr_data : srdata.uuids_complete.uuid_cnt = sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]); srdata.uuids_complete.p_uuids = m_adv_uuids; srdata.p_tx_power_level = &tx_power;

Is there a more effective way to split it ? I don't think that I can split the array that contains the UUIDs for advertising, is it possible ?

Best regards,

Guillaume

RE: DFU Service in scan response advertising data

endnode — Mon, 19 Jun 2017 12:45:47 GMT

Hi Guillaume,

Both ADV_DATA and SCAN_RSP data are limited to 31B by BT SIG specification (not counting latest BT 5.0 extension). That includes GAP AD element's overhead (TAG and LENGTH bytes) so you are not able to put more than one 16-byte (128-bit) UUID string into either of these data fields. If you have some other AD objects there (which you typically have - e.g. mandatory AD Flags etc.) then your capacity goes even lower. Can you check what exact string are you trying to put into ADV. and SCAN RSP. data?

Cheers Jan