This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Advertising forever

I want my client to advertise forever so I added the following code:

static void ble_evt_dispatch(ble_evt_t * p_ble_evt)
{
    ble_conn_params_on_ble_evt(p_ble_evt);
    ble_nus_on_ble_evt(&m_nus, p_ble_evt);
	  // Advertise forever
	  if (p_ble_evt->header.evt_id == BLE_GAP_EVT_TIMEOUT) {
          APP_ERROR_CHECK(ble_advertising_start(BLE_ADV_MODE_FAST));
      }
      else {
			on_ble_evt(p_ble_evt);
      }
    ble_advertising_on_ble_evt(p_ble_evt);
    // bsp_btn_ble_on_ble_evt(p_ble_evt);
    
}

When the initial fast-mode advertising finishes, this code calls ble_advertising_start but then hangs. Is there another method to do this?

  • This would normally be done in ble_advertising_on_ble_evt. Are you sure you don't have multiple calls to ble_advertising_start?

  • Are you saying that there is a setting of advertising parameters that will cause the logic in ble_advertising_on_ble_evt to advertise forever? I took a look at the code in that function. There's a case BLE_GAP_EVT_TIMEOUT where I believe the advertising should restart. But it looks like that logic does FAST, then SLOW, then IDLE and there's no way to set parameters to keep advertising either fast or slow without changing the function. I'm not very excited about the prospect of changing code that's outside my application and part of the API. How would I merge my changes to ble_advertising.c if Nordic releases a new version of that file?

  • Hi Bret,

    The advertising goes through a state machine and several states of FAST, SLOW and other advertisements. One easy way to avoid the BLE_ADV_EVT_IDLE from taking the system to sleep.

    In the function on_adv_evt, the usual handler for the BLE_ADV_EVT_IDLE case is to run sleep_mode_enter() which is what stops advertising. Instead call:

    ble_advertising_start(BLE_ADV_MODE_FAST);

    To restart the FAST advertising (or change to SLOW or whichever you want).

    We have devices that constantly advertise and they can go through several phases of advertisement depending on power requirements.

  • In an effort to resolve this issue, I reasoned that perhaps the issue lay in my advertising data. As a result, I reorganized the code and temporarily removed the beacon advertising initialization in favor of focusing solely on getting the connectable advertising to function with sd ble gap adv start.                                   quordle

Related