search

lancaster-university / microbit-dal

http://lancaster-university.github.io/microbit-docs
Other
259 stars 131 forks source link

power off micro:bit? #97

Open mmoskal opened 8 years ago

mmoskal commented 8 years ago

Hi,

I was thinking of a scenario, where micro:bit runs off battery and does some activity tracking every now and then. The battery may or may not have on-off switch and the user might forget to turn it off anyway. So it would be best if I could turn it off programatically.

I measured the power consumption as the following:

Screen off - 1.8mA Screen off, CPU crunching full speed - 4.9mA (CPU datasheet specified 4.4mA so I guess there are other things running than the CPU) 1 LED at full brightness adds 0.7mA 1 LED at low brightness adds 0.1mA-0.2mA

Screen off, CPU in POWEROFF state - 0.8mA (NRF_POWER->SYSTEMOFF = 1;, see https://github.com/NordicSemiconductor/nrf51-powerdown-examples/blob/master/system-off-wakeup-on-gpio/main.c )

So even in poweroff mode, with 750mAh AAA battery it will only run for just over a month. With a 90mAh coin-cell battery it would be less than 5 days.

I guess there is other stuff on the board that we could power off? It would be nice of DAL to provide a poweroff() function, that would just require RESET button to be woken up from. If we can do it on A or B, that would be also nice, but I guess not necessary.

mmoskal commented 8 years ago

CC @jamesadevine @finneyj

finneyj commented 8 years ago

Hi @mmoskal

Thanks for raising this and for sharing your results. I'd been meaning to measure this also.

I agree completely about this. There is a complication though. There was a ticket about this on bbc-extras, and I drafted up a partial working solution accordingly that allowed the micro:bit to enter a hibernate mode when the reset button was held down. The device would then be woken up on a subsequent click of the reset button.

The BBC's child protection team felt that there would be a safety issue here though, in that it would encourage kids to leave a micro:bit in a bag/pocket whilst still having a power source attached with the 3V power line exposed through the large pad on the edge connector and risking the pads being shorted. As such, they decided that we weren't permitted to use this feature. I parked development at this point as there was lots of other work to be doing...

As for ways forward here, i guess two possibilities:

thoughts?

mmoskal commented 8 years ago

Hmm, maybe we can have calls to disable compass and accelerometer? I think these would be generally useful.

finneyj commented 8 years ago

yes, that would be simple. Also perhaps some auto activation, so they are disabled by default until someone calls read() or registers for an associated event...

pelikhan commented 8 years ago

Agreed. Tight control on turning on/off all services + smart default about turning them on on demand would be great.

Also, being able to completely shut off the micro:bit for a given amount of time (hibernate timer of some sort) would probably help as well.

Sent from Outlook Mobilehttps://aka.ms/qtex0l

On Wed, Feb 17, 2016 at 8:52 AM -0800, "Joe Finney" notifications@github.com<mailto:notifications@github.com> wrote:

yes, that would be simple. Also perhaps some auto activation, so they are disabled by default until someone calls read() or registers for an associated event...

Reply to this email directly or view it on GitHubhttps://github.com/lancaster-university/microbit-dal/issues/97#issuecomment-185294437.

jamesadevine commented 8 years ago

@pelikhan @mmoskal This is now in... the accelerometer, compass and temperature sensor, do not perform update operations until they are used for the very first time, or a listener is placed for a component.

mmoskal commented 8 years ago

Awesome! This will help in the general case. Can these be turned off after they have been used?

jamesadevine commented 8 years ago

In a very manual way - for sure.

Should definitely be more accessible, however. We should definitely a disable() call to all components, applied in MicroBitComponent.h.

jamesadevine commented 8 years ago

However, it's starting to feel like there are a set of MicroBitSensorComponents...

markshannon commented 7 years ago

@mmoskal Did you perform your measurements with a USB cable attached? According to the datasheets, the magnetometer should draw 275µA and the accelerometer a mere 27µA which is a long way short of the ~800µA you measured.

mmoskal commented 7 years ago

I think this was on battery, but I don't remember really...

finneyj commented 7 years ago

@markshannon @mmoskal

I did some more detailed profiling on power usage a little while ago for a talk I was giving. There were a few surprising results in there. This was all measured from a 3V lab supply connected to the external 3V pins and a data logging multimeter:

image

The serial cost might be particularly relevant for micropython @markshannon

We move most drivers to be lazily initialized as a result of seeing these numbers.

markshannon commented 7 years ago

@jfinney, a few questions. What was your method? It isn't clear to me what, for example, "Reset button" is measuring.

What does the "Serial" row mean? Is that the power consumption of the UART component on the Nordic chip or the power consumption of the Kenetis chip?

finneyj commented 7 years ago

@markshannon

These results we all gathered by measuring direct current draw of a micro:bit powered from a laboratory power supply at 3V, with a fluke data logging ammeter placed in series with the power supply. micro:bit was powered through the external 3V/GND pads on the edge connector and was disconnected from USB. (Essentially the same as a battery power configuration),

I ran a series of tests that added/removed the component drivers for all the micro:bit peripherals, and measured the changes in power consumption. A different HEX file was generated for each test, using microbit-dal v2.0.0. Each row corresponds to the current (in uA) added when each component was brought online.

"Reset Button" was an interesting one. It's the difference between leaving the nrf51 pin connected to the reset button in a high impedance state, and configuring it as an input with an internal pull resistor.

Serial was purely the consumption of the nrf51 chip. KL26 is only powered when USB is connected. To ensure there were no indirect effects, I also routed the serial interface through P0/P1 on the edge connector instead of to the KL26 chip - the results were the same. the nrf51 uart seems to be a hungry beast - at least with mbed driver.

The Timer row is the cost of bringing up the 1MHz granularity timer (notes in brackets are the components that use the timer). I was curious about this as we replaced the standard mbed RTC clock with this to get additional precision (RTC only gives ~33us precision)

Quiescent current I never managed to track down - seems to be something constant and external to the processor (probably an effect power supply filtering, pull ups, PSU protection diodes, etc).