Conditional advertising

RE: Conditional advertising

p143 — Wed, 16 Feb 2022 18:56:30 GMT

Thanks Karl.

I got it cristal clear now (There is no advertising payload on the primary channels when advertising with LE Code).

Best regards.

RE: Conditional advertising

Karl Ylvisaker — Wed, 09 Feb 2022 11:10:26 GMT

[quote user="p143"]I could use ADV_EXT_IND, which, as far as I understand, is a type of advertising PDU that can advertise in primary channels (that is maximum payload 29 Bytes) "and" implement LE Coded. Is that right?.[/quote]

I am not sure that I have understood your questions correctly here, but ADV_EXT_IND packets only contains the pointer to the secondary channel and time which the payload will be transferred on. There is no advertising payload on the primary channels when advertising with LE Coded.
The maximum advertising payload on primary channels are 32 bytes, but this also includes the 2 bytes of overhead added for each datafield - so in practice you will always be constrained to less than 32 bytes payload on primary advertising channels.

Best regards,
Karl

RE: Conditional advertising

p143 — Tue, 08 Feb 2022 15:17:34 GMT

Hi Karl.

What I mean is that, since my app is permanently advertising, and it must use LE Coded, and my advertising payload is small, I could use ADV_EXT_IND, which, as far as I understand, is a type of advertising PDU that can advertise in primary channels (that is maximum payload 29 Bytes) "and" implement LE Coded. Is that right?.
Thanks

Best regards,
Juan

RE: Conditional advertising

Karl Ylvisaker — Tue, 08 Feb 2022 12:40:30 GMT

Hello Juan,

[quote user="p143"]Thanks for your prompt answer.[/quote]

No problem at all, I am happy to help!

[quote user="p143"]And since you mention that the payload is one the choices to save battery, my adv messages are short, and I need Long Range to be implemented, I imagine that using ADV_EXT_IND to advertise only through primary channels would be a good idea. Wouldn´t it?[/quote]

Payload length does indeed play into current consumption, because it influences how long the radio must be in use for each advertising event.
Could you elaborate / be more specific about what you mean when you say that you need long range?
To achieve longer range without increasing the radio TX power you could use the Coded PHY.

Best regards,
Karl

RE: Conditional advertising

p143 — Mon, 07 Feb 2022 20:21:39 GMT

Hi Karl.
Thanks for your prompt answer.
And since you mention that the payload is one the choices to save battery, my adv messages are short, and I need Long Range to be implemented, I imagine that using ADV_EXT_IND to advertise only through primary channels would be a good idea. Wouldn´t it?
Thanks

Best regards
Juan

RE: Conditional advertising

Karl Ylvisaker — Mon, 07 Feb 2022 08:28:43 GMT

Hello Juan,

[quote user="p143"]what would improve implementing this Slow Mode versus playing with APP_ADV_INTERVAL?[/quote]

There would be no difference between these two as long as they have the same advertising interval and duration configured.
I mentioned the Advertising library approach because I thought you were using the Advertising library directly. If you are not, you may just set the advertising interval and duration directly, like demonstrated in the beacon example from the SDK.

Best regards,
Karl

RE: Conditional advertising

p143 — Fri, 04 Feb 2022 18:36:55 GMT

Hi Karl.

And what would improve implementing this Slow Mode versus playing with APP_ADV_INTERVAL?
Thanks.

Best regards.
Juan

RE: Conditional advertising

Karl Ylvisaker — Fri, 04 Feb 2022 07:32:30 GMT

Hello Juan,

[quote user="p143"]May I ask you which "mode" you would suggest to save even more battery?[/quote]

By modes I was here referring to the different advertising modes of the Advertising library - The 'slow' is the least energy consuming of these.
Other than that, the two most significant parameters to save power in your continuous advertising is advertising interval and payload. These dictate the time between each radio usage, and the length of the usage, respectively.

You should also make sure to power down as many peripherals as possible while your device is sleeping for a prolonged period, if you do not need them.

