Periodic Advertising Issue

RE: Periodic Advertising Issue

Gary T — Thu, 16 Jun 2022 12:03:00 GMT

Thanks Susheel.

I appreciate your time and effort to try and solve this issue.

I hope you are able to raise this with the relevant people so that they can perhaps provide a solution in the future.

RE: Periodic Advertising Issue

Susheel Nuguru — Thu, 16 Jun 2022 10:22:10 GMT

I think adding the delay between AUX_ADV_IND and AUX_SYNC_IND might work the first event but then the LL controler takes over the timing and then it is back to the same timing you saw without the k_sleep.

Yes, It seems that there needs to be some design changes needed to facilitate your use case. Unfortunately we are not stuck the max interval of 2.5s to sync faster with the scanner

RE: Periodic Advertising Issue

Susheel Nuguru — Thu, 16 Jun 2022 10:05:54 GMT

[quote user="Gary T"]As a suggestion, since the AUX_SYNC_IND depends on information provided in AUX_ADV_IND, doesn't it make sense to transmit AUX_SYNC_IND after AUX_ADV_IND? This would solve all the issues. I could then set both events with the same frequency and AUX_SYNC_IND would always be within 2.5s of AUX_ADV_IND. I could then set both to 10s and use a lot less power (11.3µA for my peripheral which means my battery would last 50% longer!)[/quote]

Your point is valid and after reading the spec, I do not see why we cannot do that. This most likely is a design decision made for making scanning more predictable. But this thread definitely has given enough points to re-evaluate these offsets.

RE: Periodic Advertising Issue

Gary T — Thu, 16 Jun 2022 10:00:03 GMT

I just wanted to clarify that I am starting AUX_ADV_IND before AUX_SYNC_IND in my code even though they are being broadcast in the opposite order. I guess it just takes a bit longer to initialise the AUX_ADV_IND packet.

As an attempted fix, I have inserted a k_sleep(K_SECONDS(1)); after I start the AUX_ADV_IND but before I start the AUX_SYNC_IND.

It initially works and the receiver syncs quickly. There is an initial gap between AUX_ADV_IND and AUX_SYNC_IND of around 800ms. Unfortunately, even though they are both set to the exact same interval, over time the gap reduces until the point where AUX_SYNC_IND starts to occur before AUX_ADV_IND (or put another way, the gap from AUX_ADV_IND until the next AUX_SYNC_IND goes from ~0.1s to ~9,9s) and the receiver loses synchronisation.

I am guessing this happens because I think there is a random delay inserted into the advertising interval to prevent collisions from other devices set with the same interval.

So now I am stuck. I would like my beacon to only transmit every 10s (which saves me a lot of power) but I can't find a way to do this reliably without reducing the AUX_SYNC_IND to 2.5s or less.

[quote userid="6207" url="~/f/nordic-q-a/88553/periodic-advertising-issue/372558#372558"]Normally when the distance between the AUX_ADV_IND(with sync_info) and the AUX_SYNC_IND is greater than 2.5s, then the value of that distance offset cannot be represented in the interval field of the sync_info. [/quote]

I think the only way to properly make this work is to fix the issue you mentioned above. Is this a limitation of the BT standard or a limitation in the Nordic software?

Do you think there is a way to properly represent the interval field of greater than 2.5s in the sync_info?

Is this problem fixable or must I just live with the compromise?

RE: Periodic Advertising Issue

Gary T — Wed, 15 Jun 2022 14:17:18 GMT

Thanks for this description.

It did confuse me because if you are saying that the AUX_ADV_IND event and the next AUX_SYNC_IND event must be within 2.5s of each other then, if I set both of them with an interval of 10s, aren't they within 2.5s of each other? This is where I started my testing and this doesn't work.

I dug a little deeper into the readings from the PPK attached to the peripheral and it appears that the AUX_SYNC_IND transmits a tiny bit before the AUX_ADV_IND event (I can tell because the AUX_SYNC_IND uses a lot less power and also, if I set the AUX_SYNC_IND frequency lower than AUX_ADV_IND I can also check the timing between events). If this is true, can I assume the offset is ~9.9s rather than ~0.1s and hence won't work because of your explanation above?

By this logic, as far as I can tell, the only way to keep this working reliably is to transmit the AUX_SYNC_IND every 2.5s or less and transmit the AUX_ADV_IND at a frequency a multiple of the AUX_SYNC_IND interval. This uses a lot of power (17.6µA for my peripheral using AUX_ADV_IND interval of 10s and AUX_SYNC_IND interval of 2s).

As a suggestion, since the AUX_SYNC_IND depends on information provided in AUX_ADV_IND, doesn't it make sense to transmit AUX_SYNC_IND after AUX_ADV_IND? This would solve all the issues. I could then set both events with the same frequency and AUX_SYNC_IND would always be within 2.5s of AUX_ADV_IND. I could then set both to 10s and use a lot less power (11.3µA for my peripheral which means my battery would last 50% longer!)

