Jump to content

[RfC] Using A20 board with Armbian as 'powermeter'


Recommended Posts

From time to time I searched for a somewhat precise power meter that produces not only a simple visual output but data that can be integrated into a monitoring system (be it RPi-Monitor, SNMP or something else). The ODROID Smart Power looked somewhat promising but was rather expensive and seems to be sold out in the meantime.

 

Zador told me some time ago some details about different ADC measurements with Lime2, I checked this some days ago when combining Lime2 with a H3 board and am now thinking about simply using a Banana Pro to be used as such a power meter since I'm currently preparing measurements of a few H3 boards to arrive soon (see for some preparations this thread). 

 

The idea is to power Banana Pro through the DC-IN jack, ensure that consumption of the board itself remains identical (fixed cpufreq settings, stopping any daemons that are not needed, monitoring performance data of the board to be able to drop results if something looks suspicious) and then to power 4 Nano Pi NEO through the 2 USB ports from Banana Pro and do some math (subtract the Banana's own consumption, divide the difference by 4 and add some correction/calibration with a formula)

 

This way I can utilize RPi-Monitor running on the Banana Pro to monitor consumption of the 4 NanoPi NEO and also some basic data from the NEOs (cpufreq, SoC's temperature, /proc/stat, count of active CPU cores to test 'low power throttling' settings). Data aquisition from the NEOs will be done using netcat (using SSH with keyless authentication every few seconds is already too 'heavy' to simulate realistic 'low power' scenarios)

 

The idea is to stay below 1.5W per board since I only want to test out low power scenarios (limiting max cpufreq to 912 MHz and always staying at the lower VDD_CPUX voltage and so on) in the hope to be able to monitor such minor stuff like LEDs (Jeff Geerling reported 5mA consumption difference on RPi but I would suspect that is more of an assumption than a measurement backed by monitoring data, maybe when switching 8 LEDs on 4 boards in parallel we get results that matter).

 

I already tested whether power provided through USB ports can be measured on Banana Pro (true. I use vanilla kernel with Zador's AXP209 patches) but I have two problems with the whole approach:

  1. Due to being an electrics noob I don't know whether the whole idea is crap or not
  2. I believe I need some sort of calibration eg. a device that draws exactly 5W so I could compare /sys/power/axp_pmu/ac/amperage and /sys/power/axp_pmu/ac/voltage before/after and then use a correction formula)

Any comments on that? 

 

I want to provide not only the data/results with the NanoPi NEOs gathered from the measurements but also the tools/scripts so others could also use a cheap A20 board together with Armbian later to do such 'low power' energy measurement stuff if the approach is able to produce reliable numbers.

 

Link to comment
Share on other sites

Dislaimer, I'm computer engineer and at my job I was working on a product which had some current measurement (< 6A) for protection, so my knowledge isn't perfect.

 

Everything depends how smart PMIC on Banana Pro is. You should test if a constant load (e.g. resistor), which would simulate maximum expected load, through time always reports same power. Possible issue I see here is that changing temperature (if load is high) might ruin measurements. I'm not sure if USB traces are designed for currents higher than 500mA. Another possible issue I see here is that you would also measure power loss on the cables and you know that with bad cables it can be significant. Definetly I would try to validate setup first and start small. What do you plan to use for 5W device?

Link to comment
Share on other sites

I already tested whether power provided through USB ports can be measured on Banana Pro (true. I use vanilla kernel with Zador's AXP209 patches) but I have two problems with the whole approach:

  1. Due to being an electrics noob I don't know whether the whole idea is crap or not
  2. I believe I need some sort of calibration eg. a device that draws exactly 5W so I could compare /sys/power/axp_pmu/ac/amperage and /sys/power/axp_pmu/ac/voltage before/after and then use a correction formula)

Any comments on that? 

I'm not sure AXP209 is precise enough (well, datasheet doesn't provide ADC tolerance and current measurement path details) to use it for any absolute measurements, and you'll have to verify that it is linear enough to make relative measurements. If you want to use your board as a USB power meter - it may be possible. If you want to produce meaningful numbers - you better use something else. Speaking of meaningful numbers, Banana Pro generates 5V from IPSOUT voltage with DC-DC converter running (presumably) at 1MHz (yes, it has capacitors at input, but still), and, again, we don't know how well AXP209 handles measuring non-DC current.

 

So just out of my mind, wouldn't it make more sense with a shunt.

Measure it with A20 or Arduino?

Current shunts are usually designed for very small output voltage (i.e. 75mV at maximum current). A20 has only 8-bit Edit: 6-bit (!) LRADC (and doesn't have proper driver for reading it), and Arduino even at 3.3V reference will have input resolution of 3.2mV/bit, so with 5A 75mV shunt you will get resolution of 200mA/bit, which is bad. So either use shunt with special amplifier or buy a Hall effect current sensor.

Link to comment
Share on other sites

When my scope died 3 years ago, I had a look at xoscope. Audio cards have a 16 bits adc and so must have an A20 card ? By the way, one for the mic and another with 2 chans on the camera connector. (I have to get a flat cable to check audio input, because it is almost impossible to solder on card).

 

I had bought a dozen of metal resistor to make a shunt but never found the time to check it and lost my calcualtions about current mesurement, impedance and input limit on audio cards. With 10 1 ohm resistors in parallel, and 1 amp current, the 0,1 ohm shunt should take 0,1 W and 100 mV on power line. And I should be able to calibrate and mesure transcient and average current at 20 kHz. (I also checked an SPI ADC on RPI - easy to wire on a test board - the problem was then the noise level).

Link to comment
Share on other sites

Tank you all for the (mostly discouraging) answers so far :)

 

I thought about my approach and will start differently (more experimental and testing out some stuff instead of relying on assumptions from the beginning).

 

I ordered a few 20AWG rated USB-to-Micro-USB cables already. Will use them to test whether cable length makes already a difference regarding consumption when powering the NanoPi NEOs through Micro USB. After that I might use the cables for soldering experiments combining a short cable with type A jack with 4 short 22 AWG rated jumper wires to be able to power 2 NEO from one USB port each. I found this 'AWG 22AWG Dupont Jumper Wire 10cm cable Line 1p-1p pin connector 20pcs'  eBay offer but most probably the 22AWG rating is BS and I just should ensure to use pretty short cables: http://goughlui.com/2014/10/01/usb-cable-resistance-why-your-phonetablet-might-be-charging-slow/

 

I wanted to use a different approach first (using a bread board) but as Jernej pointed out the chances to measure losses through cabling are too high.

 

So I will simply start with this setup and experimentally try whether I'm able to measure consumption differences (eg. connecting one NanoPi NEO to each USB port, sampling voltage/consumption every second, switching on the leds on both NEO for 5 minutes, then off, then on again... and see whether 5min averaged consumption values show an indication regarding consumption). Next task is to get an idea how high current limits of the Banana's USB ports are and so on.

 

Then I'll see whether I'm able to measure small consumption differences even when not being able to get real consumption differences due to missing calibration and unknown linearisation of the ADC output. But this way I'm already able to compare different measures to limit consumption if I test one by one and always start with the same 'base line'.

 

A few days ago I though I would be able to do calibration on my own based on consumption values available on the net (eg. an idle RPi 2 uses 420 mA @ 5V) but after checking some of these numbers it's quite obvious that they're all BS more or less since these are just the results of random people putting random numbers they got from both very unreliable USB powermeters and precise multimeters in nice looking blog posts that get shared hundreds of times in RPi forums.

 

A friend of mine told me another friend of him studying at the local technical university has better equipment and is interested in results too. Maybe I meet him so I can benefit from his knowledge (to measure correctly) and equipment and then a calibration approach using AXP209 and the USB ports might work. We'll see, I start now with a slightly different focus (on relative differences and testing whether the whole idea works or not -- will then get back here with results and questions :) )

 

Thanks again!

Link to comment
Share on other sites

Next task is to get an idea how high current limits of the Banana's USB ports are and so on.

I don't see any current limiters on BPro (compared, for example, with Orange Pi PC or Cubietruck schematics), so USB ports current limit is based on DC-DC converter current limit and voltage drops on PCB traces. Only OTG port is protected with SY6280 current limiter.

 

I ordered a few 20AWG rated USB-to-Micro-USB cables already. Will use them to test whether cable length makes already a difference regarding consumption when powering the NanoPi NEOs through Micro USB. After that I might use the cables for soldering experiments combining a short cable with type A jack with 4 short 22 AWG rated jumper wires to be able to power 2 NEO from one USB port each. I found this 'AWG 22AWG Dupont Jumper Wire 10cm cable Line 1p-1p pin connector 20pcs'  eBay offer but most probably the 22AWG rating is BS and I just should ensure to use pretty short cables: http://goughlui.com/2014/10/01/usb-cable-resistance-why-your-phonetablet-might-be-charging-slow/

In addition to (or instead of) ordering cables you could order USB A and miniUSB/microUSB plugs and just solder any wires that would fit.

 

A friend of mine told me another friend of him studying at the local technical university has better equipment and is interested in results too. Maybe I meet him so I can benefit from his knowledge (to measure correctly) and equipment and then a calibration approach using AXP209 and the USB ports might work. We'll see, I start now with a slightly different focus (on relative differences and testing whether the whole idea works or not -- will then get back here with results and questions :) )

If you basically want USB power meter with external interface for reading measurements, you could combine some USB sockets/plugs, current sensor and ATtiny MCU programmed as I2C slave for reading internal ADC

 

According to this thread there is a 12 bit ADC available that can be misused for this and that after some soldering: http://forum.lemaker.org/thread-15573-1-1.html

Yes, but these pins may be used or not used on different boards, so amount of soldering and configuration steps may vary.

Link to comment
Share on other sites

 

So just out of my mind, wouldn't it make more sense with a shunt.

Measure it with A20 or Arduino?

Current shunts are usually designed for very small output voltage (i.e. 75mV at maximum current).

A20 has only 8-bit LRADC (and doesn't have proper driver for reading it), and Arduino even at 3.3V reference will have input resolution of 3.2mV/bit, so with 5A 75mV shunt you will get resolution of 200mA/bit, which is bad.

So either use shunt with special amplifier or buy a Hall effect current sensor.

 

Are we talking about the same shunts, my idea was in this way: Use in current measuring

I see that they write 500A 75mV, but we are talking about 0,2 - 2A @5V. A Multimeter can measure such little current, why isn't it possible

in this scenario with A20 or Arduino.

 

PS: I don't know about Hall effect current sensor (Google says thats the one you just put around the cable - good for many Amps like starting a car)

Link to comment
Share on other sites

Are we talking about the same shunts, my idea was in this way: Use in current measuring

I see that they write 500A 75mV, but we are talking about 0,2 - 2A @5V. A Multimeter can measure such little current, why isn't it possible

in this scenario with A20 or Arduino.

I was talking about shunt like this: http://www.chipdip.ru/product/75ship1-5-0.5/

I'm not saying it's impossible to use this with Arduino or A20, I mean you can't connect it directly - you have to use amplifier and/or MCU or external ADC to make more or less precise measurements. In addition you need to wire it properly since it provides no isolation.

 

PS: I don't know about Hall effect current sensor (Google says thats the one you just put around the cable - good for many Amps like starting a car)

There are "Arduino compatible" modules like this or this. Yes, they are quite expensive (high current ACS758 based ones) and they are designed for high currents, but you can connect them to Arduino directly.

Link to comment
Share on other sites

If you basically want USB power meter with external interface for reading measurements, you could combine some USB sockets/plugs, current sensor and ATtiny MCU programmed as I2C slave for reading internal ADC

 

No unfortunately I can't since I simply lack the skills :)

 

And apart from that I will most likely end up with just another power meter producing wrong readouts since I still lack the equipment to do calibration properly (compare first and last post here for example)?

 

Therefore I will start simply with AXP209 measuring the whole board consumption and start to test whether I get significant relative differences when switching on/off leds, choosing long time frames and using averaged values. If that works I still have not that much clue about real differences in mA or mW but am able to compare which measures are more effective than others.

 

And given I use the same cabling I'm also able to compare different SBC (just ordered an RPi Zero with 'special' camera cable for the same price directly at Pimoroni since here in Germany the cheapest variant to get this board is 39€ -- a 'starter kit' with a bunch of useless stuff). My main interest is in finding out where to adjust what to decrease consumption while being able to control performance and for this purpose my setup might already be sufficient even when I'm not able to produce absolute consumption numbers.

Link to comment
Share on other sites

If you have electronics skills, you can easily make a hat with an MCP3002 (https://www.sparkfun.com/products/8636 2.3$) : 10 bits 2 channels SPI ADC.

 

Well, I don't have electronics skills, I just read here and there and came to the conclusion that most approaches to measure low currents are either too expensive or too crappy (most probably both). After comparing a lot of consumption numbers published for various RPi models I came also to the conclusion that the moronic 'passive benchmarking' approach (collecting numbers without meaning) also applies to consumption figures: People love numbers, people love comparing numbers, people don't care at all about their meaning since numbers are enough.

 

That said I could try to develop an external ADC solution to read out low currents. Or I use AXP209 readouts and add a random generator ;)

 

At least that was my impression after reading about "burden voltage" and how that affects measurements in low consumption area. Even if I could build such a device I lack both knowledge and equipment to calibrate readouts and to verify that numbers are correct.

Link to comment
Share on other sites

My current approach is this: I added this line to /etc/rc.local on my "PSU" (the Banana Pro feeding the NanoPi NEOs later):

/usr/local/bin/monitor.sh &

And this script simply reads current/voltage from DC-IN and adds it to a log file:

root@bananapro:~# cat /usr/local/bin/monitor.sh
#!/bin/bash

while true ; do
	read AC_Voltage </etc/armbianmonitor/datasources/ac_voltage
	read AC_Current </etc/armbianmonitor/datasources/ac_current
	echo -e "$(cat /proc/loadavg | cut -f1 -d' ')\t$(( ${AC_Voltage} * ${AC_Current} / 10000000 ))\t$(date)" >>/tmp/lala
	sleep 1
done
root@bananapro:~# tail /tmp/lala 
0.14	100833	Mon Jul 25 18:09:17 UTC 2016
0.14	100585	Mon Jul 25 18:09:18 UTC 2016
0.14	105400	Mon Jul 25 18:09:19 UTC 2016
0.14	96854	Mon Jul 25 18:09:21 UTC 2016
0.21	105223	Mon Jul 25 18:09:22 UTC 2016
0.21	100980	Mon Jul 25 18:09:23 UTC 2016
0.21	99684	Mon Jul 25 18:09:24 UTC 2016
0.21	97640	Mon Jul 25 18:09:25 UTC 2016
0.27	102098	Mon Jul 25 18:09:27 UTC 2016
0.27	105259	Mon Jul 25 18:09:28 UTC 2016

First and last row are for control purposes only (average load exceeding 0.3 is at least a sign that the Banana Pro itself has a bit too much to do, so time to throw results away) and 'sampling rate' is approx 1.1 seconds. So the idea is to monitor average consumption values over longer periods of time in the hope changes then get visible.

 

Banana Pro is now up and running for 23 minutes. Since we know that booting comes along with higher consumption I simply calculate the average consumption value for the last 19-20 minutes:

root@bananapro:~# uptime
 18:12:09 up 23 min,  1 user,  load average: 0.26, 0.25, 0.24
root@bananapro:~# expr 20 * 60
1200
root@bananapro:~# SampleCount=1200
root@bananapro:~# Average_Value=$(tail -n${SampleCount} /tmp/lala | awk '{n++;sum+=$2} END {print n?sum/n:0}')
root@bananapro:~# Rounded_Value=$(echo ${Average_Value} | awk '{printf("%.2f",$1 / 100)}')
root@bananapro:~# echo $Rounded_Value
1057.39

The code above simply takes the last 1200 entries in my log file and calculates the average value of the 2nd row (awk '{n++;sum+=$2} END {print n?sum/n:0}'). The $Rounded_Value is the same value in a human readable format -- in this case in mW (for W it could read 'awk '{printf("%.3f",$1 / 100000)}')' instead).

 

Now a script will check average consumption values hourly within the next 24h (in the hope they're pretty identical), then I let the Banana Pro power an Orange Pi PC where I will switch the two leds on/off every hour. If the average consumption values then differ in a reproducible way I will continue since then I get small relative consumption differences reliably reported regardless of the real consumption difference in mA or mW.

Link to comment
Share on other sites

Some results:

Tue Jul 26 21:00:01 UTC 2016	2288.38mW	Load: 0.389	PMU Temp: 38.27°C
Tue Jul 26 22:00:01 UTC 2016	2295.86mW	Load: 0.405	PMU Temp: 38.19°C
Tue Jul 26 23:00:01 UTC 2016	2290.80mW	Load: 0.401	PMU Temp: 38.16°C
Wed Jul 27 00:00:01 UTC 2016	2294.58mW	Load: 0.400	PMU Temp: 38.22°C
Wed Jul 27 01:00:02 UTC 2016	2287.75mW	Load: 0.389	PMU Temp: 38.17°C
Wed Jul 27 02:00:01 UTC 2016	2295.29mW	Load: 0.361	PMU Temp: 37.99°C
Wed Jul 27 03:00:01 UTC 2016	2291.04mW	Load: 0.384	PMU Temp: 37.86°C
Wed Jul 27 04:00:02 UTC 2016	2291.57mW	Load: 0.386	PMU Temp: 37.87°C
Wed Jul 27 05:00:01 UTC 2016	2289.25mW	Load: 0.384	PMU Temp: 37.87°C
Wed Jul 27 06:00:01 UTC 2016	2303.64mW	Load: 0.378	PMU Temp: 37.90°C

This is average consumption and load (using 2740 samples of the log which represents 60 minutes) monitored hourly on Banana Pro. PMU temperature is a 3 minutes average value. Orange Pi PC is fed through one USB port of Banana Pro and the only difference is a cron job on OPi PC switching on/off both leds every hour:

root@FriendlyARM:~# cat /usr/local/bin/switch-leds.sh
#!/bin/bash

cat /sys/class/leds/red_led/trigger | grep -q '\[default-on\]'
case $? in
	0)
		echo none >/sys/class/leds/green_led/trigger
		echo none >/sys/class/leds/red_led/trigger
		echo none >>/var/log/leds.txt
		;;
	*)
		echo default-on >/sys/class/leds/green_led/trigger
		echo default-on >/sys/class/leds/red_led/trigger
		echo default-on >>/var/log/leds.txt
		;;
esac

I would call this (measuring the effect of 2 leds switched on/off) already worst case scenario but with some good will one could say: It works somehow since by averaging the results above we get ~6mW difference reported.

 

Things I learned (or at least think I learned):

  • Using actual values is useless, averaging and monitoring over long periods of time is necessary
  • taking 30 min average values is not precise enough, 60 min look better
  • Accessing RPi-Monitor's web interface while measuring/monitoring already destroys everything since added activity is too high

Bildschirmfoto%202016-07-27%20um%2008.36

 

Bildschirmfoto%202016-07-27%20um%2008.37

 

Bildschirmfoto%202016-07-27%20um%2008.38

 

(Timestamps in the logs are UTC, in RPi-Monitor CEST therefore 2 hours difference!)

 

Now Orange Pi PC is switched off, I'll monitor idle consumption of Banana Pro alone the next hours and will disconnect network in the afternoon to see whether that makes a difference. Still the whole approach is somewhat questionable but to get relative differences of different energy saving measures it should succeed (as an example: a few hours the cronjob on the idling OPi PC switched also DRAM clockspeed between 432 MHz and 624 MHz and this resulted in reported consumption differences of 30mW or more -- I still don't know how much the difference is in absolute numbers but at least that adjusting DRAM clockspeed is many times more efficient than switching on leds when it's about minimizing consumption).

 

If anyone knows how I can switch off as much background tasks as possible in Xenial then please tell me. At the moment the Banana Pro simply runs a nearly unmodified vanilla Xenial build (cpufreq settings: always running at 960MHz) which is responsible for too much 'noise' due to unwanted background activity. Support log: http://sprunge.us/KaJd

Link to comment
Share on other sites

"switched also DRAM clockspeed between 432 MHz and 624 MHz ..."

 

Have you made stress test with reduced DRAM clockspeed ? My BPI M2+ entered in a total instability state while compiling large packages ending up with system freezing. Even with reduced CPU clockspeed and number of cores - not a CPU heating problem. The symptoms disappeared when I reseted original DRAM clockspeed. Could it be a problem of eMMC calibration ? (I'll make other tests with io activity trace and reduce DRAM speed when I eventually manage to get *!@? wireshark running on gentoo)

Link to comment
Share on other sites

"switched also DRAM clockspeed between 432 MHz and 624 MHz ..."

 

Have you made stress test with reduced DRAM clockspeed ?

 

Nope but that's on my list. In case you decreased DRAM clockspeed below Allwinner's lower limit (408 MHz) then please let's continue discussion where it belongs to: http://forum.armbian.com/index.php/topic/1614-running-h3-boards-with-minimal-consumption/?view=getlastpost

Link to comment
Share on other sites

Now Orange Pi PC is switched off, I'll monitor idle consumption of Banana Pro alone the next hours and will disconnect network in the afternoon to see whether that makes a difference.

 

 

In the meantime I installed 'rcconf' and disabled a few unnecessary daemons (on our Xenial build eg the following all related to cpufreq behaviour: loadcpufreq, cpufrequtils and ondemand) but to no avail: Consumption of the idle Banana Pro jumps by 5mW over longer periods of time without feeding Orange Pi PC so measurements below 10 or 20 mW aren't possible this way (will check when the 4 NaniPi NEO arrive and I'm able to feed 4 of them since consumption differences can be then divided by 4 afterwards).

 

Disconnecting network from Banana Pro leads to 420mW less consumption reported by PMU immediately (powermeter between wall and PSU reported a drop from 1.5W to 1.0W):

Bildschirmfoto%202016-07-27%20um%2015.13

 

 

But unfortunately the '60 min averaged value' doesn't get more stable. This here are changes of 5mW over 45 minutes that are not related to the subject of testing (since not connected):

 

Bildschirmfoto%202016-07-27%20um%2015.05

 

On the other hand that's even more precise than I hoped since the stuff I want to test out -- see below -- should show higher consumption differences, especially when testing 4 boards in parallel:

  • idling at 912MHz with VDD_CPUX set at 1.1V and 1.3V
  • adjusting DRAM clockspeed in 48 MHz steps
  • running intensive tasks on 1, 2, 3 and 4 cores at different clockspeeds
  • trying to deactivate as much components as possible (Ethernet PHY, WiFi on OPi Lite, CSI, HDMI/Mali and so on -- see the Running H3 boards with minimal consumption thread)
  • maximum consumption at different clockspeeds up to 912MHz (or 1.1V limit) with light and heavy workloads
Link to comment
Share on other sites

In preparation of the NEO boards I changed my test setup a bit. I still use the Banana Pro as 'power source' but the H3 device I test with is now not an OPi PC any more but an Orange Pi Lite (due to same voltage regulator switching VDD_CPUX just between 1.1V and 1.3V). For the moment I will always stay on the lower VDD_CPUX voltage and since our highest DVFS operation point with 1.1V is 912MHz this is the maximum CPU clockspeed I'll test with.

 
I use the AXP209 readouts regarding consumption (simply multiplying the reported values for voltage available and current needed) as averaged values. One averaging the values from last 30 minutes, the other 60 minutes ago for more fine graned measurements, Banana Pro's own consumption (1055mW) will be substracted so I get consumption graphs that should show only the consumption of the powered device(s). Then I took our fex file for Orange Pi Lite and created 4 adoptions of it deactivating more and more stuff to test through how much disabling different stuff might save on consumption.
 
The different fex settings as follows (please keep in mind that our OPi Lite fex already has Ethernet completely disabled):
  1. HDMI and Mali disabled (needs more testing with display enabled later to get the idea how much energy we can save with headless systems)
  2. TWI/SPI (twi0, twi1, spi0) and CSI (csi0) disabled 
  3. USB 1, 2 and 3 (the three host ports) disabled
  4. USB 0 (OTG), 1-Wire, corekeeper disabled
All settings as diff from the previous version:

Settings 1:
323c323
< disp_init_enable = 1
---
> disp_init_enable = 0
337c337
< hdmi_used = 1
---
> hdmi_used = 0
799c799
< mali_used = 1
---
> mali_used = 0

Settings 2:

145c145
< twi_used = 1
---
> twi_used = 0
150c150
< twi_used = 1
---
> twi_used = 0
194c194
< spi_used = 1
---
> spi_used = 0
354c354
< vip_used = 1
---
> vip_used = 0
646c646
< audio_used = 1
---
> audio_used = 0
663,665c663,665
< codec_used = 1
< spdif_used = 1
< hdmi_used = 1
---
> codec_used = 0
> spdif_used = 0
> hdmi_used = 0
698c698
< ir_used = 1
---
> ir_used = 0

Settings 3:

523c523
< usb_used = 1
---
> usb_used = 0
533c533
< usb_used = 1
---
> usb_used = 0
543c543
< usb_used = 1
---
> usb_used = 0
583c583
< wifi_used = 1
---
> wifi_used = 0
587,588c587,588
< wl_reg_on = port:PL07<1><default><default><0>
< wl_host_wake = port:PG10<0><default><default><0>
---
> wl_reg_on = 
> wl_host_wake =
Settings 4:
507c507
< usb_used = 1
---
> usb_used = 0
805c805
< w1_used = 1
---
> w1_used = 0
809c809
< corekeeper_enabled = 1
---
> corekeeper_enabled = 0

 
I tested another setting too (only WiFi disabled) but that makes no difference so I skipped testing with this. First round of tests: OPi Lite idling at 312MHz (4 cores active) and testing through 4 different DRAM clockspeeds (132, 264, 432 and 672 MHz). Each test has to run 4000 seconds to get useful results so it takes quite some time to check through different settings (roughly one day).
 
First round testing combination of 4 settings and 4 DRAM clockspeed differences:
 
Board idling at 312 MHz (x4) with settings 1:
 
672: 950 mW
432: 905 mW (-45 mW)
264: 695 mW (-255 mW)
132: 630 mW (-320 mW)
 
Board idling at 312 MHz (x4) with settings 2:
 
672: 840 mW
432: 795 mW (-45 mW)
264: 590 mW (-250 mW)
132: 540 mW (-300 mW)
 
Board idling at 312 MHz (x4) with settings 3:
 
672: 810 mW
432: 760 mW (-50 mW)
264: 560 mW (-250 mW)
132: 505 mW (-305 mW)
 
Board idling at 312 MHz (x4) with settings 4:
 
672: 715 mW
432: 665 mW (-50 mW)
264: 460 mW (-255 mW)
132: 410 mW (-305 mW)
 
Right, test with 4th settings is postponed since I'm pretty sure with more disabled stuff we're able to stay below the 500mW / 100mA barrier. But since I still have not the slightest idea how precise these measurements based on Banana Pro circuitry and AXP209 readouts are I added now another 'consumer' to the setup.
 
EDIT: Also tested through settings 4 (now 1-Wire, USB OTG and corekeeper also disabled) and consumption even decreased more. The consumption differences with all 4 tested settings are identical (the setup is not precise enough to differentiate reliably at 10mW or below) so IMO it's save to draw the following conclusion regarding consumption saves (on an idle system running at 312 MHz -- more tests with other parameters have to follow!):
 
672 MHz: base consumption
432 MHz: 47.5 mW less
264 MHz: 252.5 mW less
132 MHz: 307.5 mW less
 
I just added a Banana Pi powered by OPi Lite through USB that runs cpuburn-a7 at 1008 MHz (so the somewhat weird setup is now: PSU powering a Banana Pro that functions as 'monitoring PSU' for one OPi Lite that uses now a Banana Pi as consumer on one of its USB ports. I chose the Banana Pi since I can monitor this board indepedently too). AXP209 of Banana Pro reports an increase in consumption by ~4W, the powermeter reports a little bit more and AXP209 of Banana Pi ~3.4W.
 
I'll repeat the first set of tests now to get an idea about linearity of AXP209 measurements. As can be seen above when overall consumption is low walking through the different DRAM clockspeed settings led to relative consumption differences that were quite equal. So I'm curious what will happen now with another 4W consumer added to the setup.
 
TL;DR: Disabling display stuff and reducing DRAM clockspeeds seem to be the best candidates for energy savings when it's about idle consumption (that's important -- 'full load' consumption needs different focus). It needs further investigation whether disabling CSI/camera also helps (switching between both settings saved 100mW) and it's still unclear how precise the test setup is regarding absolute readings and linearity. Maybe after the next round of tests (~20 hours due to the need to use a lot of samples and averaged readouts) a few more conclusions can be drawn.
Link to comment
Share on other sites

