Periodic Advertising Issue

[Gary T]

Hi Nordic Community

I have been building a thermometer device from which I would like to send temperature values via periodic advertising. 

I have based the sender and receiver off the Zephyr "periodic adv" and "periodic sync" examples provided in the SDK which I have modified for my purposes. The main change I have made is to move over to "LE Coded" transmission by adding BT_LE_ADV_OPT_CODED to the advertising parameters. I have also increased the TX power to 8dBm.

I am using an nRF52840DK as the sender and nRF52833DK as the receiver. 

I have managed to get everything working and the peripheral is successfully sending data and the receiver is successfully synchronising to the peripheral and then receiving temperature data.

I initially set the BT_LE_ADV (BT Advertising) interval to 1s and the BT_LE_PER_ADV (Periodic data transmission) to 1s and everything works fine.

In an effort to reduce power usage I wanted to reduce the interval to 10s for both the BT Advertising as well as Periodic Data transmission however when I do this I have problems and the receiver won't synchronise.

From what I understand in the receiver sample code, the device looks for BT Advertising data and then inspects the data for an "Interval" which indicates that there is periodic data being sent. It then uses information in the BT Advertising event to retrieve the info required to synchronise with the periodic data being sent.

In my testing I set the Periodic Interval to 10s:

If I set the BT Advertisement Interval to 1s then the receiver synchronises without issue.

If I set the BT Advertisement Interval to 3s then the BT Advertisement sometimes doesn't contain the "Interval" data required for the receiver to get it's periodic sync info but it eventually does come through.

If I set the BT Advertisement Interval to 5s then the frequency of not including "Interval" data increases.

If I set the BT Advertisement Interval to 10s then it never seems to contain the "Interval" data.

Is there any advice on how to get this working reliably when setting both the BT Advertising as well as the Periodic Data transmission to 10s intervals?

Is there another way to set up the synchronisation without relying on the "Interval" being available?

Here are some screenshots showing the terminal on the receiver when the Periodic Interval was set to 10s and the Advertising Interval was varied between 3s, 5s, and 10s.

3 second advertising interval:

5 second advertising interval:

10 second advertising interval:

I would appreciate any guidance. Thanks for your help.

Gary

[Gary T]

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. 

[Susheel Nuguru]

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

[Susheel Nuguru]

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. 

[Gary T]

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.

[Gary T]

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.

Susheel Nuguru said:

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.

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?