Change adv interval in PAwR BLE in runtime

Hello,

I am using PAwR (Periodic Advertsing with Response) in coded PHY (S8) with SDK 2.7.0, following the Nordic demo :

8562.PAwR_Demo.zip 

Periodic Advertising with Responses (PAwR): A practical guide - Software - nRF Connect SDK guides - Nordic DevZone

I want to change, in run time, the advertising interval ".interval_min" and ".interval_max" initialised with the structure "static const struct bt_le_per_adv_param per_adv_params"

More precisely I want to change it frequently between fast and slow advertising. 

Is it possible to do so in the case of PAwR ? Is there any example for illustration ? Should I go through the whole process of sync (initialisation connexion disconnexion) to be able to change it whenever I want ?  Or should I just use the following snippet which stops advertising resets the new parameters and starts advertising :

	struct bt_le_ext_adv *pawr_adv;

	struct bt_le_adv_param *params = BT_LE_EXT_ADV_NCONN;
	params->options |= BT_LE_ADV_OPT_USE_IDENTITY | BT_LE_ADV_OPT_USE_NAME | BT_LE_ADV_OPT_CODED;
	params->sid = 0;
	

	/* Create a non-connectable non-scannable advertising set */
	err = bt_le_ext_adv_create(params, &adv_cb, &pawr_adv); //BT_LE_EXT_ADV_NCONN //BT_LE_EXT_ADV_CODED_NCONN
	if (err) {
		LOG_ERR("Failed to create advertising set (err %d)\n", err);
		return 0;
	}
	
    // Stop periodic advertising
    err = bt_le_per_adv_stop(pawr_adv);
    if (err) {
        LOG_INF("Failed to stop periodic advertising (err %d)\n", err);
        return;
    }
    
	// Set new adv parameters
    struct bt_le_per_adv_param per_adv_param = {
        .interval_min = min_int,
        .interval_max = max_int,
		.options = 0,
		.num_subevents = NUM_SUBEVENTS,
		.subevent_interval = 120,
		.response_slot_delay = 5, 
		.response_slot_spacing = 40,
		.num_response_slots = NUM_RSP_SLOTS,
    };

	/* Set periodic advertising parameters */
	err = bt_le_per_adv_set_param(pawr_adv, &per_adv_params);
	if (err) {
		LOG_ERR("Failed to set periodic advertising parameters (err %d)\n", err);
		return 0;
	}

	/* Enable Periodic Advertising */
	err = bt_le_per_adv_start(pawr_adv);
	if (err) {
		LOG_ERR("Failed to enable periodic advertising (err %d)\n", err);
		return 0;
	}

	LOG_DBG("Start Periodic Advertising\n");
	err = bt_le_ext_adv_start(pawr_adv, BT_LE_EXT_ADV_START_DEFAULT);
	if (err) {
		LOG_ERR("Failed to start extended advertising (err %d)\n", err);
		return 0;
	}

Kind regards,
Yanis
  • Hi, 

    It needs to stop the current advertising, update the parameters, and then restart advertising with the new parameters. 

    Regards,
    Amanda H.

  • Now I do not know anything about your use case. But, depending on what you want to accomplish, you can also consider another approach.

    Instead of changing the Advertising Interval of the PAwR train on the broadcaster, subscribers can choose a different subset of Subevents to subscribe to. So if you want to save power on a subscriber node, it can listen to only subevent 0 by default, and to all Subevents during selected periods.

  • Thank you for your reply Jakob,

    Do you mean to switch between one "standby" subevent with no expected response and all subevents to send response ?

    But if no response it will timeout the sync ?

    Besides, It is the broadcaster that writes the subevents and slots to sych to,

    Changing the subevent to listen to means to go through another sync subscription cycle, isn't it ?

    The subevent to listen to is set when the sync_cb call back is triggered (bt_le_per_adv_sync_subevent).

  • In this case, do you think that this reset should be done before the timeout (past_param.timeout) ?

    Otherwise the sync would be lost if the adv is stopped for too long (> past_param.timeout).

  • A subscriber does not have to respond to Subevents to stay in sync. On the broadcaster side it is up to the application to decide if a subscriber should be treated as in sync or not.

    However, a subscriber that does not receive the AUX_SYNC_SUBEVENT_IND from the broadcaster for a while, will eventually get out of sync from the PAwR train.

    Which subevent(s) and which response slot a Subscriber is allowed to use is completely up to the application. 

    A subscriber may call `bt_le_per_adv_sync_subevent()` at any time to change the subset of Subevents to listen to.

    You have a lot of freedom when it comes to how PAwR should be used in a system. It is powerful enough to cover almost any use case. 

    If you explain on a higher level what you would like to accomplish it might be possible to guide you even more. But hopefully this is a good start for you. To learn more about PAwR there are good videos available and Nordic Developer Academy is also very good. 

    Good luck with your project!

Related