Based on the 4 sets of settings above I'm now trying out 10 different settings basing on the last setup above (where nearly everything is disabled, just serial console is working and CPU cores) so we have a pretty clear and low 'baseline' for comparisons.

 
I scripted an automated test setup with 11 different script.bin variants. The 1st is setting 4 from above again, just to check whether same consumption values will be reported. The next 10 settings enable only some hardware parts at a time (1st display stuff, the second USB 0, the next USB 1 and so on) and the next setting disables the last one again to test another one.
 
My /etc/rc.local ensures that OPi Lite idles at 312 MHz cpufreq and 123 MHz DRAM clockspeed for approx. 45 minutes, then exchanges the link to script.bin and initiates a reboot so the next setting will be active:
root@orangepilite:~# grep -v "^#" /etc/rc.local                                                              
echo 312000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 312000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo none >/sys/class/leds/red_led/trigger
echo none >/sys/class/leds/green_led/trigger
echo 132000 >/sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/userspace/set_freq
/usr/local/bin/idle-around.sh &
exit 0

root@orangepilite:~# cat /usr/local/bin/idle-around.sh
#!/bin/bash
TimeToSleep=3000
sleep ${TimeToSleep}
cd /boot
CurrentSetting=$(readlink /boot/script.bin | tr -c -d '[:digit:]')
NextSetting="bin/test_$(( ${CurrentSetting} + 1 )).bin"
if [ -f "${NextSetting}" ]; then
        ln -sf "${NextSetting}" script.bin
        reboot