Best regards,
Karl

RE: Conditional advertising

p143 — Fri, 04 Feb 2022 02:21:21 GMT

Hi Karl.

In your last comment, you mention, "There are many configurations you could change to reduce the advertising's power consumption as well, such as advertising mode... ".
In my project, I am permanently advertising, and my APP_ADV_INTERVAL is 128. My init.advdata.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;
May I ask you which "mode" you would suggest to save even more battery?
Thanks.
Best regards,

Juan

RE: Conditional advertising

Karl Ylvisaker — Fri, 28 Jan 2022 09:45:43 GMT

Hello again, Juan

[quote user="p143"]1.- I understand that a module radio permanently advertising (therefore transmitting) consumes more battery than permanently scanning (therefore receiving). Am I right?[/quote]

Not quite, because scanning is a continuous process within the configured scan window - meaning that the radio will be active continuously for the duration of the scan window - while advertisings only have the radio active for a limited time once during the advertising interval. There are many configurations you could change to reduce the advertising's power consumption as well, such as advertising mode, interval and duration.
So, advertising is in the general case less power consuming than scanning.

[quote user="p143"]2.- I also understand that advertising packets, if you don't connect with the central module, are simply broadcasted, so no being addressed to any particular module. Okey?[/quote]

This is also configurable - if you use directed advertising then you are looking for a specific central device to connect. All advertisements are visible to all nearby BLE devices, however.

[quote user="p143"]3.- Would it be possible for the advertising module to set itself as a central scanning module A and the central module B as a permanently advertising module ONLY until module A detects the presence of B? Then, module A would set itself as a peripheral (for a preset period, though) and module B as a scanning module (for the same preset period).[/quote]

I think my answer to the first question might have negated the need for this question, since the assumption that scanning comes with a lesser power consumption was not valid.
In short; you could have done this like you proposed, but it would waste a lot of power for very little / no gain.

Please do not hesitate to ask if any part of my answer should be unclear, so that I may elaborate.

Best regards,
Karl

RE: Conditional advertising

p143 — Thu, 27 Jan 2022 18:00:11 GMT

Hi Karl.

Thanks for your prompt answer, but just to make sure, let me, please ask you a few more questions.

As I told you, my goal is to save even more battery in a permanently transmitting module, and I understand that online profiling would help with this, but before using this tool, I would like to have my ideas a bit more clear.

Right now, to increase battery life, I trade with the radiated power and the advertising frequency with reasonably good results. Still, before I order sample PCBs, I want to make sure I can't get any better regarding battery consumption. So my douts are:

1.- I understand that a module radio permanently advertising (therefore transmitting) consumes more battery than permanently scanning (therefore receiving). Am I right?
2.- I also understand that advertising packets, if you don't connect with the central module, are simply broadcasted, so no being addressed to any particular module. Okey?

So:

3.- Would it be possible for the advertising module to set itself as a central scanning module A and the central module B as a permanently advertising module ONLY until module A detects the presence of B? Then, module A would set itself as a peripheral (for a preset period, though) and module B as a scanning module (for the same preset period).

Would this make sense for you?

Best regards,

Juan

RE: Conditional advertising

Karl Ylvisaker — Mon, 24 Jan 2022 08:30:43 GMT

Hello,

[quote user=""]would it be possible for this module to remain in sleep status and start advertising (for a preset period, though) only when it detects a central module scanning for peripherals? Thanks.[/quote]

No, this is not possible since it would require that the peripheral constantly uses the RADIO peripheral to listen for central scan requests (which are directed at other devices, since itself is not advertising yet).
This would consume more energy than regular advertising.

Could it be an option to have the advertising started by an external event, such as a button press or sensor reading, instead? Alternatively, what is your application's requirements / constraints in regards to power consumption?
You could use the Online Power Profiler to estimate the power consumption of different advertising configurations, and to see how the different parameters affects your consumption.

Best regards,
Karl