<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>PaWR subevent data</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/119655/pawr-subevent-data</link><description>Hi, I am testing the PaWR examples in the NCS and I have few doubts. 
 
 In this page , 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</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 26 Mar 2025 14:27:39 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/119655/pawr-subevent-data" /><item><title>RE: PaWR subevent data</title><link>https://devzone.nordicsemi.com/thread/529098?ContentTypeID=1</link><pubDate>Wed, 26 Mar 2025 14:27:39 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:00f6d7b1-d605-475f-9e3e-e6480df4c918</guid><dc:creator>Jakob Ruhe</dc:creator><description>&lt;p&gt;I am not sure that the calls to&amp;nbsp;the callback will necessary correspond to the configured Periodic Advertising Interval.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;&lt;span&gt;BT_CTLR_SDC_PERIODIC_ADV_RSP_TX_BUFFER_COUNT&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;If you set it to 1 you should get a callback for each Subevent.&lt;/p&gt;
&lt;p&gt;As long as&amp;nbsp;NUM_SUBEVENTS is equal or higher than&amp;nbsp;&lt;span&gt;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.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: PaWR subevent data</title><link>https://devzone.nordicsemi.com/thread/528814?ContentTypeID=1</link><pubDate>Tue, 25 Mar 2025 11:19:06 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:19421150-94c1-484c-a7f7-b8d73cec1c4e</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi&lt;/p&gt;
&lt;p&gt;Yes, you will get the&amp;nbsp;pawr_data_request callback needs data for new subevent(s), so that the application can provide data.&lt;/p&gt;
&lt;p&gt;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).&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: PaWR subevent data</title><link>https://devzone.nordicsemi.com/thread/528088?ContentTypeID=1</link><pubDate>Wed, 19 Mar 2025 21:28:33 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:2add2113-7bab-4299-9790-73154a9ca6e2</guid><dc:creator>Katy_123</dc:creator><description>&lt;p&gt;&amp;nbsp;&lt;a href="https://devzone.nordicsemi.com/members/jakob-ruhe"&gt;Jakob Ruhe&lt;/a&gt;&amp;nbsp;Thank you for your reply.&lt;/p&gt;
&lt;p&gt;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 ?&lt;br /&gt;&lt;br /&gt;Also, I know that in normal advertising the&amp;nbsp;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 ?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: PaWR subevent data</title><link>https://devzone.nordicsemi.com/thread/526495?ContentTypeID=1</link><pubDate>Mon, 10 Mar 2025 09:01:58 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:853c3121-87b0-4e21-ac01-48fc47dde6f9</guid><dc:creator>Jakob Ruhe</dc:creator><description>&lt;p&gt;Hello Katy,&lt;/p&gt;
&lt;p&gt;I am happy to hear that you are trying out PAwR!&lt;/p&gt;
&lt;p&gt;1. The sample application &lt;em&gt;periodic_sync_conn&lt;/em&gt; synchronizes to the PAwR train, advertised by the&amp;nbsp;&lt;em&gt;periodic_adv_conn&lt;/em&gt;,&lt;em&gt;&amp;nbsp;&lt;/em&gt;without using PAST.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;2. The &lt;em&gt;pawr_data_request&lt;/em&gt; 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 &lt;em&gt;periodic_sync_conn&lt;/em&gt; example and the function&amp;nbsp;&lt;em&gt;request_cb&lt;/em&gt;, it only requires i tiny modification to accomplish what you want.&lt;/p&gt;
&lt;p&gt;This is&amp;nbsp;what&amp;nbsp;the loop inside the function &lt;em&gt;request_cb()&lt;/em&gt; looks like now:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;	for (size_t i = 0; i &amp;lt; to_send; i++) {
		buf = &amp;amp;bufs[i];
		buf-&amp;gt;data[buf-&amp;gt;len - 1] = counter++;

		subevent_data_params[i].subevent =
			(request-&amp;gt;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;
	}
&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;In order to only increase the counter at subevent 0 (i.e. for every new period), something like this should work:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;	for (size_t i = 0; i &amp;lt; to_send; i++) {
		const uint8_t subevent = (request-&amp;gt;start + i) % per_adv_params.num_subevents;
		if (subevent == 0) {
			counter++;
		}

		buf = &amp;amp;bufs[i];
		buf-&amp;gt;data[buf-&amp;gt;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;
	}&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;&amp;nbsp;Good luck with your project!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>