Measurement – Tuomas Kulve

Wireless MCUs and power consumption, part II

October 20, 2014tuomas

In the Part I I described my real project with the radio: a wireless power consumption meter. But it is supposed to be a low power MCU so why not run it indefinitely with a renewable power source?

Solar power is the easiest form of renewable energy and I decided to try it out. That is of course not an option in the dark closet where the smart electricity meter is so I ended up designing a modular solar powered wireless soil moisture sensor.

Measuring the moisture of the soil is only a secondary objective. The real goal is to see if I can keep the radio running continuously throughout the Finnish winter. In December 2013 we had a total of 24 minutes of sunshine during a period of 18 days, so having solar power available should not be taken for granted.

Another issue is the temperature as common batteries must not be charged below zero degrees Celsius. I decided to go with a large solar panel from Sparkfun and 10 F super capacitors from Digikey. The panel provides a maximum of 9.15V which nicely matches four 2.7V super capacitors in series.

The voltage of solar panels decreases quickly if too much power is drawn from them. All larger solar panel systems use maximum power point tracking (MPPT) which tracks the voltage and limits the power draw if the voltage drops. I tried to find MPPT solutions for small systems but did not find anything suitable for this project. Adafruit’s Solar Lithium Ion/Polymer charger is based on MCP73871 but that seems to be designed for batteries alone. There is also bq25570 from TI which looks otherwise very well suited for this kind of project but it seems to be designed for even smaller solar panels.

Solar powered soil moisture sensor — Solar powered wireless soil moisture sensor

The final software will make the measurements once an hour and sleep the rest of the time in the deepest sleep mode. The power consumption in the sleep is only a few micro-amps for the whole thing.

I made some initial tests with a five minute interval behind glass windows and without direct sunshine. During the last day I tried to keep the panel pointed directly to the sun, when possible and that clearly shows in the graph below.

Solar measurements — Solar panel and super capacitor voltages over time.

For now I have just printed out the values and created a graph about the measurements. For the electricity measurements I was using Sparkfun’s Phant on my own server but that seemed to lack features and stability. Currently I am testing ThingSpeak and letting them handle the hosting. It is open source so I could move it to my own server as well. So far the ThingSpeak looks good.

Based on the test with shorter measurement interval, I am hopeful about the radio being able to run through the long and dark winter in Finland.

Wireless MCUs and power consumption, part I

October 16, 2014tuomas

Electricity is expensive and being low power is environmentally friendly. And what is more motivating than seeing the total power consumption in real time? There are plenty of commercial products out there already but will they give you the raw data so that you can plot nice graphics? Not that many. And of course self made is always .. self made.

Lately in Finland the old electricity meters have been replaced with smart meters and they seem to have leds showing the power consumption. The model I have has a led that blinks once for every consumed watt-hour so it is easy and safe to calculate the power consumption by counting the blinks.

I am using a self designed CC430 based 433Mhz radio board and a simple photo resistor to count the blinks of the led in the apartment’s smart meter. Every minute it sends the count to another radio hooked into a Raspberry Pi that in turn sends the value to a server in the network. Then I have a simple javascript based web page that shows the data with a minute or two latency.

Power consumption over time — Javascript based power consumption info page.

There is no power plug that I could use for the radio board so it is running on two AA batteries. I put everything in a small plastic box. Below is an image of the box before I placed it next to the smart meter.

The radio part of the CC430 is turned completely off when not sending and the MCU part is sleeping. The only part running is the comparator that compares the photo resistor’s output to a predefined thresholds. If the threshold is exceeded an interrupt fires and I count the interrupts. Once a minute I reset the counter, turn on the radio and send the count over the air. Running the comparator takes some 200uA and I think I might be able to just bluntly interpret the photo resistor’s output as GPIO. That should drop the consumption below 10uA. Even with the higher consumption it has been running well for a few months now as can be seen in the graph below.

Battery voltage level — 2xAA voltage level over time.

Having to replace batteries is inconvenient and another project of mine will be running outside so I can use a solar panel. More on that in Part II.

n900 Battery Duration: Ogg vs. MP3

November 7, 2009March 27, 2011tuomas

There have always been complaints about Ogg being more of a battery hog on the Nokia tablets compared to Nokia optimized MP3. I decided to measure the difference.

All tests were run on a preproduction n900 device that Nokia distributed at the Maemo Summit. The software is the Maemo5 41-10 release which was already installed in the device. I installed Ogg Support, gst-av, ffmpeg and OpenSSH. Otherwise the device is the default 41-10 release. WLAN connection was configured but not activated during the tests. A SIM card was in place only in the SIM idle test.

