Testing power consumption?


Is there any way to test the Pokitto’s power consumption without actually buying a multimeter and hooking it up to the board?

I’m testing out the sleep() function to try to determine how much power it saves and how it can be manipulated to make the most of it.


It’s possible to build a volt meter with a couple of resistors and a second pokitto or arduino I think…


I can’t think of any way that a Pokitto could “self measure” its power consumption, so you’ll need some kind of external equipment. For sleep modes you’ll be measuring quite low currents, in the micoamp regions, requiring a fairly sensitive ammeter with a low burden voltage.

I have a device called the µCurrent, which is designed for this purpose. If you write one or more test programs, I could possibly measure the current with them running and report back to you.

Ideally, a single program would use a button to switch to, and stay in, a particular mode. This would allow the proper range to be set on the meter and allow a steady measurement of each mode.


So it is:

I don’t know how sensitive it would be though.
(And I’m always cautious about mixing 5V and 3.3V devices.)

An interesting project for another day perhaps.

As you already have the necessary equipment I think I’ll take you up on that offer, thank you.

Here’s a program to do precisely that: SleepTest.bin (38.6 KB)
Pressing A toggles between ‘Sleeping’ and ‘not Sleeping’.

In addition, here are two programs that more adequately match my intended use case.

One that doesn’t make use of sleep: ButtonTestSleepless.bin (40.5 KB)

One that does make use of sleep: ButtonTestSleeping.bin (40.8 KB)
(The extra 0.3KB is the sleep function.)

If there is a measurable difference then the use of sleep at the selected point(s) in the program may be worthwhile, and if there is no measurable difference then the use of sleep is inconsequential.

There’s no particular hurry for the results if you have more pressing matters to attend to.


OK. It may take a day or two for me to find a time where I can set up and do the testing.

Note that current draw when not sleeping can sometimes be quite dynamic and getting a proper average can be difficult with strange current waveforms. I may have to use my oscilloscope connected to the µCurrent to properly see this kind of thing.


If you have a harbour freight nearby they have them free all the time in their ad.



Sorry for the delay in doing this testing. In order to measure current, the meter has to be inserted in series with the power source (battery). I was planning to do this by using pogo pins on the power switch with the Pokitto turned off. The meter would then conduct the current though it in place of the switch. Upon further examination, I decided that this would be a bit difficult and also wouldn’t include measurement of the RTC circuit, which is always powered up even with the switch off.

I decided to do it properly by disconnecting the battery and placing the meter directly inline with the positive lead. This took a bit more time.

I’ll give you the results first then, for those interested, I’ve included info on how I did this.

The programs provided don’t do much when supposedly sleeping. Current when the programs were running was close to 44mA and dropped to only about 43mA when sleep was selected.

One possibility is that the display may be drawing a majority of the power (especially the backlight) so the difference between the processor sleeping and running is small overall.

Another possibility is that the processor isn’t actually sleeping for very long overall. It may be waking up for some reason even when SleepTest.bin is in sleep mode.

Something to note is that when the SD card loader is running after power up, before the loaded program starts, the unit draws about 80mA. I’m not sure why this would be. Possibly, the processor does sleep a lot during program execution but there’s no sleeping in the loader. But that’s just speculation. It could be something entirely different.

Also, as a point of interest, about 2.7μA is drawn from the battery (by the RTC and maybe other stuff) when the power switch is off.

Here’s my Pokitto modification and setup used:

I unsoldered the positive battery lead and installed a bent header pin. I put a Dupont connector on the battery lead to allow me to reconnect it for normal use:

I cut a small notch in the bottom case half to feed wires though, below the PEX connector, that can be connected to an ammeter:

I made two extension wires to connect the board and battery lead to the ammeter:

Here’s the measurement setup. The μCurrent device presents a very low burden voltage and converts the current to a corresponding voltage that is measured by the multimeter:

Concerns regarding arms

