nrf52 advertising multiple services

[Sébastien Schiesser]

Hi,

Similar questions have already been posted but they don't seem to fit to my problem...

Basically I want to advertise 3 primary services, starting from the 'experimental_ble_app_blinky' example: the already provided lbs service and two new ones. For the moment, the new services are just copy-pasted-renamed from the lbs and are correctly initialized.

I made three modifications:

• in advertising_init

  ble_uuid_t adv_uuids[] = {{LBS_UUID_SERVICE, m_lbs.uuid_type}, {OWN_UUID_SERVICE, m_own.uuid_type}, {MY_UUID_SERVICE, m_my.uuid_type}};

  advdata.name_type = BLE_ADVDATA_SHORT_NAME;

• in softdevice_enable_get_default_config

  p_ble_enable_params->common_enable_params.vs_uuid_count = 3;

As RK often suggests, I set a breakpoint at the ble_advdata_set function and got NRF_ERROR_DATA_SIZE. That's good to know, but I haven't any clue to reduce my advertisment data after reducing to short_name and using the scan response (as the example already does). If I correctly understood the functions, it seems that each service uuid is encoded and needs a size of 0x10 for that... what is definetly too large when the maximum size is 0x1F.

Any suggestions about how to advertise 3 services and remain within the advertising size limitations?

Thanks a lot!

[endnode]

Until extended broadcasting data are supported (as per BT 5.0) - and probably even then because you will like to maintain backward compatibility with BT 4.0/4.1/4.2 devices - you need to live with several limitations:

• There are only 62 bytes available on GAP Broadcaster/Peripheral side.
• These 62 bytes are divided into Adv. and Scan Resp. data while each cannot exceed 31 bytes (so none of strings can exceed 31 bytes).
• And to be compliant to BT LE GAP you need to encapsulate all data to valid AD objects which have 2-byte overhead (at least = length and tag/id).

By simple math you can see that it will be pretty hard to put 3 custom (128-bit = 16-byte) UUIDs there because they should be in one AD object and that would be longer then 31 bytes. You can try to set multiple of "Incomplete List of 128-bit Service Class UUIDs" AD objects and fit 2 such UUIDs there (one to Adv. data and second to Scan Resp. data) but look-up BT SIG Core spec if that is allowed.

[razormomo]

Hello endnode sorry for old / late question.  How does one set up multiple  "Incomplete List of 128-bit service class UUIDs"?  I can see this advertisement detail when I have created a peripheral with multiple services (created with NimBLE on an ESP32.  I was hoping to implement the same behavior.  Your explanation makes sense as described.

[endnode]

It depends what exact SDK architecture/version do you use, this is really old post. But you should be able to control what goes to ADV_IND and SCAN_RSP packets independently so you can add AD elements as you like. There are few rules set by Bluetooth Core spec and also few rules enforced by Bluetooth LE stack implementation on GAP layer. SO the question is which AD elements are allowed to be placed in both packets and which must be advertised only once.

(based on quick look to Core Specification Supplement doc v11 it should be permitted to have multiple Service UUID objects in the broadcasts...)

[razormomo]

Thank you for the reply.  I am on nRF Connect SDK 2.5.1 which is a bit newer than the domain of SDks discussed in this post.  I will check the core specs.