S130 measuring radio on time accurately

[pabigot]

Using S130 to request notifications of radio activity as:

err = sd_radio_notification_cfg_set(NRF_RADIO_NOTIFICATION_TYPE_INT_ON_BOTH,
                                    NRF_RADIO_NOTIFICATION_DISTANCE_NONE);

 

fails with NRF_ERROR_INVALID_PARAM.

Is there a reason this combination is disallowed? The use case for it is tracking the amount of time spent in various operational modes, of which "radio on" is a significant attribute. I don't need any preparation time, I just need to know when the radio turns on and off. It "works" with NRF_RADIO_NOTIFICATION_DISTANCE_800US but presumably that overestimates the actual on time by 800 us on each activation.

Or is there another way to collect that information? (I should note I'm not using the nRF5 SDK, though if it has that ability I may be able to use the same technique.)

FWIW, I expect to have the same need in S132 and other nRF52 once I get to those devices.

[Håkon Alseth]

Hi,

 

The sd_radio_notification_cfg_set() disables the signal if you set the NRF_RADIO_NOTIFICATION_DISTANCE_NONE, as described in the API documentation:

/**@brief Configures the Radio Notification signal.
 *
 * @note
 *      - The notification signal latency depends on the interrupt priority settings of SWI used
 *        for notification signal.
 *      - To ensure that the radio notification signal behaves in a consistent way, the radio
 *        notifications must be configured when there is no protocol stack or other SoftDevice
 *        activity in progress. It is recommended that the radio notification signal is
 *        configured directly after the SoftDevice has been enabled.
 *      - In the period between the ACTIVE signal and the start of the Radio Event, the SoftDevice
 *        will interrupt the application to do Radio Event preparation.
 *      - Using the Radio Notification feature may limit the bandwidth, as the SoftDevice may have
 *        to shorten the connection events to have time for the Radio Notification signals.
 *
 * @param[in]  type      Type of notification signal, see @ref NRF_RADIO_NOTIFICATION_TYPES.
 *                       @ref NRF_RADIO_NOTIFICATION_TYPE_NONE shall be used to turn off radio
 *                       notification. Using @ref NRF_RADIO_NOTIFICATION_DISTANCE_NONE is
 *                       recommended (but not required) to be used with
 *                       @ref NRF_RADIO_NOTIFICATION_TYPE_NONE.
 *
 * @param[in]  distance  Distance between the notification signal and start of radio activity, see @ref NRF_RADIO_NOTIFICATION_DISTANCES.
 *                       This parameter is ignored when @ref NRF_RADIO_NOTIFICATION_TYPE_NONE or
 *                       @ref NRF_RADIO_NOTIFICATION_TYPE_INT_ON_INACTIVE is used.
 *
 * @retval ::NRF_ERROR_INVALID_PARAM The group number is invalid.
 * @retval ::NRF_ERROR_INVALID_STATE A protocol stack or other SoftDevice is running. Stop all
 *                                   running activities and retry.
 * @retval ::NRF_SUCCESS
 */
SVCALL(SD_RADIO_NOTIFICATION_CFG_SET, uint32_t, sd_radio_notification_cfg_set(uint8_t type, uint8_t distance));

However, if you want to see when the actual RADIO is active, this will not give you any detailed information, as it provides a event before and/or after a connection interval, which also include stack processing.

If you are interested in the detailed timing of the radio receive and transmit windows, it is not possible to get those numbers in firmware. At that point, you'll need to analyze the dynamic current consumption using external equipment.

If you want to know the length of your connection interval, your current solution with using radio_notification with a distance of 800 us, would be an alternative (measure time, then subtract 2*800us).

 

The nRF51-devices has the pin "VDD_PA", which is a pin that goes high 50 us before the radio goes into TX mode, and goes low immediately after a transmission ends. You can probe this, or even use a timer to get the length of it. But, on the nRF51-series, you do not have an option to check the RX length.

This pin is commonly used to control external RF PAs.

The nRF52-devices does not have the "VDD_PA" pin, so the PA/LNA functionality is then built in to the SoftDevice, using the sd_ble_opt_set/get API. When this is set, you can get PA and LNA signals outputted on GPIOs.

What do you want to obtain? If you want to profile your current consumption, then I'd recommend looking at the power calculator for nRF52-devices:

https://devzone.nordicsemi.com/power/

For nRF51-series power profiling, we do not have a automated calculator, but there are scenarios listed in the S130 datasheet:

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s130.sds/dita/softdevices/s130/ble_power_profiles/ble_power_profiles.html?cp=3_7_2_0_17

Best regards,

Håkon

[pabigot]

I don't read the documentation that way. There's a recommendation (but not requirement) to use DISTANCE_NONE when using TYPE_NONE, but no clear statement that DISTANCE_NONE plus TYPE_INT_ON_ACTIVE is invalid.

My question was really why sd_radio_notification_cfg_set() disallows the combination. If you want to turn off notifications, that's covered by TYPE_NONE. DISTANCE_NONE is allowed for INT_ON_INACTIVE; disallowing it for INT_ON_ACTIVE lacks motivation.

That what the notification brackets is a connection interval is helpful; thanks.

As to what I'm doing: I've set up a framework to measure time spent in various modes, e.g. in below A=active, S=sleep; R is radio on:

  A--: 00:15:44.660   30954628
  S--: 41:34:05.245  608608115
  A-R: 00:00:04.361     142912
  S-R: 00:03:55.732    7724490

I will be using external instrumentation to estimate the power consumed by various operations; from that and time-in-mode I'm hoping to get a more accurate estimate of remaining battery life that is available from estimating remaining Ah from measured battery voltage. If I extend that with a count of radio-on events, then I can do a correction of n*800, but I won't be able to attribute the duration to the correct operational mode.

Thanks for the pointers on PA/LNA for nRF52; I haven't gotten to that series yet, but will probably try that technique when I do.