MicroPython Forum (Archive)

The following factors limit the minimum power that systems will consume when the Pyboard is in standby mode. The first appears impossible to solve without access to the regulator disable pin. The second can be addressed with external hardware, but in the case of the I2C issue the solutions I've come up with are not ideal.

1. The standby current of 29uA is dominated by the regulator quiescent current of 25uA. While it's possible to power the Pyboard directly from 3.3V (e.g. a CR2032 cell) a diode internal to the regulator ensures that it continues to consume current. According to my measurements an additional 10uA.
2. Any external devices (e.g. I2C and SPI chips) will continue to draw power. If an external MOSFET is used to turn off their 3.3V supply before entering standby, current of the order of hundreds of uA continues to be consumed by typical I2C devices by virtue of the Pyboard's I2C pullup resistors.

These issues could be addressed in a V1.1 Pyboard with modifications along these lines. The cost in components would be trivial but it would entail two extra pads - although the regulator disable could be achieved with a solder bridge. Resistor values are arbitrary. The uP pin would be driven low by firmware after a reset or on coming out of standby. On entering standby the pins appear to go hi-z so the MOSFET would automatically turn off, powering down the pullups and external devices.
Any comments?

That looks very similar to a circuit I've seen used for controlling pullups on USB lines.

I think that the pullup on the gate of the MOSFET can be quite large (500K ohms or probably even 1M).

You're right. The values on the MOSFET gate and regulator control were arbitrary. On reflection the value of the resistor on the regulator control pin is critical as, by virtue of the diode in the regulator chip, it will consume power constantly when the board is configured to run from a user's 3.3V supply. It needs to be on the order of 1M to avoid excessive power draw. Perhaps there's a better way to disable the regulator?
[message edited]
To expand a bit more on my thinking. The Pyboard design seems close to achieving extremely low currents when in standby. To use this capability the user would need to power the board from a source such as a CR2032 cell: the power draw of any kind of regulator would be excessive. In this case the one on the board serves only to waste power. Depending on what the Pyboard does when it wakes up, and the frequency of its waking, substantial run times could be achievable.

If it were possible to get the Pyboard's quiescent current down to 5uA it would consume 0.12mAH per day. Given the measurements of @moose http://analysisnorth.com/images/standby_profile.png the Pyboard uses about 9mAS of energy to wake up and return to standby. If this occurred once per hour the consequent daily consumption would be 0.06mAH. This would yield a theoretical runtime on the order of three years from a cell: 0.18mAH per day equates to 66mAH annually. Clearly a practical application will do more than wake up and go back to sleep but I can envisage applications where hourly wakeups are adequate and routine cell replacement at six monthly intervals manageable. Environmental monitoring and data logging come to mind.

Ideally the power consumption of such applications should be dominated by the inevitable draw caused by computation rather than by the overhead of standby current and this looks close to being achievable.

Another application area which might benefit are systems powered from a small solar cell and a supercap - the latter providing power in the hours of darkness. The supercap would be charged to 3.3V by a regulator designed to allow minimal current to flow back when unable to supply power. Some quick calculations suggest the voltage drops could be low enough for feasibility but I have no experience of such designs.

I find following this path very interesting. Albeit I have a few questions and comments.

TLTR: I would love to build an energy-harvesting skin and a low power RF skin (maybe an EnOcean-shield?!) bringing pyboards to IoT and smart home.

The pyboard does not include any wireless communication unlike the wipy-board. Thus, how realistic is the chance that you will power a pyboard over larger periods on tiny small battery. Maybe as data logger for a sensor device. Since it does not spot any communication channel, one might come up with some LEDs or other ways to read a status message. However, those would draw much higher currents then any standby problem. I can see the efforts behind reducing the standby power but want to give awareness that most practical applications might not come even close to those values. Just take the heartbeat and power LEDs on most boards. Those consume often more then any other peripheral or the even the uC itself.
Just to give an comparison the MSP430 which claims to be the power-saving king among the uC-gangs states it consumes 1.5 µA in standby, yet I haven't seen a practical application (with peripherals) which comes even close to this value.
Well, if the discussed ideas could be ported to the wipy board as well, that might be even more interesting, or making sure that a pyboard and one of those wireless modules interact nicely with each other in terms of power consumption. Then we could have a pyboard/wipy which even in terms of IoT/smart home usage becomes interesting and might even leave many proprietary boards behind.

If I understood correctly, the pull-up on the MOSFET will only consume power in the "on" phase, in "off" you mentioned the pin will be high-z, that should limit the current already, isn't it? Anyhow a high resistance doesn't hurt here, since, I guess nobody plans to switch the state with several hundred kHz

Beside of a small solar cell I would be interested to see if we could come up with an energy harvesting skin for the pyboard/wipy. That would be very interesting. RF / vibration / temperature / electrochemical cells, even large charge cycles of a supercap, could be sufficient if one cal live with very short and infrequent on-time periods. There are a lot of battery-less sensor devices from EnOcean would be interesting to see if we could get create a skin to talk to/with those sensors. A pyboard-enocean system would allow us to add pyboards to smart home solutions.

With that respect, for a combination with a wireless module or the wipy board, a wake-up call routine could be helpful. The board powers up every few minutes just to check if there is a request and directly went to sleep again, if no request is present. If there is a request, it does it magic and send values back. Optimizing this check-routine would limit the on-periods and can save a lot of power compared to a fixed periodically wake-up-measurement-calculus-transmission-standby-routine.

Just some thoughts

Regarding practical applications I have a Pyboard driving an e-paper display using the hardware described here https://github.com/peterhinch/micropython-epaper.git. Currently it just runs a test program which periodically displays the time of day and temperature but its power draw between updates is 29uA at 3.3V. Since the sensors are only powered up when being read, others could be added with minimal additional power draw. e-paper, of course, continues to display the results in the absence of any power

In terms of communication I had envisaged using an NRF24L01 which again would only be powered up when required. It would act as the master with the slave module permanently running and listening for communication from the master. As soon as a successful transmission had taken place the master would power off (or shut down) its radio. While I haven't tested this aspect, I have used the NRF24L01 with the Pyboard and it strikes me as eminently usable in applications such as remote data collection.

So, in my view, micropower applications of the Pyboard are eminently practical given a little external hardware and an application based on low frequency updates driven by the RTC. But their design does require some attention to detail and LED's are best avoided. Update rate, and the amount of processing required when an update occurs, will be the predominant factor for mean power draw in many applications.

As for energy harvesting this is an idea I'm very interested in, but haven't studied sufficiently to comment. Likewise WiFi - I backed the WiPy kickstarter and hope to get a board in due course but I haven't yet had a chance to figure out how applicable it might be to ultra low power projects.