Before every test I charged the device, disconnected the charger once I noticed the green led, and rebooted the device. After the boot I started a simple script in the xterm. The script logged current time to a file, run “sync” command and slept 60 seconds after which it started the loop again.

Idle tests

I run two idle tests between the libvorbis and ffvorbis tests but I’ll introduce the idle results first.

First idle test was a generally idle device. I.e. it did have the default processes running but I didn’t start anything, except my logging script. During the test I did check a couple of times if the device was still on. The battery lasted for 93.8 hours.

According to Igor Stoppa, there’s a cellmo sw bug that makes current higher without a SIM card. Therefore I rerun the idle test with a SIM card inserted. During the test I received two phone calls which I hung up, I received two SMS messages and wrote one. At one point the notification led was blinking for 45 mins. The battery laster for 93.6 hours.

There’s probably a few hour error margin on those tests, so basically the battery lasted roughly a bit over 90 hours in both tests.

Powertop shows that after 60 seconds of showing the xterm with display blanked, the CPU is mostly in the highest C4 sleep state:

C#	Ratio	Avg/dura	Frequency	Ratio
C0	0.3%		600 MHz	0.0%
C1	0.0%		550 MHz	0.0%
C2	0.1%	1.1ms	500 MHz	0.0%
C3	0.2%	15.2ms	250 MHz	100.0%
C4	99.5%	2297.0ms

Ogg vs. MP3

Now that we know how long the device will last when idle we can move to the actual results.

I run two sets of tests. First one was with the Ogg Support 1.0.5 from Extras and the second one with Felipe’s gst-av (2009-09-25) which is using vorbis decoder from FFmpeg (2009-09-07). I repeated both tests three times, running every other test with MP3 and every other with Ogg.

After restarting the device with a fully charged battery I started the logging script in the xterm, started the File Manager and clicked on the MP3 or Ogg file which then started playing that single file in a loop in the Media Player. Both files were encoded with variable bitrate 192kbps settings. Volume of the device was set to minimum and no headphones were connected.

This is what powertop shows while playing MP3 in Media Player compared to libvorbis:

MP3

libvorbis

C#	Ratio	Avg/dura	Frequency	Ratio
C0	37.9%		600 MHz	3.1%
C1	0.0%	0.2ms	550 MHz	1.1%
C2	7.0%	3.0ms	500 MHz	17.5%
C3	55.1%	8.0ms	250 MHz	78.3%
C4	0.0%

C#	Ratio	Avg/dura	Frequency	Ratio
C0	70.1%		600 MHz	18.2%
C1	0.0%	0.1ms	550 MHz	0.0%
C2	4.7%	2.7ms	500 MHz	28.8%
C3	25.1%	7.8ms	250 MHz	52.9%
C4	0.0%

Clearly while using libvorbis the CPU spents more time in lower sleep state and running with higher frequency. The following graph shows how this affects the battery. The battery lasts around 18 hours while playing MP3 but only around 11 hours while playing Ogg.

Next numbers are with ffvorbis instead of libvorbis. Powertop shows that while using ffvorbis the time spent in different sleep states matches quite closely to the ones of MP3 usage:

MP3

ffvorbis

C#	Ratio	Avg/dura	Frequency	Ratio
C0	37.9%		600 MHz	3.1%
C1	0.0%	0.2ms	550 MHz	1.1%
C2	7.0%	3.0ms	500 MHz	17.5%
C3	55.1%	8.0ms	250 MHz	78.3%
C4	0.0%

C#	Ratio	Avg/dura	Frequency	Ratio
C0	38.4%		600 MHz	2.1%
C1	0.0%	0.1ms	550 MHz	0.0%
C2	5.7%	3.1ms	500 MHz	13.2%
C3	55.9%	8.3ms	250 MHz	84.6%
C4	0.0%

The similarity of the powertop numbers can be seen in the battery duration as well:

The average battery duration while using ffvorbis was slightly better than while using MP3 but probably well within the error margins. So basically they are equal when battery duration is concerned.

It’s interesting to see how the situation changes in a year, will Nokia make better optimizations to their MP3 decoder than the community to the FFmpeg. These tests were run in a preproduction device with a pre-sales software. I’m sure the overall power management of the device will get (even?) better in the future software releases.

Addition (2009-11-17):

When using the speakers the n900 runs some “speaker protection algorithms” that take extra power. I repeated the ffvorbis test case with Nokia’s headset and here are the results:

