More than one advertising packet

[mrezan]

Hi Expertise,

I'm using S140 and SD version 7.

I have two packets of advertising data:
Packet A, 31 bytes.
Packet B, 20 bytes.

Packet A is required to be advertised every 500ms while packet B only when needed.
How can I advertise packet B without affecting packet A interval?
My idea is to send packet B just after packet A is sent as below:

Do we have an efficient method to switch it accordingly?

Thanks & Best Regards,
Rezan

 

[Jørgen Holmefjord]

Hi,

Do you need the two packets to be separate advertising packets, or could you put the data from packet B in the scan response packet? This is as far as I know the only way to not affect the interval of the Packet A advertising in nRF5 SDK.

Only one advertising set is supported with S140 v7, so you will have to update the advertising data, and also stop/restart the advertising if you want to use a different advertising interval.

For more details, you can reference these guides:

• How to update advertising data dynamically using BLE Advertising library
• Concurrent Advertising

In nRF Connect SDK there exists ready-made sample in the SDK that shows this, which you can test out:

• Bluetooth: Multiple advertising sets

Best regards,
Jørgen

[Jørgen Holmefjord]

mrezan said:

Is there any callback/event when advertising is finished?

There is no direct callback when advertising is finished, but it could be possible to use the Radio Notification API to determine when the radio activity is done. Note that the radio notifications does not provide any context of the radio activity, and will trigger on radio activity from connections or scanning in addition to the advertising events. Also, there is a limitation with this feature that flash operations are also reported through radio notifications).

mrezan said:

If have, and we turn ON it, will it increase the current consumption?

This will depend on how long time the CPU needs to process the event. There should be no other current consumption increase than the additional CPU time.

Best regards,
Jørgne

[mrezan]

Noted that. Thanks Jørgne.

Worth to study it.

Best regards,
Rezan