Multiactivity Example vs. Github Multirole Advertiser

[Marius Heil]

Hi,

I want to implement Advertising with the Timeslot API. I only need non-connectable advertisements but I want to be able to control the transmit power.

• Which example should I start with?
• Is any of these outdated?
• Are they both compatible with NRF52 as well?
• Support for multiple advertising messages isn't getting implemented in the SoftDevice soon, is that right?

I am using the S130 v2 Softdevice and I want as little code overhead as possible as I am duplicating code that is already in the Softdevice by implementing this.

Thanks

[Øyvind Karlsen]

Hi,

The multiactivity example is the one that is the most up to date.

Neither is compatible for nRF52 out of the box, I do not know why the multiactivity example is not shipped for nRF52 by default, as far as I can see there's nothing in there that won't be easily transferrable to nRF52.

I can't comment on future SoftDevice releases. You will have to consult your regional sales manager for these questions (send me a PM if you need contact info).

The code overhead shouldn't be so bad, in the multiactivity example everything in total is about 3-400 lines of code.

I recommend having a look at the timeslot tutorial, the blog on concurrent BLE and ESB is also useful to get a feel for timeslots.

[Marius Heil]

Thanks a lot, I liked the multiactivity example more as it is easier :-) Can you tell me anything about conformance testing? Has this been done with the multiactivity example as well? Do I have to follow some rules while changing the code?

[Øyvind Karlsen]

Hi,

I've thought a little bit more about this and will instead recommend a different approach. Bear with me, this is going to be a little bit hacky.

You can use the SoftDevice to send non-connectable advertisements while in a connection, this skips right over the conformance problem as well. It is possible to call the function: sd_ble_gap_adv_start() when you are in a connection. It is however only possible to do scannable and non-connectable advertisements when you are in a connection.

Well that's fine, but we still need to be able to control the output power, here's where the workaround comes in. Set up a radio notification before each radio event, the hacky part is the logic you will have to make to discern wether you are about to send an advertisement package or a connectable package, if you can make the advertisement and connectable packets alternate that would make things a whole lot easier for you.

In the radio notification after you have determined that it is an advertisement you can call sd_ble_gap_tx_power_set() with your desired TX power. Remember to set the TX power back afterwards.

[Marius Heil]

Thanks, but what exaclty could be the hacky part? I have connections coming and going and even advertisements starting and stopping. How would I be able to know in the beginning of an advertisement session that the softdevice will indeed be advertising? Any fixed address in the RAM of the Softdevice that I could query?^^

I also want to be able to implement multiple advertising messages, knowing the beginning of each advertising event and the end would be very, very helpful. (Will one radio session always only be of one kind? e.g. advertising / connection?)

[Øyvind Karlsen]

Well that's the hacky part, you only know that there's a radio event, there's no info on the type. For now you will have to find some logic that figures this out for you.

Alternately the timeslot solution is also perfectly valid. I am not sure that either will outcompete eachother on current consumption.