Custom 128bit UUID is Advertised Incorrectly

[k3nt]

Hello, 

I am having some trouble attempting to advertise a single custom 128bit uuid. I have two custom services sharing the same base uuid. Everything works correctly after connecting, the correct uuids show up for both services and chars. The problem is that the base uuid being advertised is completely wrong, and I'm not sure why. Oddly enough the service portion seems to work, which is 0x0100 and 0x0200 in my case, if I swap the services being advertised. I followed everything in this guide to be able to advertise a full 128bit UUID in the first place https://github.com/bjornspockeli/custom_ble_service_example . I'm using nRF5 SDK V15.0.0.

My defined custom UUID base is:

// EE84xxxx-43B7-4F65-9FB9-D7B92D683E36
#define DCS_BASE_UUID {{0x36, 0x3E, 0x68, 0x2D, 0xB9, 0xD7, 0xB9, 0x9F, 0x65, 0x4F, 0xB7, 0x43, 0x00, 0x00, 0x84, 0xEE}}

static ble_uuid_t m_adv_uuids[] = {{BLE_UUID_DCS_SERVICE, BLE_UUID_TYPE_VENDOR_BEGIN}};

but this is what is showing up in the advertisement packet:

82c90100-f315-4f60-9fb8-838830daea50

Any help as to where to start to debug would be much appreciated!

-Kent

[bjorn-spockeli]

Hi Kent, 

have you verified that sd_ble_uuid_vs_add() returns NRF_SUCCESS? 

Best regards

Bjørn

[k3nt]

Hi Bjorn,

Yes, it returns 0 for both custom services.

[mrono]

That seems to be the Nordic base UUID (BLE_NORDIC_VENDOR_BASE_UUID), mixed with the custom service UUID.

I recall seeing this earlier. If you have two vendor specific base UUIDs, the way many Nordic examples are written don't specify which one do you want to use.

[bjorn-spockeli]

mrono: Thanks for sharing. 
 k3nt: Then there must be something with the order of the function calls that adds the VS UUID and populated the GATT table . If you have multiple vendor specific base UUIDs then you must call  sd_ble_uuid_vs_add() before any sd_ble_gatts_service_add, sd_ble_gatts_characteristic_add or sd_ble_gatts_descriptor_add calls. 

[mrono]

I agree that the issue is caused by the order of operations. A Nordic service, possibly DFU or NUS, is initialized first. Therefore the first VS UUID in the table is the Nordic one. However, I don't think relying on the order is the proper way to fix this.

In my opinion the error is right here:

static ble_uuid_t m_adv_uuids[] = {{BLE_UUID_DCS_SERVICE, BLE_UUID_TYPE_VENDOR_BEGIN}};

BLE_UUID_TYPE_VENDOR_BEGIN basically means "The index of the first vendor specific base UUID". Here you don't want the first base UUID, but specifically the base UUID of the DCS_SERVICE.

The correct base UUID is available from p_cus->uuid_type once the service has been initialized. So I'd forget the m_adv_uuids[]-array entirely and get the correct value at runtime in advertising_init().

[k3nt]

mrono and bjorn-spockeliThank you both for your responses! mrono, it does seem that you were correct in your suspicion. I am in fact using the dfu service and was initializing it before my own custom services. I tested moving the dfu service init to after my service inits and now the correct UUID base is being advertised. I also agree with you very strongly that this is not a suitable solution, and nowhere have I ever seen mention of the importance in the order of service inits in regards to advertising. Would you be willing to expand more on how I could get the correct value at runtime in advertising_init() please!

-Kent

[mrono]

k3nt said:

Would you be willing to expand more on how I could get the correct value at runtime in advertising_init() please!

Try something like this in advertising_init():

    static ble_uuid_t adv_uuid;
    adv_uuid.uuid = BLE_UUID_DCS_SERVICE;
    adv_uuid.type = m_cus.uuid_type;

    // ....
    
    init.advdata.uuids_complete.uuid_cnt = 1;
    init.advdata.uuids_complete.p_uuids  = &adv_uuid;

Once you have initialized the custom service then m_cus.uuid_type holds the correct index to that service's base UUID.