Unable to pass 2 seconds for the PAwR sync ad

RE: Unable to pass 2 seconds for the PAwR sync ad

TheLittleFish — Wed, 25 Sep 2024 14:15:26 GMT

After some testing everything seems to be working ok.

Solutions:

1 - PAST does not permit disconnect without a response from the peripheral to the Host about how the synchronization went.

2 - Updating from sdk 2.5.2 to 2.7.0 fixed the connectivity problem that occurred when trying to synchronize to a Per. Adv. bigger than 2 sec.

RE: Unable to pass 2 seconds for the PAwR sync ad

dejans — Tue, 24 Sep 2024 09:29:36 GMT

Hi,

Thank you for the update.

Best regards,
Dejan

RE: Unable to pass 2 seconds for the PAwR sync ad

TheLittleFish — Mon, 23 Sep 2024 22:01:38 GMT

UPDATE:

After updating to sdk 2.7.0 the periodic_adv_conn and periodic_sync_conn samples no longer give a sync error. Initially there was also the message received was also garbage, but that was my fault, and now it works as expected. I'm presuming the softdevices controller had a bug in version 2.5.2 that was corrected in future updates.

Tomorrow will do more test and confirm if everything is really working as should.

RE: Unable to pass 2 seconds for the PAwR sync ad

TheLittleFish — Mon, 23 Sep 2024 20:14:46 GMT

So I went digging in the Bluetooth 5.4 core for more information and found this:

5.1.13 Periodic Advertising Sync Transfer procedure
A Controller may use the Periodic Advertising Sync Transfer procedure to transfer, to a connected peer device, the synchronization information necessary to synchronize to a periodic advertising train (see Section 4.4.3.4). Either the Central or the Peripheral Link Layer initiates this procedure by sending an LL_PERIODIC_SYNC_IND PDU or an LL_PERIODIC_SYNC_WR_IND PDU. The PDU used is determined by the type of the periodic advertising used. For PAwR, the LL_PERIODIC_SYNC_WR_IND PDU shall be used, otherwise the LL_PERIODIC_SYNC_IND PDU shall be used. If the LL_PERIODIC_SYNC_WR_IND PDU is used, then the RspAA shall be set to an Access Address value as specified in Section 2.1.2.
If the Host has enabled receipt of transfers and the Link Layer receives an LL_PERIODIC_SYNC_IND PDU or an LL_PERIODIC_SYNC_WR_IND PDU that describes a periodic advertising train that the Link Layer is neither already synchronized with nor in the process of synchronizing with, the Link Layer shall synchronize with the described periodic advertising train and then notify the Host; it shall also notify the Host if synchronization fails. However, if the PHY field of the LL_PERIODIC_SYNC_IND PDU or the LL_PERIODIC_SYNC_WR_IND PDU has no bits or more than one bit set, or the bit set corresponds to a PHY that the recipient does not support or is reserved for future use, the recipient shall ignore the PDU.
The procedure has completed when an LL_PERIODIC_SYNC_IND PDU or an LL_PERIODIC_SYNC_WR_IND PDU has been sent or received.

page 2886

Correct me if I'm wrong but, in the second paragraph where it says "and then notify the Host; it shall also notify the Host if synchronization fails", it means that the Host (the one giving the Per. Adv. information trough PAST) must be informed of the success of the synchronization.

Applying this to the example it means that the connection established with the Host must be maintained until the synchronization is resolved, has to inform it of the result.

If this is correct it explains why the example does not work without the delay, but it does explained the example that does not utilize PAST failing. I still have to test it with version 2.7.0 of the sdk, will update when done.

RE: Unable to pass 2 seconds for the PAwR sync ad

TheLittleFish — Mon, 23 Sep 2024 13:19:30 GMT

[quote userid="111786" url="~/f/nordic-q-a/114888/unable-to-pass-2-seconds-for-the-pawr-sync-ad/503403"]Is it that you tried to change interval_min and interval_max to the value 0x1F40 to get 10 s interval and this worked well when you added 10 seconds delay using k_msleep(10000) in periodic_adv_rsp sample (and used both periodic_adv_rsp and periodic_sync_rsp samples)?[/quote]

Yes i followed the low-power examples available in this link

Periodic Advertising with Responses (PAwR): A practical guide

[quote userid="111786" url="~/f/nordic-q-a/114888/unable-to-pass-2-seconds-for-the-pawr-sync-ad/503403"]There are 2 pairs of PAwR samples which should be used for testing. First pair consists of periodic_adv_rsp and periodic_sync_rsp samples and the second pair consists of periodic_adv_conn and periodic_sync_conn samples. What are you trying to achieve by combining periodic_sync_conn and periodic_adv_rsp?[/quote]

That is my fault it was suppose to be as you have written periodic_adv_rsp with periodic_sync_rsp and periodic_adv_conn with periodic_sync_conn. Altered in update.

RE: Unable to pass 2 seconds for the PAwR sync ad

dejans — Mon, 23 Sep 2024 13:04:25 GMT

Hi,

Is it that you tried to change interval_min and interval_max to the value 0x1F40 to get 10 s interval and this worked well when you added 10 seconds delay using k_msleep(10000) in periodic_adv_rsp sample (and used both periodic_adv_rsp and periodic_sync_rsp samples)?

There are 2 pairs of PAwR samples which should be used for testing. First pair consists of periodic_adv_rsp and periodic_sync_rsp samples and the second pair consists of periodic_adv_conn and periodic_sync_conn samples. What are you trying to achieve by combining periodic_sync_conn and periodic_adv_rsp?

Best regards,
Dejan

RE: Unable to pass 2 seconds for the PAwR sync ad

TheLittleFish — Fri, 20 Sep 2024 20:46:01 GMT

Update:

Found the problem with the periodic_adv_rsp and periodic_sync_rsp (PAST) versions.
In the same website give for the 10 s a version of these codes developed for low power is available for download. After analyzing the differences between it and the original, I discovered that if the 10 s delay, before the periodic_adv_rsp gives an order to disconnect, is removed the program fails.

		err = k_sem_take(&sem_written, K_SECONDS(10));
		if (err) {
			printk("Timed out during GATT write\n");
			num_synced--;

			goto disconnect;
		}

		printk("PAwR config written to sync %d, disconnecting\n", num_synced - 1);

disconnect:
		//added a delay so that the peer has enough time to sync before disconnection
		//k_msleep(10000); //  <---- This one
		if (default_conn)
		{
			err = bt_conn_disconnect(default_conn, BT_HCI_ERR_REMOTE_USER_TERM_CONN);
			if (err) {
					printk("Failed to disconnect, can be that the connection is already terminated, continue \n");		
			}
		}
		printk("Waiting for disconnected\n");
		k_sem_take(&sem_disconnected, K_FOREVER);
	}

When reducing the delay to 5 s, it give the following error:

Waiting for periodic sync...
Connected (err 0x00)
New timing: subevent 1, response slot 3
Not synced yet
Disconnected (reason 0x13)
Timed out while synchronizing
[00:01:10.012,603] <err> bt_adv: No valid legacy adv

Lowering the delay below 10 s makes the error appear, its chance of triggering seams to increase the lower the delay.

This means that for the periodic_sync_rsp needs for some reason to be in a connection with the periodic_adv_rsp to synchronize.

Any ideas why this is necessary?
I read a bit of the Bluetooth core but could not find this necessity.