I hope this makes sense.

RE: Periodic Advertising Issue

Susheel Nuguru — Wed, 15 Jun 2022 12:05:08 GMT

The interval should have been set to non zero value, which is a small bug and will be fixed soon.

Normally when the distance between the AUX_ADV_IND(with sync_info) and the AUX_SYNC_IND is greater than 2.5s, then the value of that distance offset cannot be represented in the interval field of the sync_info. That made us mistakenly clear the sync_info field in case the distance cannot be represented.

But even after fixing this not to clear the interval field, the behavior would be same. If the AUX_ADV_IND and the next periodic AUX_SYNC_IND packets happen to be at the distance greater than 2.5s, then you will see a longer syncing time before the sync_info field can represent the interval.

Do not chose the ADV_IND and AUX_SYNC_IND intervals where in worst case there distances are farther than 2.5S for multiple times in a row.

RE: Periodic Advertising Issue

Susheel Nuguru — Wed, 15 Jun 2022 11:42:56 GMT

I see the same, this should have been fixed, I will check with the dev team and come back to you.

RE: Periodic Advertising Issue

Gary T — Tue, 14 Jun 2022 11:06:55 GMT

I have upgraded to nRF Connect SDK 2.0.0 (it took me some time to understand the new Pin Control settings).

Unfortunately, it doesn't seem to have affected this issue. It is behaving the same as before.

RE: Periodic Advertising Issue

Susheel Nuguru — Tue, 14 Jun 2022 06:31:43 GMT

This seems to be a bug that seems to have been fixed in Nordic Connect SDKv2.0.0

"Fixed an issue where the advertiser would incorrectly set Offset Adjust in 
the SyncInfo when the offset to the AUX_SYNC_IND is large (DRGN-16887)."

Can you please give it a try

RE: Periodic Advertising Issue

Gary T — Tue, 14 Jun 2022 06:17:35 GMT

Many thanks!

RE: Periodic Advertising Issue

Susheel Nuguru — Tue, 14 Jun 2022 05:11:17 GMT

There clearly is some logic behind the optimal settings here and I cannot figure out what that is by looking at the documentation. I will have to reach to the BLE team to gain more knowledge. I will be back to you with more info soon.

RE: Periodic Advertising Issue

Gary T — Mon, 13 Jun 2022 13:16:04 GMT

Thanks Susheel

In order to test this I have kept the ADV_EXT_IND interval at 10s and have varied the AUX_SYNC_IND interval across 9s, 8s and 7s. It takes anywhere from 2 to 5 minutes for the receiver to synchronise. The peripheral/sender is still sending lots of events with no "interval" included even though the ADV_EXT_IND and AUX_SYNC_IND events are quite far apart.

I have tested this using my phone (with the nRF Connect App) as well as an nRF52833DK.

I am still confused about why it works if I increase the interval frequency. If I set both intervals to 1s then the receiver synchronises almost immediately. The "interval" is included in the very first transmission.

Do you know the logic used to include the "interval" into the initial advertising message?

RE: Periodic Advertising Issue

Susheel Nuguru — Mon, 13 Jun 2022 11:46:09 GMT

OK, I tested this and it seems that since the ADV_EXT_IND interval in le_advertising_param and AUX_SYNC_IND interval in periodic_param might be causing some collisions in the timeslots most likely causing the adv ind to not transimit the interval sometimes. Try to select the intervals of ADV_EXT_IND and AUX_SYNC_IND not to be multiples of each. I understand that there should be some radion delay between adv events, but there seems to be a connection in how you select the adv_params and periodic_sync_interval parameter

RE: Periodic Advertising Issue

Gary T — Fri, 10 Jun 2022 14:35:39 GMT

Thanks Susheel.

Looking forward to your feedback.

RE: Periodic Advertising Issue

Susheel Nuguru — Fri, 10 Jun 2022 06:49:36 GMT

I could not test this this week. I will have to take a look at it Monday, I appreciate your patience and sorry for the delays.

RE: Periodic Advertising Issue

Gary T — Tue, 07 Jun 2022 09:40:37 GMT

devzone.nordicsemi.com/.../nrf_5F00_test_2D00_periodic_5F00_demo.zip

Hi Susheel

I have attached the projects.

The "Adv" is for the peripheral and the "Sync" is for the scanner.

I have set up the intervals on the Peripheral as 10s for the LE Advertisement and 5s for the Periodic Data.

Thanks for your help!

RE: Periodic Advertising Issue

Susheel Nuguru — Tue, 07 Jun 2022 08:14:29 GMT

This is very interesting.
I have not tested the periodic advertising my self, but the output does look very interesting.
I do not think that the advertising interval should have this effect. Is it possible for you to attach the adv and scanner project here so that I can do some testing here and give you more conclusive answer?

RE: Periodic Advertising Issue

Susheel Nuguru — Fri, 03 Jun 2022 11:34:27 GMT

Hi,
I did not manage to look at this today, will look into the details you provided next week. Thanks for your patience.