Advertisement packet loss at device startup

RE: Advertisement packet loss at device startup

Simonr — Wed, 07 Oct 2020 05:36:18 GMT

Ah, yes. The advertising flag will have to be set to BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE in order to use 0 as the advertising duration.

Best regards,

Simon

RE: Advertisement packet loss at device startup

hmolesworth — Tue, 06 Oct 2020 15:38:51 GMT

Changing from SDK v15.2 to later versions caused advertising to stop when set to 0, there were several posts regarding this. Looking back I now see that another change was required to allow a value of 0 be used:

"If you don't want your advertisements to time out, and your device to go to sleep, you can set the advertising duration (APP_ADV_DURATION) to 0. Note that you also need to change the advertising flag from BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE to BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE."

RE: Advertisement packet loss at device startup

Simonr — Tue, 06 Oct 2020 06:40:43 GMT

setting the advertising duration (APP_ADV_DURATION) to 0 will disable the advertising timeout, and will let the device keep advertising "indefinitely". I'm not entirely sure what hmolesworth is referring to I'm afraid.

Best regards,

Simon

RE: Advertisement packet loss at device startup

Aftab — Mon, 05 Oct 2020 07:20:32 GMT

@Sinmonr,

Does the following code continuously advertise or not in the softdevice v7.0.1 (SDK v16.0)?

#define APP_ADV_DURATION   0   //always advertise

My testing shows that it does, and whenever I scan devices through nRFConnect, it shows updated adv data. But still I want to confirm as @hmolesworth suggested otherwise.

Also my issue is not that it stops advertising, my issue is packet loss at the start of advertising. It may just be mobile app scanner issue, but I still want to confirm.

RE: Advertisement packet loss at device startup

hmolesworth — Fri, 02 Oct 2020 19:13:53 GMT

This is just a guess but I think this feature changed and doesn't now continuous advertise in recent softdevices:

#define APP_ADV_DURATION   0   //always advertise

I can't check as too busy, but on advertising timeout - set to a large number like 18000 - simply restart the advertising if I recall correctly. Quick look in my code shows this, may be what you want:

/**@brief Function for handling the Timeout event.
 *
 * @param[in] p_advertising Advertising module instance.
 * @param[in] p_ble_evt Event received from the BLE stack.
 */
static void on_terminated(ble_advertising_t * const p_advertising, ble_evt_t const * p_ble_evt)
{
    ret_code_t ret;

    if (p_ble_evt->header.evt_id != BLE_GAP_EVT_ADV_SET_TERMINATED)
    {
        // Nothing to do.
        return;
    }

    if (  p_ble_evt->evt.gap_evt.params.adv_set_terminated.reason == BLE_GAP_EVT_ADV_SET_TERMINATED_REASON_TIMEOUT
        ||p_ble_evt->evt.gap_evt.params.adv_set_terminated.reason == BLE_GAP_EVT_ADV_SET_TERMINATED_REASON_LIMIT_REACHED)
    {
        // Start advertising in the next mode.
        ret = ble_advertising_start(p_advertising, adv_mode_next_get(p_advertising->adv_mode_current));

        if ((ret != NRF_SUCCESS) && (p_advertising->error_handler != NULL))
        {
            p_advertising->error_handler(ret);
        }
    }
}

RE: Advertisement packet loss at device startup

Aftab — Fri, 02 Oct 2020 12:48:03 GMT

We further tested this issue and found that if iPhone rescans the advertisement data, it starts getting good packets again. So, for now, restarting iPhone scanner after every 10s resolves the issue. I means that hardware sends correct packets but iPhone somehow cannot capture those packets unless it's BLE scanner is reset. Does this make any sense? Why it's happening?

RE: Advertisement packet loss at device startup

Simonr — Fri, 02 Oct 2020 11:41:26 GMT

First off, do you see this on multiple of your custom boards or just the one? It could be that you have a faulty/poorly optimized crystal that takes some time to get up to speed after a power cycle. Can you upload the schematics of your board and/or the datasheet of the external crystal(s) you are using so we can take a look at that.

Next, advertising won't be the most reliable way to capture data, as there is no way to ensure that an advertisement reaches its destination, so if you're looking for reliability I would suggest connecting the devices instead to ensure that all the necessary data is received in the central device.

Best regards,

Simon