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

[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