Scanning, Multiple advertisement, varying payloads.

[DavideDN]

We need to build a device that acts as a peripheral (with some custom characteristic to transfer data toward a smartphone and having OTA/DFU functionalities), as a beacon with changing payload (not connectable and not scannable), and passive scanner, all three concurrently.

The beacon advertising interval will be in the range of 100mS-300mS with a payload that changes every a few seconds (jitter is OK, but absolute time consistency is required).

Application scenario: SDK 16.0.0 (the most recent....), nRF52832.

We started with the BLE peripheral Blinky example and we successfully added the passive scanner code. Now it is time to add the concurrent beacon function.

I am trying to browse all the forum and available examples... but I still have difficulties understanding the correct/wiser approach.

Is it possible to have more than one advertiser instance running concurrently ?

It seem "yes" but quite unclear if it is necessary to deal with the softdevice directly or even start messing with timeslot api, or we can stay within BLE Library Advertising Module.

Unfortunately in the forums there are partial overlapping answers but most of them referring to older SDKs.

Can you summarize what is the "today SDK" recommended approach to achieve our goal?

Is there an up to date example close to our needs?

I have read that in SDK 16, changing the advertiser payload has been improved/simplified, I am missing some documentation/example about this, can you share an hint?

thank you in advance and

 best regards

  Davide

[Edvin]

Hello Davide,

So you want to advertise as a beacon even when you are not connected to the phone, right?

The softdevice can only deal with one advertising set at the time. That being said, you are free to change between two advertising sets at any time (e.g. every 100-300ms). So when you are advertising with the beacon and the connectable advertisements, you need to "manually" switch between the two. When you are connected, you can use only the beacon advertisements.

You should be aware of one thing. Since the nRF only has one radio, it can only do one thing at once, receive or transmit. This means that you can only scan or advertise at once. You can do it seemingly simultaneously, but the softdevice will have to prioritize either the advertisement or the scan window if they are colliding. I am only saying this so you can consider your scan window and scan interval at an early stage, before you are seeing a lot of packet drops. The softdevice will only schedule entire scan windows, so if you set the scan window to 1 second, you can not use the radio for anything else this second, which means you will not be able to advertise. Equally, if the softdevice decides to skip this scan window, you will not see any advertising intervals until the next scan interval.

The softdevice has a dynamic scheduler, so it will increase the priority for advertising or scanning if that was skipped the last time.

So for your question:

I believe that some advertising update API came a couple of Softdevice releases ago. But you need to use this in your application. Check out ble_advertising_advdata_update() and try to use this in combination with a timer to change between connectable and beacon advertisements.

Best regards,

Edvin

[DavideDN]

Thak you Edvin.

Yes, our need is to merge a "normal" peripheral and a pure beacon (with the beacon having a dynamic payload) and a pure scanner.

Regarding the fact that we have a single radio: this was already crystal clear, of course we cannot do two things at a time. Anyway thank you for the explanation of the scan window slot policy and constrains. Indeed I was naively thinking that scan was kind of a background activity that maybe was always active whenever no other TX(adv or connection) or RX(connection) activity was underway. Now I have more hints to select the scan interval and window.

We need to scan 100% of the (available/remaining) time, even during connection, so after your explanation I am thinking about the scheduling of:

• connection events,
• advertising events
• and scanning events

You explained that there are dynamic policies to assign the right priorities. But since the "standard operation" for a BLE device would be to act as only one of these at a time, maybe in our use case the priorities needs to be tuned to better suit our use scenario?

Can these priorities be tuned? Does it make sense to do it, or it would be better to relay on the default one you mentioned?

Thank you in advance.

Davide

[Edvin]

DavideDN said:

Can these priorities be tuned? Does it make sense to do it, or it would be better to relay on the default one you mentioned?

 Unfortunately, no. They can not be tuned. The softdevice takes full control of these priorities. You can read about the priorities here.

There is also another page with some suggested intervals and windows.

BR,

Edvin