AN36 modifications

RE: AN36 modifications

michurin — Fri, 06 Dec 2013 19:32:37 GMT

I need more time to read books/specs, examples of actual implementation and personal experience to digest what you've been saying... In any rate AN36 is a pretty good starting point and of course it could be and should be better but so far this is the best tutorial already. Hope that our discussion will help it to become even better.

My regards, Boris.

RE: AN36 modifications

Ole Morten — Fri, 06 Dec 2013 14:30:55 GMT

Each field in the advertisement and scan response packets have a type, and when you use the complete UUID list as type, I'd say that you are required to actually have all services in this exact field. If you have one field in the advertisement packet which have the complete type, and one field in the scan response with the complete type, neither of them are actually complete, and I'd hence say that you don't fulfill the specification.

This is exactly why you have the more available type, and are also not required to have all services in the advertisement packet. I'd normally recommend you to have the primary service of the device in the advertisement, and leave out all others. In some cases you may have multiple equally important services, and if so, you may need/want to split them between the advertisement and scan response, but then by using the more available type for both fields.

RE: AN36 modifications

michurin — Fri, 06 Dec 2013 14:24:02 GMT

Dear Ole,

Thank you very much for your help, support and patience. Could you please add more details and extend this paragraph:

Based on my understanding of the spec however, I don't think it would normally be legal to have uuids_complete split between advertisement data and scan response. The reason is that each packet should be valid in itself, but if you have only some services in a field marked as uuid_complete, your field doesn't actually contain what the type implies. If you want to share the list between the packets, I'd therefore recommend you to use more_available.

What confuses me is if I do have a proprietary device with some unique service(s) but also want to have same defined services like the battery, temperature, proximity. The list can become lengthy and may not fit, so how to do it the right way?

Thank you.

RE: AN36 modifications

Ole Morten — Fri, 06 Dec 2013 09:23:31 GMT

You can get any kind of advertisement and scan response data you want, by just using sd_ble_gap_adv_data_set() directly if ble_advdata doesn't allow you to do what you want. In that case, you must however do the parsing and data setup yourself.

Based on my understanding of the spec however, I don't think it would normally be legal to have uuids_complete split between advertisement data and scan response. The reason is that each packet should be valid in itself, but if you have only some services in a field marked as uuid_complete, your field doesn't actually contain what the type implies. If you want to share the list between the packets, I'd therefore recommend you to use more_available.

(In your case this is somewhat different, since you have one 128-bit UUID and one 16-bit UUID, so you could probably achieve what you want and be compliant by having the type of fields be different (see Core specification, Volume 3, Part C, table 18.2), but this seems to be a corner case.)

RE: AN36 modifications

michurin — Thu, 05 Dec 2013 19:51:59 GMT

This is what I ended up with:


static void advertising_init(void)
{
    uint32_t      err_code;
    ble_advdata_t advdata, scanrsp;
    uint8_t       flags = BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE;
    
    // YOUR_JOB: Use UUIDs for service(s) used in your application.
    ble_uuid_t adv_uuids[] = 
    {
        {BLE_UUID_BATTERY_SERVICE, BLE_UUID_TYPE_BLE},
        {LBS_UUID_SERVICE, m_lbs.uuid_type}
    };

    // Build and set advertising data
    memset(&advdata, 0, sizeof(advdata));
    
    advdata.name_type               = BLE_ADVDATA_FULL_NAME;
    advdata.include_appearance      = true;
    advdata.flags.size              = sizeof(flags);
    advdata.flags.p_data            = &flags;

    memset(&scanrsp, 0, sizeof(scanrsp));
    scanrsp.uuids_complete.uuid_cnt = sizeof(adv_uuids) / sizeof(adv_uuids[0]);
    scanrsp.uuids_complete.p_uuids  = adv_uuids;
    
    err_code = ble_advdata_set(&advdata, &scanrsp);
    APP_ERROR_CHECK(err_code);
}

Does this mean that because of implementation of SD110 x.uuids_complete can not be splitted between advdata and scanrsp?

RE: AN36 modifications

Ole Morten — Thu, 05 Dec 2013 11:08:53 GMT

Sorry, the method name was a typo from my part, it is sd_ble_gap_adv_data_set(), which as you can see is the final call of ble_advdata_set().

It seems that current softdevices will initialize the appearance to 0x1234, but this will most likely be changed in future versions to just 0. If you want to, you can set appearance to one of the values from this list: https://developer.bluetooth.org/gatt/characteristics/Pages/CharacteristicViewer.aspx?u=org.bluetooth.characteristic.gap.appearance.xml

As for the latter part of your question, I'm not sure I understand it. With the S110, you can change the advertising data at any time, by either calling sd_ble_gap_adv_data_set() or ble_advdata_set(). You can however not advertise more than 31 bytes in the advertisement packet and 31 bytes in the scan response, and all data must be part of some advertising type as defined in the specification.

RE: AN36 modifications

michurin — Thu, 05 Dec 2013 04:58:49 GMT

I'm assuming that > the source code for ble_advdata you mean file ble_advdata.c but in any case I do not see sd_ble_advdata_set(): not in this file nor anywhere else. Also there is a function sd_ble_gap_appearance_get(). Should it not return what sd_ble_gap_appearance_set() sets? Template uses


    /* YOUR_JOB: Use an appearance value matching the application's use case.
    err_code = sd_ble_gap_appearance_set(BLE_APPEARANCE_);
    APP_ERROR_CHECK(err_code); */

AN36 doesn't have this snippet or I missed it but somehow appearance gets initialized to 0x1234 and the code is not for debugging... I'm sorry for the next question because I'm sure BLE Core v.4 has the answer but having advertisement package and the scan response limits is limiting to less than 62 bytes. What am I missing? Or if it is necessary one can modify ads by changing my advertisement data?

Thanks.

RE: AN36 modifications

Ole Morten — Wed, 04 Dec 2013 16:43:18 GMT

I assume the user who wrote that means that he removed some of the services and then shortened his name.

There isn't any magic way to know how large the packet is, but if you look at the source code for ble_advdata, you can see the raw packet as passed to sd_ble_advdata_set(). This is the size of advertising data as seen on air. You can also take a look at the Core Specification, Volume 3, Part C, chapter 11, which details the different fields available.

There isn't any right or wrong way to separate data between the advertisement packet and scan response, you are more or less free to choose as you see fit. The only exception I'm aware of is that you are allowed to have the name only one place, and that the Flags field shall be in the advertisement. You may also want to consider Apple's recommendations in section 3.4 of their Bluetooth Accessory Design Guidelines, if that is a target platform of yours: https://developer.apple.com/hardwaredrivers/bluetoothdesignguidelines.pdf

RE: AN36 modifications

michurin — Wed, 04 Dec 2013 13:53:29 GMT

Thank you for the reply. I do not understand what this exactly means:> I dropped the other services and pared the name down.

Also, I'm aware of size limitations but how does ble_advdata_t is converted into the message, so I can count it's size? Sorry I didn't find this in ble_advdata.h. How to split correctly long message between the advertisement package and the scan response. Could you please point me to an example.

Thank you.

RE: AN36 modifications

Ole Morten — Wed, 04 Dec 2013 12:04:33 GMT

If you want to advertise a regular Bluetooth SIG service like the battery service, you should use BLE_UUID_TYPE_BLE and not m_lbs.uuid_type. Using the latter will set the Battery Service's 16-bit UUID on top of the Led Button service's base UUID, which is not what you want.

The error 0x0C shows that your advertisement packet is too big. For details, take a look at this and this question, and also section 4.4.6 of the application note.