Bluetooth advertising more than 31B data limit

[Lukáš]

Hello,

We just noticed that according to the Raw data detail in nRF Connect, we are able to advertise more than 31B data limit. Is that possible or do we incorrectly count the bytes in the advertising payload? This is a way how we do it:

length+ type + payload = xB
1 + 1 + 1 = 3B Flags
1 + 1 + 24 = 26B Manufacturer-specific data
1 + 1 + 4 = 6B Short name

Comes out to 35B in total and shouldn't be valid. However, it seems to be working, see screenshot below.

We are using nRF52833 and 1.3.1 NCS. Relevant code is:

void dt_bt_conn_adv_start_handler() {
    uint8_t manufDataBuff[]={0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00,
                             0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                             0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
    memcpy(manufDataBuff+4, odid_basic_data.UASID, sizeof(manufDataBuff)-4);
    struct bt_data dt_bt_conn_ad[] = {
        BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
        {
            .type = BT_DATA_MANUFACTURER_DATA,
            .data_len = sizeof(manufDataBuff),
            .data = manufDataBuff,
        }
    };

    int res = bt_le_adv_start(BT_LE_ADV_CONN_NAME, dt_bt_conn_ad, ARRAY_SIZE(dt_bt_conn_ad), NULL, 0);
    if(res == -EAGAIN) {
        LOG_INF("Start failed with EAGAIN. Delaying start");
        k_delayed_work_submit_to_queue(&dt_bt_work_q, &dt_bt_conn_adv_start_work, K_MSEC(500));
        return;
    }
    if (res) {
        LOG_ERR("Advertising failed to start (err %d)\n", res);
        return;
    }
    LOG_INF("Advertising connactable started");
    return;
}

[Einar Thorsrud]

Hi,

You are right. The advertising packet has room for up to 31 byte payload, and you calculation is correct (including length, type and data for each type of data).

Bu tit is a bit odd... I would not have expected you to be allowed to advertise this, and even if you are, I would not have expected the Android device to process the invalid packet. In fact, you should get a "Too big advertising data" error when starting advertising, so there must be something I am not seeing. Can you upload a minimal but complete project that reproduce this so that I can test on my side?

[Lukáš]

The easiest way how to reproduce is to run the Zephyr Beacon sample. It also advertises more than 31B, see screenshots below.

 

[Einar Thorsrud]

Hi,

Ah, I see. nRF Connect for Android is what causes the confusion. It shows the data from the advertising packet and scan response packet together, as if it was all from the advertising packet. But here, the complete local name (type 0x09 length12 in this case), is actually part of the scan response packet.

[Lukáš]

You are correct. I got even more confused because I didn't use any scan response in code or even in advertising parameters. See code line below:

bt_le_adv_start(BT_LE_ADV_CONN_NAME, dt_bt_conn_ad, ARRAY_SIZE(dt_bt_conn_ad), NULL, 0);

However, when you use BT_LE_ADV_CONN_NAME parameter instead of BT_LE_ADV_CONN, it automatically puts the CONFIG_BT_DEVICE_NAME into scan response.

Thanks for figuring this out.