advertisment directed/discoverable

[Stephane D'Alu]

Two questions about advertisement (i'm reading ble_advertising.c code)

• I failed to see what is making transition from BLE_ADV_MODE_DIRECTED to BLE_ADV_MODE_DIRECTED_SLOW as adv_params.timeout is set to 0 (for BLE_ADV_MODE_DIRECTED) and transition seems to be done on BLE_GAP_EVT_TIMEOUT .

• For the flags in advertisement packet (BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE/ BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE), usually set when calling ble_advertising_init, it seems to be overwritten to BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED by the call to ble_advertisement_start when using whitelist. But in ble_advertising_restart_without_whitelist it is not set back to its initial value. Is it normal?

[FormerMember]

Directed advertising

For directed advertising with high duty cycle the timeout is 1.28 s.

For directed advertising with high duty cycle, the min/max advertising interval settings are being ignored:

"For high duty cycle directed advertising, i.e. when Advertising_Type is 0x01 (ADV_DIRECT_IND, high duty cycle), the Advertising_Interval_Min and Advertising_Interval_Max parameters are not used and shall be ignored." (Bluetooth Core Specification, Vol 2, Part E, chapter 7.8.5)

Bluetooth Core Specification, Vol 6, Part B, chapter 4.4.2.4 says the following about high and low duty cycle directed advertising:

Connectable low duty cycle directed advertising is designed for cases where reconnection with a specific device is required, but time is not of the essence or it is not known if the central device is in range or not. High duty cycle directed advertising is designed for cases in which fast Link Layer connection setup is essential (for example, a reconnection). Note that high duty cycle directed advertising is a power and bandwidth intensive advertising scheme that should only be used when fast connection setup is required.

Advertising flags

Advertising with whitelist: According to the Bluetooth Core Specification, only the flag BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED should be set when advertising with whitelist.

The flags BLE_GAP_ADV_FLAG_LE_LIMITED_DISC_MODE and BLE_GAP_ADV_FLAG_LE_GENERAL_DISC_MODE should only be used when the advertising device will accept connection request from any device::

The Host shall set the advertising filter policy to ‘process scan and connection requests from all devices’. (Bluetooth Core Specification Vol 3, Part C, chapter 9.4.2 and 9.4.3 )

I think it is a bug in the advertising module that the advertising flag is not set back to the "normal" one (BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE or BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE) when disabling whitelist. From what I can see in the code, the flag should be "re-set" in ble_advertising_start(..) (not tested):

uint32_t ble_advertising_start(ble_adv_mode_t advertising_mode)
{
...
...
// Set advertising parameters and events according to selected advertising mode.
    switch (m_adv_mode_current)
    {
...
 case BLE_ADV_MODE_FAST:
            adv_params.timeout  = m_adv_modes_config.ble_adv_fast_timeout;
            adv_params.interval = m_adv_modes_config.ble_adv_fast_interval;

            if (   whitelist_has_entries(&m_whitelist)
                && m_adv_modes_config.ble_adv_whitelist_enabled
                && !m_whitelist_temporarily_disabled)
            {
                adv_params.fp          = BLE_GAP_ADV_FP_FILTER_CONNREQ;
                adv_params.p_whitelist = &m_whitelist;
                m_advdata.flags        = BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED;
                err_code               = ble_advdata_set(&m_advdata, NULL);
                if(err_code != NRF_SUCCESS)
                {
                    return err_code;
                }

                m_adv_evt = BLE_ADV_EVT_FAST_WHITELIST;
                LOG("[ADV]: Starting fast advertisement with whitelist.\r\n");
            }
            else
            {
                m_adv_evt = BLE_ADV_EVT_FAST;
                 // Add advertising flag here.
                LOG("[ADV]: Starting fast advertisement.\r\n");
            }
            break;

        case BLE_ADV_MODE_SLOW:
            adv_params.interval = m_adv_modes_config.ble_adv_slow_interval;
            adv_params.timeout  = m_adv_modes_config.ble_adv_slow_timeout;

            if (   whitelist_has_entries(&m_whitelist)
                && m_adv_modes_config.ble_adv_whitelist_enabled
                && !m_whitelist_temporarily_disabled)
            {
                adv_params.fp          = BLE_GAP_ADV_FP_FILTER_CONNREQ;
                adv_params.p_whitelist = &m_whitelist;
                m_advdata.flags        = BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED;
                err_code               = ble_advdata_set(&m_advdata, NULL);
                if(err_code != NRF_SUCCESS)
                {
                    return err_code;
                }

                m_adv_evt = BLE_ADV_EVT_SLOW_WHITELIST;
                LOG("[ADV]: Starting slow advertisement with whitelist.\r\n");
            }
            else
            {
                m_adv_evt = BLE_ADV_EVT_SLOW;
                // Add advertising flag here.
                LOG("[ADV]: Starting slow advertisement.\r\n");
            }
            break;
...
...
}

[Håvard]

Thanks Stephane D'Alu and Kristin. A fix was added for the upcoming SDK release.