else
        sed -i '/exit 0/istress -c 1 &' /etc/rc.local
        ln -sf bin/test_1.bin script.bin
        reboot
fi

The 11 different fex settings are converted to bin format and available as /boot/bin/test_1.bin - /boot/bin/test_11.bin and contain the following adjustments:

  1. everything except UART disabled (just like setting 4 above)
  2. disp_init_enable = 1, hdmi_used = 1, mali_used = 1
  3. [usbc0] usb_used = 1
  4. [usbc1] usb_used = 1
  5. [usbc2] usb_used = 1
  6. [usbc3] usb_used = 1
  7. [csi0] vip_used = 1
  8. [audio0] audio_used = 1
  9. [gmac0] gmac_used = 1
  10. [w1_para] w1_used = 1
  11. [corekeeper] corekeeper_enabled = 1
Important: When starting to test H3 thermal stuff last year I realized that reported SoC temperature dropped by ~4°C after 10 minutes when no HDMI display was connected (maybe indication for shutting down display engine when H3 detects none?). Therefore this test happens with a connected and active HDMI display since I want to ensure that setting 2 above (HDMI enabled) will show accurate results and does not get tampered with display recognition (this is stuff for another test).
 
If the first round of tests is done the script will add 'stress -c 1 &' prior to 'exit 0' in /etc/rc.local and restart with setting 1. So we get some more results with some load on the SoC (my approach to use a Banana Pi to add additional 4W consumption failed since numbers differ too much). Each round of tests takes approx. 15 hours so I'll get back to you on monday :)
Link to comment
Share on other sites

