How to run nrf_drv_saadc_sample in a loop

[Nikosant03]

Hi everyone,

I want to run nrf_drv_saadc_sample in a loop but I do not want to use PPI and TIMER peripherals because they increases the power consumption of my device. I could use the continuous sampling but it uses the HFCLK (16 MHz) and I want to avoid it.

Is it safe to call the nrf_drv_saadc_sample in a for loop providing a delay > tconv + tACQ

tconv < 2us (see tconv in Electrical specifications)

tACQ = 3-40us (depended by the source impedance) (see acquisition time)

Is there any more efficient/low power method? I design an ultra low power device

[Jørgen Holmefjord]

Hi,

Is it safe to call the nrf_drv_saadc_sample in a for loop providing a delay > tconv + tACQ

Yes, that should be safe, but it will no be lower power than using PPI+TIMER. Using a delay will keep the CPU running, which consumes ~3-6mA @3V, depending on the regulator and clock configs. The CPU also keeps the HFCLK running, to generate the 64MHz CPU clock.

Is there any more efficient/low power method? I design an ultra low power device

The best method to achieve very low current consumption with the SAADC peripheral, is to use RTC to trigger samples over PPI, and use the lp_mode in the driver (or uninit the driver between samples). The low power mode in the driver will only start the SAADC when a sample is requested, while in normal mode the SAADC will be running from whenever you setup the buffer until the buffer have been filled. You can find an example showing low power in this GitHub repository.

If you plan to utilize the maximum sample frequency of the SAADC, this method may not be feasible, meaning low power may not be achievable. When started, the SAADC peripheral will consume over 1mA.

Best regards,
Jørgen

[Jørgen Holmefjord]

Hi,

It is expected that the two approaches have approximately the same current consumption. The app_timer library runs on the RTC, and PPI consumes almost no current (it is simple signals between peripherals in HW). The additional current consumption is the first approach is likely from the CPU waking up to handle the app_timer events in SW.

Best regards,
Jørgen

[Nikosant03]

Thank you, Jorgen!!