Relation between broadcast.c timings & the online power profiler timings for non-connectable BLE advertising

[Mathias]

Hi,

We're trying to characterize the radio timings of the transmission of a Bluetooth Mesh packet from an originator in a Bluetooth Mesh network. Looking at the broadcast.c file in the nRF5 Mesh SDK, we see that the radio time that's being calculated is based on the rampup time of the radio, on-air transmission time and disabling time for each channel (37, 38 and 39) + the initial setup and last disabling time of the radio for transmission:

uint32_t radio_time_per_channel = RADIO_RAMPUP_TIME +
                                      (packet_length_in_bytes * radio_mode_to_us_per_byte[radio_mode]) +
                                      RADIO_DISABLE_TO_DISABLED_DELAY_US;

return (BROADCAST_SOFTWARE_OVERHEAD_US + USR_SOFTWARE_OVERHEAD_US + radio_time_per_channel * channel_count);

However, if we look at the timings shown in the Online Power Profiler for non-connectable advertising, it seems that these are a bit larger than the ones shown in the broadcast.c file (https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/nrf52-online-power-profiler). For example:

• RADIO_RAMPUP_TIME is 40µs while the Online Power Profiler says ~130 µs for Start Radio.
• RADIO_DISABLE_TO_DISABLED_DELAY_US is 6µs while the Online Power Profiler says 157 µs for every Standby between channels and even 350 µs for Post Processing after channel 39.
• BROADCAST_SOFTWARE_OVERHEAD_US is 72 µs and USR_SOFTWARE_OVERHEAD_US is 80 µs (so 152 µs in total), while the additional timings within the Online Power Profiler indicate 60 µs for Pre-Processing, 400 µs for Crystal Ramp Up and an additional 1072 µs for Standby.

So my question is, why do these timings differ so much? And why is there so much Standby timing necessary?

Thanks in advance.

Kind regards,

Mathias

[Simonr]

Hi Mathias

1. If you check out the Radio timing section in the nRF52832 PS, you can see that there is a default and a fast ramp-up mode in order to start the radio. So the Mesh SDK apparently uses the fast ramp-up, and the power profiler uses the default ramp-up mode.

2. Same goes here, the 6us is how long it takes to disable the radio, but it has to be enabled as well. So tTXDIABLE + tTXEN will be 140us+6us, as well as a few us between the disabled event and the TXEN task will result in ~150us.

3. The BROADCAST_SOFTWARE_OVERHEAD is just setting up the radio, etc. There is much more than that going on during startup, and the USR_SOFTWARE_OVERHEAD_US is the maximum overhead when a TX call is completed.

Overall, the Online Power Profiler is just a measured estimate of how long it will take to power up the chip and complete one radio event. You should always measure your own application's current consumption, and the BLE Mesh stack has not been used when making the Online Power Profiler measurements, so these values may differ somewhat. The broadcast.c file only defines values used for the broadcast itself, and not anything used to start the chip and/or the external crystals as far as I know.

Best regards,

Simon