Some results (tests still running, 2nd round with added 'stress -c 1' seem to be consistent to first round, the stress call simply adds 115mW to consumption):

 

Bildschirmfoto%202016-07-31%20um%2010.20

 

Results compared individually (in brackets consumption of 2nd run where available) -- baseline consumption is ~400mW:

  1. baseline consumption is ~400mW
  2. disp_init_enable = 1, hdmi_used = 1, mali_used = 1 --> 665mW (775mW)
  3. [usbc0] usb_used = 1 --> 560mW (675mW)
  4. [usbc1] usb_used = 1 --> 560mW (675mW)
  5. [usbc2] usb_used = 1 --> 560mW (675mW)
  6. [usbc3] usb_used = 1 --> 560mW (675mW)
  7. [csi0] vip_used = 1 --> 460 mW (575mW)
  8. [audio0] audio_used = 1 --> 460 mW (575mW)
  9. [gmac0] gmac_used = 1 --> 460mW
  10. [w1_para] w1_used = 1 --> 460mW 
  11. [corekeeper] corekeeper_enabled = 1 --> 570mW
That means that disabling display stuff on a headless system is the most efficient measure (265mW), followed by disabling corekeeper (170mW), followed by disabling USB ports (each 160mW) and then CSI/camera, audio, 1-Wire and networking (each 60mW).
 
