tkaiser Posted January 14, 2016 Author Posted January 14, 2016 Here my axp209_cpu_pmu_temp.conf http://pastebin.com/SM9exzC8 The board is powered through the 5V DC-IN and the battery is always connected to the board. Thx. As already written this is the 'wrong' or let's better say old/insufficient template (the new 'axp209_cpu_pmu_temp_r1.conf' now). This template should only be used when you insert 5V DC-IN through the battery connector (in this mode or more precisely when voltage on the battery connector exceeds 4.2V then AXP209 disabled the battery charger but unfortunately provides no information about the voltage through sysfs). Providing DC-IN through the battery connector is only necessary with the crappy Lamobo R1 since there the 'engineers' used the crappy micro USB connector for DC-IN (limited maximum current, voltage drops due to crappy cables --> all sorts of stability problems). On Olimex boards with a sane barrel plug and an additional noise free DC-IN design this is never needed! The old template should only be used for the special 'Lamobo R1 fed through battery connector' situation (but when no battery is in use it still works). For situations with a connected battery please use the new template, either by replacing the contents with http://pastebin.com/DxbbZ8xtor by following the installation instructions. What happened with the wrong template in your case yesterday (a bit hard to tell know since the screenshot isn't available any longer)? For unknown reasons DC-In voltage dropped below 5.0V and it seems the AXP209 PMU compensated this through battery. Since the old template always multiplied the current taken through the battery connector with 5 (volts) you got this strange increase in consumption. With the new template this shouldn't happen.
PaceyIV Posted January 14, 2016 Posted January 14, 2016 I replace the file with the new one, then I restart the rpimonitor. I've got an error about rdd file that were invalid so I delete ac_* usb_* battery_* total_comsumpion.rdd from /var/lib/rpimonitor/stat but now I've got this problem http://picpaste.com/Immagine-1PBjDNbs.png How can I fix?
tkaiser Posted January 14, 2016 Author Posted January 14, 2016 How can I fix? No available data sources at all looks to me like rpimonitord (the daemon tasks that collects data) isn't running. You should try to stop/start rpimonitor again. In case you deleted databases while rpimonitord was running this might also be the culprit...
PaceyIV Posted January 14, 2016 Posted January 14, 2016 I stop the rpimonitor service, delete all the rrd file in /var/lib/rpimonitor/stat (I keep empty.rrd), I start again the rpimonitor service and I wait at least 10 seconds. I've get again some rrd file but not rrd file for the "variable" defined in your new config and I don't understand why. The two config file are the same! you only add the battery_current.
PaceyIV Posted January 14, 2016 Posted January 14, 2016 I fix. Only a Windows - Linux pastle problem.
tkaiser Posted January 15, 2016 Author Posted January 15, 2016 I fix. Only a Windows - Linux pastle problem. Good to know, thx for the feedback. Now you owe me a screenshot and /tmp/battery-stats.txt Could you please provide the statistic graphs for both "Load / cpufreq / consumption" and "PMU current / voltage" for the following situation. For step 4 and 5 you'll also need another PSU and a Mini-USB cable -- do you have one lying around? Prerequisits: report-battery-stats.sh script stored somewhere and tested shortly (will write battery stats every 5 seconds to /tmp/battery-stats.txt Connected battery that is charged 50% or above (would be good if one charge/discharge loop already happened so it will be calibrated) Steps: start report-battery-stats.sh disconnect DC-IN wait 60 seconds connect 2nd PSU to Mini-USB OTG port wait 60 seconds connect DC-IN back wait 60 seconds stop report-battery-stats.sh with [ctrl]-[c] and put the contents of /tmp/battery-stats.txt on pastebin.com -- I will add then battery support to RPI-Monitor for AXP209. Please get back to us with pastebin.com link and screenshots. Thx in advance!
PaceyIV Posted January 16, 2016 Posted January 16, 2016 Here you can see the full discharge of the battery. And here the full recharge Here you have the zip of rrd files and your battery-stats.txt report. (I add echo "$(date +"%D %H:%M:%S")" >>/tmp/battery-stats.txt to your script). https://drive.google.com/folderview?id=0BzF5qrRdBNDbTDdMNWxCSkZKMGM&usp=sharing Tomorrow I'm going to wait to discharge again the battery to 50 % and then I'm going to do your tests. I'm using a modified version of axp209_cpu_pmu_temp.conf I've added the graph of battery_capacity http://pastebin.com/J9vdVWZQ The compute of consumption is wrong. During the discharge the current increase to compensate the the voltage decrease: the power should be the same!
tkaiser Posted January 16, 2016 Author Posted January 16, 2016 (edited) The compute of consumption is wrong. During the discharge the current increase to compensate the the voltage decrease: the power should be the same! Yes, currently it's wrong when running on battery. I just ordered the large Olimex battery and will then look into it at the end of next week. BTW: My Lime2 didn't survive a switch between DC-IN and USB OTG (no battery connected). Now it doesn't even reboot properly. Will have a look into it tomorrow. Now it's time for a few beers Edited January 17, 2016 by tkaiser Not => Now ;) Gut! 1
zador.blood.stained Posted January 16, 2016 Posted January 16, 2016 (edited) BTW: My Lime2 didn't survive a switch between DC-IN and USB OTG (no battery connected). Now it even reboots properly. Will have a look into it tomorrow. Now it's time for a few beers There are voltage and current limits for powering from OTG bus by default, this may be the cause. Edit: Voltage Limiting/Current Limiting mode and Direct Mode In order not to affect the USB communication, VBUS is always working under Voltage-Limit mode by default. In this mode, AXP209 ensures that VBUS voltage remains above a configurable reference voltage VHOLD which can meet the USB specification. The default VHOLD is 4.4V, adjustable in Reg30H [5:3] register. If the system has limit on current obtained from USB VBUS, a current-limit mode is provided (See REG30H[1] register), with 900mA/500mA/100mA (Reg30H [0]) selectable. If the system just utilizes the USB for power supply rather than communication, or the USB power adapter is utilized, AXP209 can be set to “VBUS Direct Mode†by modifying register REG30H[6], and then AXP202 will give priority to the application power demand. When the drive ability of USB Host is insufficient or system power consumption is large then the VBUS voltage is lower than VHOLD, AXP202 will release IRQ to indicate the weak power supply ability of Host VBUS, which may affect USB communication, and then Host software will follow up. Edited January 16, 2016 by wildcat_paris Now! It is time to moderate drinking "a few beers"
tkaiser Posted January 17, 2016 Author Posted January 17, 2016 There are voltage and current limits for powering from OTG bus by default, this may be the cause. Voltage Limiting/Current Limiting mode and Direct Mode In order not to affect the USB communication, VBUS is always working under Voltage-Limit mode by default. In this mode, AXP209 ensures that VBUS voltage remains above a configurable reference voltage VHOLD which can meet the USB specification. The default VHOLD is 4.4V, adjustable in Reg30H [5:3] register. If the system has limit on current obtained from USB VBUS, a current-limit mode is provided (See REG30H[1] register), with 900mA/500mA/100mA (Reg30H [0]) selectable. If the system just utilizes the USB for power supply rather than communication, or the USB power adapter is utilized, AXP209 can be set to “VBUS Direct Mode†by modifying register REG30H[6], and then AXP202 will give priority to the application power demand. When the drive ability of USB Host is insufficient or system power consumption is large then the VBUS voltage is lower than VHOLD, AXP202 will release IRQ to indicate the weak power supply ability of Host VBUS, which may affect USB communication, and then Host software will follow up. Thx, that might be the reason. I ran also an iozone benchmark on an attached SSD while disconnecting DC-IN. BTW: The current values I got seemed a bit off. But I'll have a closer look into it later and will get back to you in the thread where it belongs to.
PaceyIV Posted January 17, 2016 Posted January 17, 2016 Here the test. Battery always connected. 1. 60 seconds (from 20:13): 5 Volt on DC-IN 1. 60 seconds (from 20:14): no power, only battery 2. 60 seconds (from 20.15): 5 Volt on Mini-USB OTG port 3. 60 seconds (from 20.16): 5 Volt on DC-IN AND 5 Volt on Mini-USB OTG port 4. 60 seconds (from 20:17): 5 Volt on DC-IN The battery report is here: http://pastebin.com/9vgC5V8m
tkaiser Posted January 22, 2016 Author Posted January 22, 2016 Here the test. Battery always connected. Thx, in the meantime my battery arrived and I had a look (currently using Zador's latest axp209 mainline sysfs interface patches). Now it's also obvious to me that the consumption calculation I used before is simply crap when using a real battery (and not the 'fix Lamobo R1 power problems' operational mode is used). Will have a look into it the next days... 1
chradev Posted March 28, 2016 Posted March 28, 2016 Hi to All, I am testing battery (6600 mAh from Olimex) usage on Lime 2 using RPI Monitor customized for A20 boards. While tuning charge and discharge times I have to modify lime2.bin file to change battery parameters. To get optimal battery control the following parameters have to be changed: pmu_battery_cap = 6600 pmu_init_chgcur = 500 pmu_earlysuspend_chgcur = 700 pmu_suspend_chgcur = 1000 pmu_resume_chgcur = 500 pmu_shutdown_chgcur = 1000 These parameters make battery to be charged with 630 mA witch is good for its capacity. Unfortunately, increasing the charge current the current drawn from DC IN also increases. For example in may case (Lime 2 + USB WiFi + USB LAN + SSD) the current drawn from DS IN is 1A @ 5.2V (measured at the source). Slightly higher voltage was setup for having 5V measured in PMU. It slightly decrease the current drawn from DC IN. I get into following problems: PMU temperature rises up to 50+ degrees Celsius at battery charge cycle (need cooling). AC-DC adapter from Olimex (1A @ 5V / 5W) become useless because these are its maximal parameters. On the other hand working from image installed in NAND there is no lime2.bin file to change battery parameters. Where battery parameters can be changed in case of booting from NAND? Best regards Chris
Igor Posted March 28, 2016 Posted March 28, 2016 On the other hand working from image installed in NAND there is no lime2.bin file to change battery parameters. Where battery parameters can be changed in case of booting from NAND? NAND is having different boot process ... what you look is in /boot/script.bin (on first NAND partition).
chradev Posted March 28, 2016 Posted March 28, 2016 Thanks Igor, I know that and I know also that uboot and kernel expect internal bootloader to initialize the SoC. Unfortunately, it will be very basic initialization could be done from there. My question is how and where to setup battery parameters (and others if needed) like in fex/bin files. Is all /boot/bin/* files and link to one to be used is copied from SD card to NAND in installation process and used later on at boot one?
zador.blood.stained Posted March 28, 2016 Posted March 28, 2016 My question is how and where to setup battery parameters (and others if needed) like in fex/bin files. Is all /boot/bin/* files and link to one to be used is copied from SD card to NAND in installation process and used later on at boot one? If you are booting from NAND without SD card, then "compiled" fex file that contains battery settings (script.bin) is loaded from first NAND partition. If first NAND partition is mounted to /boot, then you need to edit (convert bin->fex, edit fex file, convert fex->bin) /boot/script.bin
chradev Posted March 28, 2016 Posted March 28, 2016 Thanks Zador, I suppose that /boot/script.bin is of course appropriate one from SD card image. So the modifications done at image build process and later on written to SD will be finally copied to NAND as /boot.script.bin.
chradev Posted March 28, 2016 Posted March 28, 2016 Hi to All, While testing battery usage with Lime 2 I noticed some strange behavior of battery capacity value coming from source=/sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20-supplyer.28/power_supply/battery/capacity The curve is highly none linear in discharge mode. In the beginning it falls with 15-20% per hour and at the end last percentages lasts too much. Even at battery voltage slightly less than 3.6V battery capacity goes to zero but the boards continues to draw 750mA from battery and to work in normal mode. As I know battery discharge has to be controlled precisely not allowing battery voltage to fall to the values less than 3V even 3.3 for assurance. Is there something more to adjust and where for getting right battery charge level and properly shutdown the system? For example there are pmu_bat_para1 ... 16 assigned with valued from 0 to 100 in lime2.fex file. Are they or other parameters in lime2.fex file related to to above issue?
tkaiser Posted March 28, 2016 Author Posted March 28, 2016 The curve is highly none linear in discharge mode. It looks somewhat like this? http://forum.armbian.com/index.php/topic/611-wip-axp209-mainline-sysfs-interface/?p=4604
chradev Posted March 28, 2016 Posted March 28, 2016 Yes except that it is zero more then hour while battery voltage is more than 3.4V and the board is still working.
zador.blood.stained Posted March 28, 2016 Posted March 28, 2016 Yes except that it is zero more then hour while battery voltage is more than 3.4V and the board is still working. It was discussed in "[WiP] axp209 mainline sysfs interface" topic. Default OCV-capacity look like this, but you can change it in fex file (legacy kernel) or with "battery calibration program" (mainline kernel)
chradev Posted March 29, 2016 Posted March 29, 2016 Thanks Zador, There you are full battery cycle (discharge / charge) inc. battery capacity graph: (rejected to add image - Why?) As you can see LiPo Capacity (%) looks like the OCV-capacity graph in the attached file. Maybe I should disable translation or enter linear graph values. How to do it?
zador.blood.stained Posted March 29, 2016 Posted March 29, 2016 For lime2 (and legacy kernel) you need to edit these values in lime2.fex (and recompile it to your script.bin/lime2.bin). Check comments here for OCV levels for these entries.
chradev Posted March 29, 2016 Posted March 29, 2016 Thanks Zador, I will test it. While tested devices for measurement of total power consumption (incl. one not passed via PMU) found useful to power Lime 2 via USB when all power is measured by PMU. On the other hand if the board is powered via DC-IN and voltage is under 4.5V all current is also measured by PMU which is good to track total power consumed from the source. There you are a few links with useful and cheap power measurement staff: Dual LED Red + Blue Display Digital Voltmeter Ammeter DC 3.5-28V 3A OLED USB 3.0 Charger Capacity power Current Voltage Detector Tester Meter Mobile DC-DC Voltage Buck Converter 5-30V to 3V 5V 12V 24V Step-down CC/CV Power Module
chradev Posted March 31, 2016 Posted March 31, 2016 Hi to All, Following Zador recommendation: For lime2 (and legacy kernel) you need to edit these values in lime2.fex (and recompile it to your script.bin/lime2.bin). Check comments here for OCV levels for these entries. After re-calculation of OCV levels for Olimex 6600 mAh LiPo battery (connected to Lime 2) as follows: pmu_bat_para1 = 0 pmu_bat_para2 = 0 pmu_bat_para3 = 4 pmu_bat_para4 = 28 pmu_bat_para5 = 46 pmu_bat_para6 = 51 pmu_bat_para7 = 56 pmu_bat_para8 = 61 pmu_bat_para9 = 66 pmu_bat_para10 = 69 pmu_bat_para11 = 72 pmu_bat_para12 = 76 pmu_bat_para13 = 83 pmu_bat_para14 = 90 pmu_bat_para15 = 97 pmu_bat_para16 = 100 battery capacity (%) become almost liner. Charge and discharge cycles can be seen in attached files (more current in the beginning is thanks to USB-LAN adapter). The little none linearity at the end of the charge time can be decreased by slightly increasing pmu_bat_para2/3 (for example to 2/8% respectively). Unfortunately, there is no way to get better linearity (like in proposed by tkaizer calculation method) but advantage is the luck of additional processing. In my opinion linearity of the battery capacity in case of OCV table adjustment is enough especially if only percentage will be shown as status. Best regards Chris
chradev Posted April 4, 2016 Posted April 4, 2016 Hi Guys, I would like to ask for a help about new Olimex'A20-Olinuxino-Lime2-eMMC (Lime2 HW rev. E with eMMC option). I try to make use of eMMC connected as MMC2. Some details can be seen here and here. In my opinion Armbian with both legacy and mainline kernel and latest U-Boot can satisfy my need to use eMMC as a fail-over in system booted from MMC0, USB or SATA. Solution based on mainline kernel is preferable for me. On the other hand extending Armbian to use new eMMC option in Lime2 board will be of wider interest. Unfortunately, my experience is quite limited to solve this issue alone so, please, help me. Best regards Chris
spacebass Posted April 7, 2016 Posted April 7, 2016 Here’s a fresh install of RPi-Monitor on a Cubietruck running Legacy Jessie server (boot from mSD, / on SATA). Most things look OK to me except for the Network stats. I’ve transferred approximately 100GBs to the Cubietruck from my file servers @tk if you need any specific info, let me know.
tkaiser Posted April 9, 2016 Author Posted April 9, 2016 Most things look OK to me except for the Network stats. I’ve transferred approximately 100GBs to the Cubietruck from my file servers @tk if you need any specific info, let me know. Nope, no info needed. I know that network reporting is wrong but I do not care since these specific graphs are worthless anyway (in the sense of: what to do with it? What to analyse?). In case you want to improve this feel free to come up with suggestions. You find countless improvements for this stuff on RPi-Monitor website and since RPi-Monitor is adjustable without any limits you can tweak this to your needs.
spacebass Posted April 10, 2016 Posted April 10, 2016 Roger! Thought you were still collecting info for your research. I don't need full-blown network stats on RPimonitor either, I've got a propper collectd/rrd setup on my router
chradev Posted April 12, 2016 Posted April 12, 2016 Hi to All, I try to run RPI Monitor and A20 & AXP209 support in Armbian next (kernel 4.4.6) on A20-Olinuxino-Lime2-eMMC but without success. /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh prints error from line 107 because PMUTemp is empty (even if lm-sensors is installed). Unfortunately, I could not understand what should be done to succeed at: # check whether PMU value could be read before if [ "X${PMUTemp}" = "X" ]; then # Maybe the patches from http://sunxi.montjoie.ovh are applied and lm-sensors installed PMUTemp=$(sensors | awk -F" " '/CHIP: / {printf ("%0.0f",$2*10); }') fi BTW is there something newer to install instead of thread the work is in progress so I can try to test in cease of some guidance. Best regards Chris
Recommended Posts