Proper setup of m_adv_uuids for custom service

[ejg2putt]

We have our nrf52 working well with our iOS app - almost everything we need is in place. One last item (haha) we've been struggling with is to get the nrf52 to advertise our services properly. We've been working around this for awhile, but to get iOS to reconnect in the background, and for our OTA (we're using the Rigado module), we need our services to advertise properly.

Based on these links:

devzone.nordicsemi.com/.../ devzone.nordicsemi.com/.../

and a few others, I believe the correct way to do this is something like this. Add service to the m_adv_uuid as such:

static ble_uuid_t m_adv_uuids[] = {
                                {BLE_UUID_TX_POWER_SERVICE,         BLE_UUID_TYPE_BLE},
                                  {BLE_UUID_BATTERY_SERVICE,            BLE_UUID_TYPE_BLE},
                                  {BLE_UUID_DEVICE_INFORMATION_SERVICE, BLE_UUID_TYPE_BLE},
                                  {OUR_SERVICE, BLE_UUID_TYPE_VENDOR_BEGIN}
};

and then add it as a scan response:

ble_advdata_t srdata;
memset(&srdata, 0, sizeof(srdata));

srdata.uuids_complete.uuid_cnt = sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]);
srdata.uuids_complete.p_uuids  = m_adv_uuids;

But everything we've tried produces code that doesn't run - we get errors are various parts of the init process. The two links seem to provide conflicting info as to where the UUID provided for our service in m_adv_uuid is the 16 or 128 flavor.

It seems like the srdata.uuids_complete structure may not get setup correctly based on what's exactly put in m_adv_data.

Our environment is make/gcc on Mac, using SDK 11.0.0. The only sample code I could find that uses BLE_UUID_TYPE_VENDOR_BEGIN was the UART stuff, and that didn't seem to apply(??).

Any pointers are appreciated.

Ed

[RK]

What errors are you getting? What are the actual error codes, just saying you get errors is too vague to really help.

of course your UUID is the 128 bit version, all custom UUIDs are 128 bits.

Don't use BLE_UUID_TYPE_VENDOR_BEGIN, use the actual value returned from the sd_ble_uuid_vs_add() function.

Apart from that, you have the correct way of adding a list of UUIDs to the scan response data, so you need to tell us which function is producing and error and what the error is.

[ejg2putt]

Thanks for the quick response Rols. ble_advertisting_init() is returning a "7". I don't have a lot of detail beyond that, as we're using the UART for a different comm channel, and we don't have TWI fully functional yet (i.e. TWI will be our debugging interface).

sd_ble_uuid_vs_add() returns a ble_uuid.type of "2", which is the same as BLE_UUID_TYPE_VENDOR_BEGIN, which of course, produces the same results.

[RK]

If you're using a segger you can use RTT for debugging, very easy and requires no setup.

7 is 'Invalid Parameter' I believe, there aren't many thing which will return that from the advertising encoder, but there are a few. if all you put in was the list of ids I don't see why you'd get that error message, have you set some other options too?

The easiest thing to do is single step the advertising data encode function and find out where it's blowing up.

[ejg2putt]

Yes, 7 is Invalid Parameter. It was invalid because advertising_init() was being called before service_init() - which we took directly from the hrs app. Swapping the order fixes the problem.

So to summarize to advertise a custom service UUID:

• Initialize the 128 bit UUID with sd_ble_uuid_vs_add().
• If you're not using scan data for ble_advertising_init(), m_adv_data goes in advdata, but you'll probably need a short name
• You can use scan data in ble_advertising_init() for one custom UUID, not room for more.
• The UUID you put into m_adv_uuids[] is the 16 bit short version of your long UUID.
• Make sure you call service_init() before advertising_init() .

Thanks again Rols, please edit my bullet points if any of them are not correct.