Settings 10 and 11 are the most interesting for me since they clearly show that the difference in consumption can simply be caused by driver activity (1-Wire is not a hardware engine but the only difference between enabled/disabled 1-Wire is a driver being active and leading to a few more CPU cycles used).
 
So obviously it helps disabling as much drivers and/or hardware blocks as possible when it's about lowering consumption but we still need further investigation how this stuff behaves. Therefore next round of tests with 912 MHz CPU clockspeed instead of 312 MHz ('race for idle' concept in mind) and USB ports not individually enabled but now together.
Link to comment
Share on other sites

Hi,

 

I found out that on my A20 Cubietruck, the line-in audio input (on the 30pin header) is not capacitor coupled - so the A20 itself isn't either (if you can access the bare pin on your board).

 

However, the 0 reference level is at about +1.5V. 

 

With a shunt and the right resistor network dividing your voltage down, you might thus indeed use the line in for measuring current with good resolution (and good time-wise resolution as well, if wanted).

Link to comment
Share on other sites

Looks like you have a solution using AXP209, but if you are still looking for a simple, cheap, accurate solution that does not need an extra SBC:

 

Have a look at INA219 (at AliExpress costs like $3), great range, low noise

 

measures Voltage and milliamps on the power supply "high side" (= cut the + line from your power supply and screw them to the terminals and connect gnd +3.3v(VCC) and I2C to your SBC) , no need to mess around with an ADC yourself etc, you can read Voltage and milliamps via I2C, no need to calibrate, it is pretty accurate from the factory. ( tried with arduino on 5V, but I guess same on 3,3V)

 

