Power Optimization with PPI

[Xander To]

Hi, I'm using S132 for BLE and I want to optimize current consumption as much as I can. Right now, I'm having BLE advertising while SAADC sampling battery voltage every 10 seconds. It consumes around 1.0mA and it matches the prediction from the Online Power Profiler Tool. My code for SAADC is based on this Low power SAADC example
I know that using PPI I can link timer to 1 end of the PPI channel and SAADC to the other end of the PPI channel, thus removing the need of CPU processing. However, how much consumption is saved when I used PPI compared to the above Low Power SAADC example? Or the above example is already the lowest possible consumption I can achieve for SAADC?

Thank you very much for your clarification.

Best regards,

Xander

[Vidar Berg]

Hello Xander,

I don't know what other tasks your app may be performing, but 1 mA is quite a high current consumption if you're only doing battery sampling and advertising. Please have a look at my answer here: Low Power Mode using SAADC with ble_app_beacon  .

The issue with using a TIMER as the trigger source is that it can increase your idle current by up to ~600 uA since it requires the HF clock to remain active during sleep.

Best regards,

Vidar 

[Xander To]

Hi Vidar,

Firstly, I have a few questions to ensure I understand the BLE correctly.

1. What is advertising TX/RX ? I thought advertising is when the device only sending data to the outside world and not reading any data until a connection is established

2. Why if I set advertising interval to 300ms, the interval shown in the summary chart is 305ms ? It always 5ms more than my selected advertising interval

3. If my macro APP_ADV_INTERVAL is 300, does it mean it set the advertising interval to 300ms. Or is it 300 multiply by a time factor?

I realized my previous report from Online Power Profiler Tool was incorrect as I forgot to set the correct advertising interval. I should get around 100uA consumption when advertising BLE + SAADC. As I mentioned earlier, my board consumes 1mA. Sorry for my wrong terminology but when I used the world "timer", I mean RTC as the Low power SAADC example code uses RTC for trigger source. Other than BLE and SAADC, my board doesn't perform any other task during advertising, the programs just sits in an idle state during advertising. There is also no TIMER instance is used in the code at all. I have replaced all TIMER by APP_TIMER or RTC2. Therefore, I'm really confused why my current consumption is so high.

Please let me know what I did wrong. Thank you very much for your help and explanation.

Best regards,

Xander

[Vidar Berg]

Xander To said:

1. What is advertising TX/RX ? I thought advertising is when the device only sending data to the outside world and not reading any data until a connection is established

RX must be enabled if you want to be able to receive connection or scan requests from surrounding scanners. Without RX, you can only to non-connectable advertising.

Xander To said:

If my macro APP_ADV_INTERVAL is 300, does it mean it set the advertising interval to 300ms. Or is it 300 multiply by a time factor

The interval is given in units of 0.625 ms, so 300 corresponds to an interval of 187.5 ms.

Xander To said:

I should get around 100uA consumption when advertising BLE + SAADC.

This depends on how you have configured the SAADC. The OPP estimates the system current based on BLE activity and does not cover SAADC usage. I suggest you measure the current in your application with only BLE enabled to verify if you can match the OPP numbers. You can also try the demo project I uploaded in the linked Q&A.

Best regards,

Vidar

[Xander To]

Hi Vidar,

Assuming I implement low power SAADC and BLE correctly, so my last question is if using PPI, can I reduce the consumption even more? Or Low power SAADC + BLE is the most optimal combo?

Thank you for your reply.

Best regards,

Xander

[Vidar Berg]

Hi Xander, 

I don't think the additional CPU processing required to service the app timer/RTC interrupt every 10 seconds is going to have a noticeable impact on the total power consumption of your device.

The problem with using PPI is to get the idle current down between sampling, as the SAADC starts requesting the HF clock when you provide the DMA buffer. This is why I'm providing the buffer just before sampling in the demo sample I referred to earlier.

static void battery_level_meas_timeout_handler(void * p_context)
{
    UNUSED_PARAMETER(p_context);
    
    ret_code_t err_code = nrf_drv_saadc_buffer_convert(&m_adc_buf, 1);
    APP_ERROR_CHECK(err_code);
    
    err_code = nrf_drv_saadc_sample();
    APP_ERROR_CHECK(err_code);
}

Best regards,

Vidar