PaWR subevent data

[Katy_123]

Hi,

I am testing the PaWR examples in the NCS and I have few doubts.

1. In this page Periodic Advertising with Responses (PAwR): A practical guide , it says in section 1.3 that there are two ways for synchronization - PAST after connection OR  following the periodic advertising. Is there an example in NCS which shows the PaWR using the synchronization with the periodic advertising (without connection)? I used examples "periodic_adv_rsp" and "periodic_sync_rsp" in pairs and I can see a connection and PAST happening.

Regarding "pawr_data_request" callback, it says the callback will be called when there is buffer available?  What does this mean ? For example, How can I increment the data for subevent0 in each event? Ie, the scanner should receive 0,1,2,3,4 ... for subevent 0.

[Jakob Ruhe]

Hello Katy,

I am happy to hear that you are trying out PAwR!

1. The sample application periodic_sync_conn synchronizes to the PAwR train, advertised by the periodic_adv_conn, without using PAST. 

That said, I have only used PAST myself. I think it has some advantages because then the advertiser can share details such as which subevent and which response slot a new peripheral should have before it joins the PAwR train.

2. The pawr_data_request callback will be called periodically by the controller some time before it needs transmit data for one (or several) subevents. If you have a look in the periodic_sync_conn example and the function request_cb, it only requires i tiny modification to accomplish what you want.

This is what the loop inside the function request_cb() looks like now:

	for (size_t i = 0; i < to_send; i++) {
		buf = &bufs[i];
		buf->data[buf->len - 1] = counter++;

		subevent_data_params[i].subevent =
			(request->start + i) % per_adv_params.num_subevents;
		subevent_data_params[i].response_slot_start = 0;
		subevent_data_params[i].response_slot_count = NUM_RSP_SLOTS;
		subevent_data_params[i].data = buf;
	}

In order to only increase the counter at subevent 0 (i.e. for every new period), something like this should work:

	for (size_t i = 0; i < to_send; i++) {
		const uint8_t subevent = (request->start + i) % per_adv_params.num_subevents;
		if (subevent == 0) {
			counter++;
		}

		buf = &bufs[i];
		buf->data[buf->len - 1] = counter;

		subevent_data_params[i].subevent = subevent;
		subevent_data_params[i].response_slot_start = 0;
		subevent_data_params[i].response_slot_count = NUM_RSP_SLOTS;
		subevent_data_params[i].data = buf;
	}

 Good luck with your project!

[Katy_123]

 Jakob Ruhe Thank you for your reply.

So if the PaWR adv interval is 10 seconds, will I get this call back at least every 10 seconds ? and from the code it looks like there will be scenarios where buffer will not be available for all the subevents - What data will be sent for the subevents in this case ?

Also, I know that in normal advertising the receiver sometimes misses the ADV packets. In PAWR, will there be any cases where the subevents/responses will be missed ? Does PaWR guarantee a 100% data reception ?

[Einar Thorsrud]

Hi

Yes, you will get the pawr_data_request callback needs data for new subevent(s), so that the application can provide data.

Regarding the seocnd question, PaWR is a low-level feature that does not include retransmissions, so there is no guarantee that all data will be received. But it should be possible to build a protocol on top that does is (this is briefely described in the guilde that you linked to in your original post).

[Jakob Ruhe]

I am not sure that the calls to the callback will necessary correspond to the configured Periodic Advertising Interval. 

It depends also on which Subevent Interval you have chosen and the Number of Subevents. In addition to this it is worth noting that you can configure the controller the maximum number of Subevents it should request at the time by setting the following parameter:

BT_CTLR_SDC_PERIODIC_ADV_RSP_TX_BUFFER_COUNT

If you set it to 1 you should get a callback for each Subevent.

As long as NUM_SUBEVENTS is equal or higher than BT_CTLR_SDC_PERIODIC_ADV_RSP_TX_BUFFER_COUNT (3 per default) the number of buffers should be enough. Note that this parameter is specific to the Nordic SoftDevice Controller so the Zephyr example is not using it.

If you do not supply the Controller with data in time it will probably just transmit an AUX_SYNC_SUBEVENT_IND without a payload. It is probably better to explicitly supply the Controller with an empty payload.

This is radio communication. Packets are dropped now and then. There are no guarantees. In fact, in PAwR, there are no retry mechanism in place at all. This is the responsibility of the application. The good side of this is that you have full control and you can adapt your application to your specific use case.