https://binaryfury.wann.net/2014/04/solarbatteryload-power-logging-with-raspberry-pi-and-ina219/

https://learn.adafruit.com/adafruit-ina219-current-sensor-breakout/

check the arduino library, self explaining.

 

As you are not that technical : try this at your own risk, so try first with a cheap SBC ? :-)

Link to comment
Share on other sites

With a shunt and the right resistor network dividing your voltage down, you might thus indeed use the line in for measuring current with good resolution (and good time-wise resolution as well, if wanted).

 

Well, I still lack skills and equipment to do calibration properly. And since all I want to measure now are relative differences of specific settings to compare the efficiency regarding energy consumption I stay with my 'AXP209 only' approach that needs no more hardware and only a lot of patience and a rather stupid methodology (to test the settings one is interested in)

 

Since a week full of tests went by I was able to improve my primitive measuring setup relying simply on reading out voltage available and current used by AXP209, power the device to measure from the A20 board's USB port(s) and use average values to get somehow precise relative measurements. Using 60 min average values it's possible to measure differences as low as 10mW but it should be noted that these numbers are still not calibrated and linearity is unknown.

 

It should also be noted that not every A20/AXP209 board can be used since it depends on schematics how the current value AXP209 provides is generated. On an A20 Lime2 for example a connected SATA disk only adds to the reported consumption when Lime2 is powered through the Mini USB OTG port but not through the DC-IN barrel jack (see post #2 for details). On a pcDuino 3 Nano power provided through USB ports is never added to AXP209 current readout regardless whether the Micro USB jack for DC-IN or USB OTG is used (funny: Even when powering the board through the Micro USB OTG port AXP209 will be fed through DC-IN connection, there are small traces on the PCB feeding the same power source but leading to severe voltage drops when using USB OTG!)

 

Boards known to work are: Banana Pi, Pro and Lime2. It's important to get the consumption of the 'measurement host' as consistent as possible. Therefore I decided to use a fixed cpufreq setting (highest clockspeed possible) and used rcconf to disable the start of all unneeded services, especially loadcpufreq, cpufrequtils and ondemand. And now my /etc/rc.local looks like this:

/usr/local/bin/monitor.sh &
echo none >/sys/class/leds/*green*/trigger 
(sleep 15 ; echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor) &
echo 960000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
exit 0

The monitor.sh script queries AXP209 every ~1.4 seconds, calculates actual consumption based on voltage and current and writes them to a file in /tmp/ dir. And also averages the saved values to provide an average 30 min and 60 min value and writes those to /tmp/consumption and /tmp/consumption_60m. Also 3 min average value of the PMU's internal temperature sensor will be written to /tmp/pmutemp. This is the script code:

#!/bin/bash

while true ; do
	read AC_Voltage </etc/armbianmonitor/datasources/ac_voltage
	read AC_Current </etc/armbianmonitor/datasources/ac_current
	read PMU_Temp </sys/power/axp_pmu/pmu/temp
	tail -n3000 /tmp/lala >/tmp/lala2
	cat /tmp/lala2 >/tmp/lala
	echo -e "$(cat /proc/loadavg | cut -f1 -d' ')\t$(( ${AC_Voltage} * ${AC_Current} / 10000000 ))\t${PMU_Temp}\t$(date)" >>/tmp/lala
	SampleCount=1310
	SampleCount60=$(( ${SampleCount} * 2 ))
	Average_Value=$(tail -n${SampleCount} /tmp/lala | awk '{n++;sum+=$2} END {print n?sum/n:0}')
	Rounded_Value=$(echo ${Average_Value} | awk '{printf("%.2f",$1 / 100)}')
	Average_60=$(tail -n${SampleCount60}  /tmp/lala | awk '{n++;sum+=$2} END {print n?sum/n:0}')
	Rounded_60=$(echo ${Average_60} | awk '{printf("%.2f",$1 / 100)}')
	tail -n180 /tmp/lala | awk '{n++;sum+=$3} END {print n?sum/n:0}' >/tmp/pmutemp
	echo ${Rounded_Value} >/tmp/consumption
	echo ${Rounded_60} >/tmp/consumption_60m
	sleep 1
done

And then some template stuff is needed that's contained in this archive: axp209-monitor.tar.bz2 The contents (mostly symlinks):

 

 

root@bananapro:/# tar tf axp209-monitor.tar.bz2 
etc/armbianmonitor/datasources/ac_current
etc/armbianmonitor/datasources/ac_voltage
etc/armbianmonitor/datasources/battery_charge
etc/armbianmonitor/datasources/battery_charging
etc/armbianmonitor/datasources/battery_connected
etc/armbianmonitor/datasources/battery_current
etc/armbianmonitor/datasources/battery_percent
etc/armbianmonitor/datasources/battery_voltage
etc/armbianmonitor/datasources/charger_current
etc/armbianmonitor/datasources/pmictemp
etc/armbianmonitor/datasources/soctemp
etc/armbianmonitor/datasources/usb_current
etc/armbianmonitor/datasources/usb_voltage
etc/armbianmonitor/templates/cpu_pmic.conf
etc/rpimonitor/data.conf
etc/rpimonitor/template/armbian.conf
usr/local/bin/monitor.sh 

 

 

 

So basically setting up any A20 Banana or Lime2 for this sort of consumption monitoring is just using an Armbian image with vanilla kernel, deactivating services with rcconfig, adding the above stuff to /etc/rc.local, installing RPi-Monitor the usual way (sudo armbianmonitor -r) and then grabbing the archive and:

service rpimonitor stop
cd / && tar xf /path/to/axp209-monitor.tar.bz2
service rpimonitor start

Then check whether RPi-Monitor is working (all the interesting stuff only available on the 'Load / cpufreq / Consumption' statistics page) and let it run without any stuff connected for at least an hour. Then check the 60 min average value on the statistics page whether consumption is reported as 0. If it's above or below you have to adjust the correction factor I now use (1.030W on my Banana Pro) so in case you get 20mW reported you have to adjust lines 151 and 163 in /etc/armbianmonitor/templates/cpu_pmic.conf that they then read

151:dynamic.23.postprocess=sprintf("%.5f", $1/1000 - 1.050)
163:dynamic.25.postprocess=sprintf("%.5f", $1/1000 - 1.050)

In case a negative value is reported you have to adjust the correction value in the other direction (don't forget the necessary 'service rpimonitor restart' afterwards). And then you can connect the device you want to measure (be it an SBC or a disk/SSD for example) but have to take care that switching between different settings requires measuring of at least 45 minutes when the '30 min' average value is precise enough or at leasat 75 min when you want to rely on the '60 min' value.

Link to comment
Share on other sites

Looks like you have a solution using AXP209, but if you are still looking for a simple, cheap, accurate solution that does not need an extra SBC:

 

Have a look at INA219 (at AliExpress costs like $3), great range, low noise

 

Looks great, will most probably add this to the setup to compare readouts. Thanks!

Link to comment
Share on other sites

Small update. In the meantime an INA219 arrived so I will give it a try soon. According to my measurements with various RPi models the AXP209 approach with Banana Pro works pretty well, so I will remain with this setup for consumption optimization process with NanoPi NEO (just arrived)

 

I did one last test with RPi 3 today. Compiling cpuburn-a7 and cpuburn-a53 and trying both out when powered from Banana Pro through Micro USB. This is the graph when running cpuburn-a7:

 

Bildschirmfoto%202016-08-09%20um%2015.03

 

Banana Pro is obviously able to provide up to 5.3W (1060mA @ 5V) through one USB port. On the left I started with cpuburn-a7 then throttling started so I simply added a small 5V fan powered by RPi 3 from GPIO header (therefore adding to total consumption). Result afterwards (explanation here):

root@raspberrypi:/home/pi# vcgencmd get_throttled
throttled=0x20000

0x20000 --> 0000 0000 0010 0000 0000 0000 0000 (only bit 17 is set: "arm frequency capped has occurred")

 

Then I tried out cpuburn-a53 on RPi 3 but this is too heavy at least when powered through Micro USB (same story with Pine64+ back then). Immediately undervoltage occured, VideoCore disabled turbo mode and therefore RPi 3's CPU cores were reduced to 600 MHz clockspeed:

root@raspberrypi:/home/pi# vcgencmd get_throttled
throttled=0x70000

0x70000 --> 0000 0000 0111 0000 0000 0000 0000

 

Bits 16, 17 and 18 set:

  • 16: under-voltage has occurred
  • 17: arm frequency capped has occurred
  • 18: throttling has occurred

(interesting, frequency capping is something different than throttling in Raspberry land)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines