tkaiser Posted July 22, 2016 Posted July 22, 2016 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: Due to being an electrics noob I don't know whether the whole idea is crap or not 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. 1
jernej Posted July 22, 2016 Posted July 22, 2016 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? 1
Tido Posted July 22, 2016 Posted July 22, 2016 I am on the road. So just out of my mind, wouldn't it make more sense with a shunt. Measure it with A20 or Arduino?
zador.blood.stained Posted July 22, 2016 Posted July 22, 2016 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: Due to being an electrics noob I don't know whether the whole idea is crap or not 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. 1
arox Posted July 23, 2016 Posted July 23, 2016 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).
arox Posted July 23, 2016 Posted July 23, 2016 Well bad idee : sound cards seem to have a condo in input and cannot mesure DC.
tkaiser Posted July 25, 2016 Author Posted July 25, 2016 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! 1
tkaiser Posted July 25, 2016 Author Posted July 25, 2016 Audio cards have a 16 bits adc and so must have an A20 card ? 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
zador.blood.stained Posted July 25, 2016 Posted July 25, 2016 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. 1
Tido Posted July 25, 2016 Posted July 25, 2016 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)
zador.blood.stained Posted July 25, 2016 Posted July 25, 2016 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.
Tido Posted July 25, 2016 Posted July 25, 2016 For a high current like 50A $ 15.- not cheap, but you would have this for years.More interesting to me is this information from you about the 5Ampere ACS712 $ 2.-, I found nice documenation: ACS712 Current Sensor User Manual
tkaiser Posted July 25, 2016 Author Posted July 25, 2016 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.
arox Posted July 25, 2016 Posted July 25, 2016 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. (I had tested a MCP3208 (12bits 8 channels) but the two last bits there noise.)
tkaiser Posted July 25, 2016 Author Posted July 25, 2016 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.
tkaiser Posted July 25, 2016 Author Posted July 25, 2016 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. 1
tkaiser Posted July 27, 2016 Author Posted July 27, 2016 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 (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 1
arox Posted July 27, 2016 Posted July 27, 2016 "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)
tkaiser Posted July 27, 2016 Author Posted July 27, 2016 "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
tkaiser Posted July 27, 2016 Author Posted July 27, 2016 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): 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): 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 1
tkaiser Posted July 28, 2016 Author Posted July 28, 2016 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): HDMI and Mali disabled (needs more testing with display enabled later to get the idea how much energy we can save with headless systems) TWI/SPI (twi0, twi1, spi0) and CSI (csi0) disabled USB 1, 2 and 3 (the three host ports) disabled 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. 1
tkaiser Posted July 30, 2016 Author Posted July 30, 2016 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: everything except UART disabled (just like setting 4 above) disp_init_enable = 1, hdmi_used = 1, mali_used = 1 [usbc0] usb_used = 1 [usbc1] usb_used = 1 [usbc2] usb_used = 1 [usbc3] usb_used = 1 [csi0] vip_used = 1 [audio0] audio_used = 1 [gmac0] gmac_used = 1 [w1_para] w1_used = 1 [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
tkaiser Posted July 31, 2016 Author Posted July 31, 2016 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): Results compared individually (in brackets consumption of 2nd run where available) -- baseline consumption is ~400mW: baseline consumption is ~400mW disp_init_enable = 1, hdmi_used = 1, mali_used = 1 --> 665mW (775mW) [usbc0] usb_used = 1 --> 560mW (675mW) [usbc1] usb_used = 1 --> 560mW (675mW) [usbc2] usb_used = 1 --> 560mW (675mW) [usbc3] usb_used = 1 --> 560mW (675mW) [csi0] vip_used = 1 --> 460 mW (575mW) [audio0] audio_used = 1 --> 460 mW (575mW) [gmac0] gmac_used = 1 --> 460mW [w1_para] w1_used = 1 --> 460mW [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.
onno Posted July 31, 2016 Posted July 31, 2016 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).
Set3 Posted July 31, 2016 Posted July 31, 2016 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 ? :-)
tkaiser Posted July 31, 2016 Author Posted July 31, 2016 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.
tkaiser Posted July 31, 2016 Author Posted July 31, 2016 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!
tkaiser Posted August 9, 2016 Author Posted August 9, 2016 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: 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)
Recommended Posts