I went back a checked and found that this is only when the menu to select a new program is displayed, after pressing C. The volume select screen is the normal 44mA. So maybe accessing the SD card draws the additional power.


Firstly, sorry for the delay in replying and thank you for your efforts.

I did actually spot this yesterday but I didn’t reply immediately because I wanted to make sure I had time to read the comment properly.

It’s no problem.
Like I say, I had plenty of other stuff to be getting on with so there was no rush.

I probably wouldn’t have thought of that.

That is indeed quite fiddly.
I hadn’t anticipated it being quite so involved.

Perhaps part of the problem is that the programs don’t do much when not sleeping.

A bit of text printing is hardly going to max out the CPU.

Not a massive drop, but it is a drop at least.

This is quite likely.

There are actually two sleep modes, a light sleep mode and a deep sleep mode.
The light sleep only disables a few things and wakes up quite easily.
The deeper sleep disables more things and is more difficult to wake up from.

For anyone interested you can read about that here:
(Also linked to in the main post.)

I used the lighter sleep because I tried the deep sleep and realised

For my use case I only want a brief, light sleep because it’s something I’d be using little and often, so I used the lighter sleep mode.

I did try using the deep sleep and I had trouble getting out of it.
I realised that I’d probably have to set up some additional interrupts to get it to wake up,
which would probably be too much work for my use-case.

It would be good to research the power consumption of deep sleep at a later date though.
It would be useful for tamagotchi-like virtual pet games.

It’s plausible.
To know for sure SD card accesses would have to be included in the test.


@MLXXXp and @Pharap , the numbers that we’re seeing here are result of 2 things more than anything else

  1. the display backlight really needs to be switched off for sleeping to have any meaningful effect
  2. the sound amp IC really needs to be disabled to reduce power draw

And @MLXXXp , I noticed your comments on Arduboy (or Gamebuino?) forums about the need to open up the schematics to the community to ensure continuity of the project. I felt a tinge of guilt and I really will do something about this in the near future. Edit: otherwise, people like you who have an interest in the hardware side of things can’t really investigate and improve things like the sleep mode


Something I mentioned earlier is that I can use an oscilloscope connected to the
μCurrent in place of, or alongside, the voltmeter. This would make it possible to see short changes in current consumption over time, to get an idea of how often and how long sleep is occurring. I may do this with the provided test programs if I find a little time.

Now that I’ve modded my Pokitto, it’s fairly easy to set up for additional testing with any programs that anyone wishes to provide.


The clock speed is constant. If it’s not sleeping, it’s “maxed out”.


As @FManga just said, with microcontrollers power consumption doesn’t vary depending on the task being performed. Even executing NOPs doesn’t draw any less power than doing complex tasks. Power consumption is based on clock speed, the use of internal and external peripherals, and the use of idle/sleep modes.


In the case I’m thinking of, both of these will probably still be in use to a degree.

Though those things would be useful to take into account for something tamagotchi-like.

I think we could also do with a diagram with the dimensions of the case.

I remember someone asking about dimensions many months back.

Granted most people can measure the case themselves,
but that’s a bit like reinventing the wheel.
Having all the dimensions pre-measured would save people time and effort.

I could do so if there’s interest in doing so,
but personally I’m not really concerned at the moment.

Knowing that the use of sleep draws less power than not using it (albeit a vanishingly small amount) is pretty much all I needed to know for what I’m doing.


In most cases, you don’t need to call sleep() directly. Mbed OS enters sleep mode automatically any time the system is idle. That is when all your threads are in a waiting state, for example waiting for an event or a timeout.

Presumably that’s going to be coming into play somewhere and presumably doing something more intensive would minimise that effect.

I could be wrong though.
The whole ‘Mbed OS’ idea is still a bit strange to me.


Note: MbedOS5, the RTOS, enters sleep when inactive. MbedOS2 (as used in Pokitto), the non-RTOS library, will not


That’s good to know.
I might have to edit that into the technical documentation later because it’s pretty important.

In that case it’s more likely that the sleep measurements are correct.