power optimisation / scaling with data rate for nrf52

[Lakerno]

I have designed a custom PCB with Nrf52 for an ECG wearable sensor application and is trying to optimise the power consumption of the device. The application is to collect the ECG data (at fixed sampling interval of 32/128/256 Hz) from a TI ADS1292 AFE (AMP+ADC) and transmit it via BLE and receive it in the Master control panel app in the PC/Mobile App. The TI chip is interfaced with Nrf52 using SPI interface. I want to measure/optimise the power at different data rates.

If power/Current consumed by Nrf52 is P Amps at 256 Hz transmission At 128 Hz sampling/Transmission rate, Can I expect the current consumed by NRF52 to be around ~P/2 Amps? At 32 Hz sampling?transmission rate, Can I expect the current consumed by NRF52 to be around ~P/8 Amps??

what are the parameters to be optimised for achieving this kind of power scaling/reduction? Some things I expect to modify are

1. Connection Interval (reduce to half or 1/8th for case 2 and case 3)
2. Anything else? Any reports/graphs/plots on power reduction w.r.t. data rate?

Does consumed current scale linearly w.r.t data rate? Looking at this tutorial, power consumed at 100ms and 1000ms connection interval are not exactly 1/10th? Any Comments on this? devzone.nordicsemi.com/.../

[Stefan Birnir Sverrisson]

Hi Lakerno

The general rule for the serial peripherals of the nRF52 is that they consume the same when active, independent of the data rate. So if you want to save current, choose the highest data rate that both nRF52 and the peer device can handle. That way the serial communication will take the shortest amount of time and you spend most of the time in idle state where current consumption is much lower.

For the BLE communication, this is a different story. General rule is that if you increase connection interval or advertising interval, you will have lower current consumption, but you will also get lower data rate and longer packet delay. I suspect that if your device is in a connection and you are sending no data, then the current consumtion would approximately be twice as low if you increase the connection interval 2x. However, if you are sending data over the link, then you will see less effect of increasing the connection interval 2x, as the same amount of payload packets still need to be sent over the BLE link.

I think there are some useful tips in the nRF51 current consuption guide, "Tuning connection parameters" section, to serve the needs of your scenario but still consuming minimal current

[Lakerno]

"However, if you are sending data over the link, then you will see less effect of increasing the connection interval 2x, as the same amount of payload packets still need to be sent over the BLE link." Can you clarify why is this? If the connection interval is 2X and If I am sending half the number of packets as before(since the data rate is halved as in the original question), then the power is expected to halved as well? Is that correct?

[Stefan Birnir Sverrisson]

Note that on each connection event, 1-6 packets can be sent in each direction. Lets say that you have notifications enabled on the peripheral device and you are sending packets to the central by calling sd_ble_gatts_hvx every 100ms, and you have set your connection interval to 100ms. Then the peripheral is sending 1 packet in each connection event. If you now set the connection interval to 200ms but still call sd_ble_gatts_hvx every 100ms, then 2 packets per connection interval are sent, making the peripheral device consume more current in each connection event.

[Lakerno]

ok. Assuming the data rate is halved as mentioned in the question, I will need to call sd_ble_gatts_hvx only once in every 200ms along with 200ms connection interval. In this case, can I expect the current consumption to be halved as well?

[Stefan Birnir Sverrisson]

Yes, i would expect so if you also decrease the amount of payload data you send by 50%, and have no other activity on the chip.

Bottom line in order to save current: Don't have connection interval shorter then necessary for your scenario, and fill up packets (20 bytes maximum) as much as possible