Adding scan response gives invalid flags

RE: Adding scan response gives invalid flags

Simonr — Tue, 02 Jun 2020 07:17:20 GMT

You're right, it's not very easy to understand, and it seems like the part about the local name isn't relevant. I will report this internally and hopefully, we'll clarify this note in a future release. Thank you for your suggestion!

Best regards,

Simon

RE: Adding scan response gives invalid flags

brianreinhold — Fri, 29 May 2020 13:20:29 GMT

I guess it is best to ignore the note. I have checked on the air and the advertisement and scan response are what I expect given how I have populated it. And I DO duplicate the name in both. So that is clearly not an issue. Might I suggest that the Note say the both the adv and scan response are limited to 31 bytes? The rest of the text makes no sense and is not even true as I can duplicate the name.

RE: Adding scan response gives invalid flags

Simonr — Fri, 29 May 2020 09:44:46 GMT

Yes, that is correct, both advertisement and scan response are 31 bytes each.

Best regards,

Simon

RE: Adding scan response gives invalid flags

brianreinhold — Fri, 29 May 2020 08:40:56 GMT

Still sounds weird but I took the flags out of the scan response but not the duplicate name. I no longer get the error and it looks like it worked ... BUT I did not check it on the air.

IN any case, I am still not sure of the limitation. I have plenty of room byte-wise...(I am assuming 31 bytes in the adv and 31 bytes in the scan response. Is that not true?

RE: Adding scan response gives invalid flags

Simonr — Fri, 29 May 2020 07:57:14 GMT

"Limitations imposed by this API call to the data provided include having a flags data type in the scan response data and duplicating the local name in the advertising data and scan response data." means that the scan response data is limited to, and therefore can not include flags or duplicates of the local name. I can see how this can be misunderstood and I'm sorry you did. Hopefully, this clarifies things for you.

Best regards,

Simon

RE: Adding scan response gives invalid flags

brianreinhold — Thu, 28 May 2020 12:46:38 GMT

That's what I thought, but the documentation specifically says that I have to do it! That is what confused the life out of me.

Here I quote the documentation:

/**@brief Configure an advertising set. Set, clear or update advertising and scan response data.
 *
 * @note  The format of the advertising data will be checked by this call to ensure interoperability.
 *        Limitations imposed by this API call to the data provided include having a flags data type in the scan response data and
 *        duplicating the local name in the advertising data and scan response data.
 *
 * @note In order to update advertising data while advertising, new advertising buffers must be provided.
 *
 * @mscs
 * @mmsc{@ref BLE_GAP_ADV_MSC}
 * @mmsc{@ref BLE_GAP_WL_SHARE_MSC}
 * @endmscs
 *
 * @param[in,out] p_adv_handle                         Provide a pointer to a handle containing @ref BLE_GAP_ADV_SET_HANDLE_NOT_SET to configure
 *                                                     a new advertising set. On success, a new handle is then returned through the pointer.
 *                                                     Provide a pointer to an existing advertising handle to configure an existing advertising set.
 * @param[in]     p_adv_data                           Advertising data. If set to NULL, no advertising data will be used. See @ref ble_gap_adv_data_t.
 * @param[in]     p_adv_params                         Advertising parameters. When this function is used to update advertising data while advertising,
 *                                                     this parameter must be NULL. See @ref ble_gap_adv_params_t.
 *
 * @retval ::NRF_SUCCESS                               Advertising set successfully configured.
 * @retval ::NRF_ERROR_INVALID_PARAM                   Invalid parameter(s) supplied:
 *                                                      - Invalid advertising data configuration specified. See @ref ble_gap_adv_data_t.
 *                                                      - Invalid configuration of p_adv_params. See @ref ble_gap_adv_params_t.
 *                                                      - Use of whitelist requested but whitelist has not been set,
 *                                                        see @ref sd_ble_gap_whitelist_set.
 * @retval ::BLE_ERROR_GAP_INVALID_BLE_ADDR            ble_gap_adv_params_t::p_peer_addr is invalid.
 * @retval ::NRF_ERROR_INVALID_STATE                   Invalid state to perform operation. Either:
 *                                                     - It is invalid to provide non-NULL advertising set parameters while advertising.
 *                                                     - It is invalid to provide the same data buffers while advertising. To update
 *                                                       advertising data, provide new advertising buffers.
 * @retval ::BLE_ERROR_GAP_DISCOVERABLE_WITH_WHITELIST Discoverable mode and whitelist incompatible.
 * @retval ::BLE_ERROR_INVALID_ADV_HANDLE              The provided advertising handle was not found. Use @ref BLE_GAP_ADV_SET_HANDLE_NOT_SET to
 *                                                     configure a new advertising handle.
 * @retval ::NRF_ERROR_INVALID_ADDR                    Invalid pointer supplied.
 * @retval ::NRF_ERROR_INVALID_FLAGS                   Invalid combination of advertising flags supplied.
 * @retval ::NRF_ERROR_INVALID_DATA                    Invalid data type(s) supplied. Check the advertising data format specification
 *                                                     given in Bluetooth Specification Version 5.0, Volume 3, Part C, Chapter 11.
 * @retval ::NRF_ERROR_INVALID_LENGTH                  Invalid data length(s) supplied.
 * @retval ::NRF_ERROR_NOT_SUPPORTED                   Unsupported data length or advertising parameter configuration.
 * @retval ::NRF_ERROR_NO_MEM                          Not enough memory to configure a new advertising handle. Update an
 *                                                     existing advertising handle instead.
 * @retval ::BLE_ERROR_GAP_UUID_LIST_MISMATCH Invalid UUID list supplied.
 */
SVCALL(SD_BLE_GAP_ADV_SET_CONFIGURE, uint32_t, sd_ble_gap_adv_set_configure(adapter_t *adapter, uint8_t *p_adv_handle, ble_gap_adv_data_t const *p_adv_data, ble_gap_adv_params_t const *p_adv_params));

As I stated in the initial post the @Note was very confusing and did not make any sense but I did as it says

 * @note  The format of the advertising data will be checked by this call to ensure interoperability.
 *        Limitations imposed by this API call to the data provided include having a flags data type in the scan response data and
 *        duplicating the local name in the advertising data and scan response data.

and duplicated the flags and name in the scan response.

If that is not what the @Note is saying, what is it telling me to do?

RE: Adding scan response gives invalid flags

Simonr — Thu, 28 May 2020 12:10:23 GMT

Thank you for specifying!

I see that you have set the advertising flags in your scan response as well. Adding advertising flags in the scan response isn't allowed, and will return the INVALID FLAGS error that you're seeing. I'm struggling to see why you have written "Required Nordic duplicate" regarding these? We don't use advertising flags in scan responses in any of our examples. Please try removing these flags from your scan response data.

Best regards,

Simon

RE: Adding scan response gives invalid flags

brianreinhold — Wed, 27 May 2020 14:04:33 GMT

The advertisement alone does NOT give the invalid flags. Only when I try to add the scan response. Here is the code. All the flag settings are defined by Nordic. They should be valid. Note that this is the pc-ble-driver and the code is on a PC. I am making direct calls to the sd_* methods via the pc-ble-driver serial interface.

Note further that the code to populate the scan response is commented out because its addition causes the INVALID FLAGS error. Without it, the code works.

static ble_gap_adv_params_t     m_adv_params;
static ble_gap_adv_data_t m_adv_data;
static uint8_t  data_buffer[BUFFER_SIZE];
static uint8_t  scan_rsp_buffer[BUFFER_SIZE];

uint32_t advertisement_data_set(adapter_t* adapter, uint8_t* advHandle, short int* serviceUuids,
    int length, uint8_t* service128Uuids, const char* friendlyName)
{
    uint32_t error_code;
    uint8_t  index = 0;
    uint8_t  scan_index = 0;
    uint8_t  i = 0;
    char printBuf[256];
    memset(printBuf, 0, 256);
    memset(data_buffer, 0, sizeof(data_buffer));
    memset(scan_rsp_buffer, 0, sizeof(scan_rsp_buffer));

    const uint8_t name_length = (uint8_t)strlen(friendlyName);

    // Set the flags - important to indicate no EDR/BR support for some Androids
    // Actually by spec one is SUPPOSED to set one of the discoverable flags to be discoverable.
    data_buffer[index++] = 2;        // length of flags data type
    data_buffer[index++] = BLE_GAP_AD_TYPE_FLAGS;
    data_buffer[index++] = BLE_GAP_ADV_FLAG_LE_GENERAL_DISC_MODE | BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED;    // No EDR/BR support and general discoverable

    // Required Nordic duplicate for the scan response
    scan_rsp_buffer[scan_index++] = 2;        // length of flags data type
    scan_rsp_buffer[scan_index++] = BLE_GAP_AD_TYPE_FLAGS;
    scan_rsp_buffer[scan_index++] = BLE_GAP_ADV_FLAG_LE_GENERAL_DISC_MODE | BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED;

    // Set the device name.
    if (friendlyName != NULL)
    {
        data_buffer[index++] = name_length + 1; // Device name + data type
        data_buffer[index++] = BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME;
        memcpy((char*)&data_buffer[index], friendlyName, name_length);
        index += name_length;
    }

    // Set the device full name as a copy in the scan response.
    if (friendlyName != NULL)
    {
        scan_rsp_buffer[scan_index++] = name_length + 1; // Device name + data type
        scan_rsp_buffer[scan_index++] = BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME;
        memcpy((char*)&scan_rsp_buffer[scan_index], friendlyName, name_length);
        scan_index += name_length;
    }

    if (serviceUuids != NULL)
    {
        // Set the device's available services.
        data_buffer[index++] = 1 + 2 * length;
        data_buffer[index++] = BLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_COMPLETE;
        for (i = 0; i < length; i++)
        {
            // Store in little-endian format.
            data_buffer[index++] = serviceUuids[i] & 0xFF;
            data_buffer[index++] = (serviceUuids[i] & 0xFF00) >> 8;
        }
    }

    // Scan response:
    if (service128Uuids != NULL)
    {
        scan_rsp_buffer[scan_index++] = 1 + 16; //(only room for one)
        scan_rsp_buffer[scan_index++] = BLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_MORE_AVAILABLE;
        // Store in little-endian format.
        memcpy(&scan_rsp_buffer[scan_index], service128Uuids, 16);
        scan_index = scan_index + 16;
    }


    ble_gap_adv_properties_t adv_properties;
    adv_properties.type = BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED;
    adv_properties.anonymous = 0;
    adv_properties.include_tx_power = 0;

    m_adv_params.properties = adv_properties;
    m_adv_params.filter_policy = BLE_GAP_ADV_FP_ANY;
    m_adv_params.duration = BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED;
    m_adv_params.p_peer_addr = NULL;
    m_adv_params.interval = ADVERTISING_INTERVAL_40_MS;
    m_adv_params.max_adv_evts = 0;
    m_adv_params.primary_phy = BLE_GAP_PHY_AUTO;
    m_adv_params.secondary_phy = BLE_GAP_PHY_AUTO;
    m_adv_params.channel_mask[0] = 0;
    m_adv_params.channel_mask[1] = 0;
    m_adv_params.channel_mask[2] = 0;
    m_adv_params.channel_mask[3] = 0;
    m_adv_params.channel_mask[4] = 0;

    memset (&m_adv_data, 0, sizeof(m_adv_data));

    m_adv_data.adv_data.p_data = data_buffer;
    m_adv_data.adv_data.len = index;
 //   m_adv_data.scan_rsp_data.p_data = scan_rsp_buffer;
 //   m_adv_data.scan_rsp_data.len = scan_index;

    printf("Advertising data set\n");
    printf("Advertisement %s\n", byteToHex(m_adv_data.adv_data.p_data, &printBuf[0], ", ", m_adv_data.adv_data.len));
  //  if (scan_index > 0)
  //  {
  //      memset(printBuf, 0, 256);
  //      printf("Scan Response %s\n", byteToHex(m_adv_data.scan_rsp_data.p_data, &printBuf[0], ", ", m_adv_data.scan_rsp_data.len));
  //  }

    error_code = sd_ble_gap_adv_set_configure(adapter, advHandle, &m_adv_data, &m_adv_params);

    if (error_code != NRF_SUCCESS)
    {
        if (error_code == 10)
        {
            printf("Failed to set advertisement data. Error code: invalid flags\n");
        }
        else
        {
            printf("Failed to set advertisement data. Error code: 0x%02X\n", error_code);
        }
        fflush(stdout);
        return error_code;
    }
    fflush(stdout);
    return NRF_SUCCESS;
}

RE: Adding scan response gives invalid flags

Simonr — Wed, 27 May 2020 12:25:09 GMT

The ble_app_uart example, for one, in the SDK uses scan response data for adding UUID (see the srdata calls in the advertising_init() function). What advertising flag(s) are you setting in order to receive the INVALID FLAGS return error?

You can also check out our Bluetooth Low Energy Services tutorial, which explains in detail how to add scan responses to your advertising data.

Best regards,

Simon