STM32WB55 BLE Beacon Advertisement Update

[DenysK]

Hi all,

I’m working on an STM32WB55 and trying to run two advertisements “in parallel”:

• a connectable advertisement (for normal connections / data)

• a non-connectable advertisement using Additional Beacon

I can see both advertisements from an Android device, so the basic setup works.
The problem I’m struggling with is synchronising beacon payload updates with the actual beacon transmissions.

What I’d ideally like to do is update the beacon payload right before each non-connectable advertising event, so the transmitted packet always contains the latest data, without updating faster than the beacon interval.

I looked into using ACI_HAL_END_OF_RADIO_ACTIVITY_EVENT as a pacing mechanism (e.g., update the beacon payload right after an advertising event so the next one carries new data). However, with two advertising roles and other BLE activity (connection events, etc.), this event is generated frequently and not only for the additional beacon advertising. From what I can tell, it also doesn’t clearly identify which advertising activity just completed (connectable vs additional beacon), so triggering aci_gap_additional_beacon_set_data() directly from it doesn’t seem robust.

Has anyone implemented a clean/efficient way to:

• update additional beacon advertising data at a controlled rate, and/or

• align updates with the additional beacon advertising schedule (or reliably pace updates based on actual beacon transmissions) while still running normal connectable advertising/connection activity?

Any suggestions or best practices would be appreciated.

Thanks,

Denys

[gullasvilad]

This is a common limitation on the STM32WB. In practice, it’s safer to decouple beacon data updates from radio events and instead update the additional beacon payload on a timer aligned to the beacon interval. Using a low-power timer or scheduler to call aci_gap_additional_beacon_set_data() at the same rate as the beacon interval is usually more reliable than relying on ACI_HAL_END_OF_RADIO_ACTIVITY_EVENT, especially when multiple BLE activities are running.

Hope! it would be helpful.

[DenysK]

Hi @gullasvilad 

Thank you for the suggestion. 

In my opinion if you start a simple periodic software timer at init, you can still get occasional repeated beacon payloads. The reason is that the timer is free-running and not phase-locked to the controller’s actual advertising schedule.

Even if the timer period is set to e.g. 2500 ms, the controller’s advertising events run on their own internal timing (including small scheduling jitter/offset). Sometimes the timer callback will execute just after an advertising event has already been transmitted. In that case, the payload update misses that event and only takes effect for the following one, so the next advertising event can still go out with the previous payload, resulting in two consecutive advertisements carrying the same data, which I'm trying to avoid.

Happy to hear more suggestions.

Regards,

Denys

[DenysK]

Hi,

Small correction to my first message: I can use aci_hal_set_radio_activity_mask() to enable ACI_HAL_END_OF_RADIO_ACTIVITY_EVENT only for advertising radio activity (and disable reports for connection/scanning etc.), which reduces the amount of unrelated callbacks.

However, this doesn’t solve the underlying issue - this event is still just a “radio activity boundary” and doesn’t provide a deterministic per-advertising-event hook (or distinguish between different advertising sources if multiple are enabled). It mainly makes the events less noisy.

Regards,

Denys

[Billy OWEN]

Hi @DenysK 

This post has been escalated to the ST Online Support Team for additional assistance.  We'll contact you directly.

Regards,

Billy