Battery duration: ffvorbis with headphones

On the average the battery duration improved a bit over three hours.

Addition (2009-11-25):

I run the same tests (Ogg Support 1.0.5, no headset) for Flac:

n900 with a pre-sales w41-10 software can run Flac roughly 1.5 hours longer than MP3.

GCC options and floating point

May 17, 2008March 27, 2011tuomas

There was (again) some discussion on #maemo about gcc options regarding VFP usage so I decided to make a simple test with different gcc options using the Maemo’s cs2005q3.2-glibc2.5-arm toolchain. Nothing new here for people already familiar with the floating point stuff.

In the test I compiled a very simple test code with different -mfpu and -mfloat-abi options, -O2 and -march=armv6 were given in all cases. The asm code is linked in the table. The code is a simple for loop which could be optimized to one round but based on the results it looks like the gcc didn’t do this kind of tricks.

Although you can ask the default options from the gcc I decided to test also without the options. The test was run on n810 and results are in the table below.

GCC	none	hard	soft	softfp
none	0m 31.11s 0m 31.01s 0m 0.00s asm	– – – asm	0m 31.24s 0m 31.00s 0m 0.00s asm	0m 4.38s 0m 4.37s 0m 0.00s asm
fpa	0m 30.64s 0m 30.54s 0m 0.00s asm	5m 52.53s 0m 21.25s 5m 30.66s asm	0m 30.57s 0m 30.55s 0m 0.00s asm	5m 52.56s 0m 21.06s 5m 30.69s asm
vfp	0m 31.09s 0m 30.99s 0m 0.00s asm	– – – asm	0m 31.08s 0m 31.00s 0m 0.00s asm	0m 4.40s 0m 4.39s 0m 0.00s asm

Looks like the default for -mfpu is vfp and the default for -mfloat-abi is soft.

There are three different values, one takes some seconds, one takes some tens of seconds and one takes some minutes.

This was expected as there are three different ways to do floating point math. In the slowest one the kernel emulates the fpu after cpu has run into undefined floating point opcode. This is extremely slow as there are a lot of context switches. A faster way to do the floating point math without the hardware is to let the gcc to compile the floating point math to the binary itself (and something in libgcc?). The fastest way is to use the VFP hardware.

N800 and GCC options

February 14, 2007March 27, 2011tuomas

I was a a bit surprised to hear that Nokia doesn’t compile the Maemo stuff with any ARMv6 specific GCC options. According to someone in IRC the gain is insignificant compared to increased size (and thus booting time) when not using thumb mode.

I decided to test this out and compiled a bunch of packages with -mcpu=arm1136j-s -mfpu=vfp -mfloat-abi=softfp GCC options and without -mthumb.

The performance tests included measuring rootfs booting time, gtk-perf, cairo-perf, encoding and decoding with theora and decoding with vorbis. Memory comsumption was not measured, even though it should have been. None of the tests were made with scientific accurance and there can be errors in the tests, although zuh double checked most of the tests. There aren’t much details here, but I should have them written down, so ask if you have any questions.

I took some of the gtk, hildon, glib, xlib, etc libraries and binaries that were compiled with -mthumb and compared the sizes. The sizes increased 23% in average, the minimum increase being 8% and the maximum 30%.

Booting time was calculated by measuring the time between setting the clock in /etc/init.d/rcS and running the last init.d script. This is not very accurate since processes are started to background etc. The booting time increased roughly 8% (2 seconds on my MMC).

Encoding with theora was a bit of a surprise. The encoding time with theora compiled with no GCC options and with –disable-float was even slightly faster than with floats and the mentioned ARMv6 GCC options. Decoding with theora seemed to be roughly 5% faster with the new options.

The biggest practical difference in this test came with vorbis decoding. Decoding with ARMv6 options took only 30% of the time when compared to no options.

Gtk-perf doesn’t cover many widgets but hopefully shows the direction of the performance differences. The improvement was around 14%.

Cairo-perf doesn’t give one nice number to for making hasty conclusions, but the improvements varied from 1.05x to 7x, while the average was 1.8x. cairo-perf-diff-files reported over 800 speedups and two slowdowns.

zuh writes about memory comsumption, thumb mode swithing, gtk-perf and cairo-perf in more detail in Movial‘s syslog.

For me the disk space isn’t an issue and I don’t boot the device so often that the two second delay in bootup really matters. So, for me the little speedups are welcome. I can even tolerate the memory loss reported by zuh.