Minimising power usage


#1

I am investigating ways reduce the power consumption as much as possible. The device will have a accelerometer that it needs to measure about every minute and if its over a threshold, it needs to connect to the cloud and send a message.

At the moment a program that just turns off the RGB led and calls System.sleep(SLEEP_MODE_CPU); as often as possible still uses about 250uA average, with peaks to 17mA every 30mS. I have already found that this interval will be configurable later.

Another ‘big’ draw is the 20uA from the flash. Is there a way to add a P-channel fet and have the software power it up when the flash is needed?

When i stop advertising and disconnect BLE, and then sleep, it feels like the device resets after a few seconds. should i use another sleepmode when BLE is disconnected?

anything else i can do?

i am looking to get down to under 25uA average.


#2

You can have a look at some great measurements that @AndyW collected. The current draw between BLE events and system wakeups should be down to about 80uA with nothing turned on.

Correct, we will soon allow you to configure the connection interval and the output power, so if you are using a short range device you will be able to turn down the power used when BLE is transmitting. This will significantly help.

As for reducing power, make sure any peripherals are turned off. You mentioned an accelerometer, is this using I2C or SPI? You can shut those off between measurements by calling the .end() commands and then starting them only when you need them.

For the SPI flash, we didn’t include a FET on board to turn it off, and unfortunately there isn’t really a way to add one.


#3

To add to that, I’ve taken to using one of the other pins as the power source for a temp sensor, so even quiescent power to the sensor is shut off when we don’t need the sensor. Also, out of curiosity, what kind of accelerometer application will you be able to just poll occasionally? I feel like most applications where you’d want to set an alarm threshold, it’s only going to go over briefly (e.g. a drop or bump).


#4

For low power peripherals, that is an often overlooked and simple way of powering them - just hang them off a GPIO pin. Simple and effective.

@eric, I’m not really sure what role the spi flash plays in the solution - but would this be a possible option, or is the spi flash required before any software is able to take control and enable the power to it ?


#5

The SPI flash is used to store the device ID, keys for the cloud, factory reset firmware and as the download space for the OTA updates. It is only used at certain times, however we didn’t build in a way to turn it off.

I am also not sure it is making much of an impact. I took a board yesterday and had a sketch turn off BLE and the RGB LED. I was measuring (inaccurately with a multimeter) about 40uA. I then physically removed the SPI flash and didn’t notice much difference (again though, inaccurately).


#6

The device will be a kind of level sensor that you can drop in a barrel of water. it will have a pointy bottom and will float. when its not floating anymore (thus at an angle), will report this.

@eric , how did you turn off BLE? if i call BLE.stopAdvertising(); it doesnt seem to make any difference and Publish() still works too. Infact, when i call BLE.startAdvertising(); i get a reproducible weird looking SOS code. https://vimeo.com/165588445

I am currently using 1.0.47 , should i try 1.1.47 ?


#7

For current consumption of low duty-cycle devices such as a DK in low power mode, meters are not very useful - you really need to monitor at a high temporal resolution, then integrate and measure the area under the curve for the total charge consumed.

Digital meters will also lie to you more than analog meters (same as 'scopes, in that respect.)


#8

Yeah, I was just trying to make some quick spot checks. The numbers aren’t too accurate, but I was trying to compare two things relative to eachother, I have found meters to be somewhat decent at that task.

I was going to try and test a few more things and accidentally shorted the battery and blew the fuse in the meter. Ooops. Getting more today so I will continue to play around with this a bit.


#9

Understood, not trying to lecture you :slight_smile:


#10

since the DK runs from 4V just as well as from 5V, and even with the RGB led on it will not use more then lets say 10mA for any length of time, you can put a 100 Ohm resistor in series with a BIG cap (1,000 or 10,000 uF) to get a lot more decent averages with regular multimeters.


#11

Has anybody worked at all at reducing power consumption more? I asked because I read this and want to know if something similar is being done as well. I remember seeing very low uA from the RFduino I used to use so I am surprised at 80uA. Then again, what is a typical battery decay rate just sitting on the shelf? Maybe this isn’t worth pursuing further.

The sensor beacon saves power by putting the CPU to sleep between every step in the firmware sequence above. It also saves power by switching off the crystal oscillator and the power to the sensor chip and the TWI.


#12

Some good and related discussions look like they are going on here:
Wake on interrupt ACTIVE
Questions about System.sleep() STALE


#13

And another (new users can only put two links in a post)
How to wakeup every <n> seconds from sleep(SLEEP_MODE_CPU)? AWAITING ACTION


#14

Minimizing power consumption is always on the list of To Do’s. We have some good features coming with 1.2 that will help, including deep sleep mode and Timers, which you pointed out.

There are other things as well, like lowering the transmit power and increasing the connection intervals. I will say that the options to decrease power consumption will only get better as we release new versions of firmware!