Jump to content
  • 0

Testers wanted: sunxi adjustments for RPi-Monitor


tkaiser
 Share

Question

Hi,

 

I started to adjust RPi-Monitor's settings for the Banana Pi a while ago and reworked the whole stuff in the meantime (since it was focused on Banana Pi and some parts were too quick&dirty -- especially temp file handling of the temperature daemon). I also adjusted the consumption measurements for Lamobo R1 since it's the best idea to power the board through the LiPo battery connector -- for this case you need the axp209_cpu_pmu_temp_r1.conf template!

 

Here you find an installation overview for RPi-Monitor (takes you 3 minutes if you are able to copy&paste): http://rpi-experiences.blogspot.fr/p/rpi-monitor-installation.html

 

Here you find what's different on sunxi: https://github.com/ThomasKaiser/RPi-Monitor/blob/master/README_sunxi.md

 

Here you find the adjustments: http://kaiser-edv.de/downloads/sunxi-monitor.tar.gz (MD5: 6822bcd7fe5cb2403eed9747e7cfff52. It will take you additional 3 minutes to 'install' -- see below)

 

The archive contains the following:

/etc/rpimonitor/data.conf
/etc/rpimonitor/template/sunxi_axp209.conf
/etc/rpimonitor/template/axp209_cpu_pmu_temp.conf
/etc/rpimonitor/template/axp209_cpu_pmu_temp_r1.conf
/usr/share/rpimonitor/scripts/sunxi_tp_temp
/usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh

Contents: data.conf is relinked to template/sunxi_axp209.conf which includes all the basic RPi-Monitor stuff but uses template/axp209_cpu_pmu_temp.conf for all the A10/A20/AXP209 specific stuff since this differs totally from Raspberry Pi. The sunxi_tp_temp binary is able to read out A20's temperature and sunxi-temp-daemon.sh is a script I rewrote from scratch since it's not possible to collect thermal data from disks/SoC under heavy load (RPi-Monitor isn't that patient waiting for external ressources to respond. So I created a daemon that collects thermal data into 3 temporary files and redirect RPi-Monitor to read from there).

 

WARNING: Most of the sunxi stuff works only with kernel 3.4.x since in mainline the I2C/sysfs interface to the AXP209 PMU disappeared.

 

Installation: Install RPi-Monitor as outlined in the link above, then stop it, untar the archive from /, ensure that /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh will be running and start rpimonitor again.

# become root eg. by "sudo su -"
service rpimonitor stop
cd / && tar -xzf /path/to/sunxi-monitor.tar.gz
nohup /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh &
service rpimonitor start

To let the collection of thermal data survive a reboot it's a good idea to add "/usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh &" prior to "exit 0" to /etc/rc.local

 

Bildschirmfoto%202015-07-29%20um%2009.30

 

Bildschirmfoto%202015-07-29%20um%2009.12

 

Bildschirmfoto%202015-07-29%20um%2009.26

 

Bildschirmfoto%202015-07-29%20um%2009.26

Link to comment
Share on other sites

Recommended Posts

Armbian is a community driven open source project. Do you like to contribute your code?

  • 0

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...

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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:

  1. start report-battery-stats.sh
  2. disconnect DC-IN
  3. wait 60 seconds
  4. connect 2nd PSU to Mini-USB OTG port
  5. wait 60 seconds
  6. connect DC-IN back
  7. wait 60 seconds
  8. 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!

Link to comment
Share on other sites

  • 0

Here you can see the full discharge of the battery.

 

 

 

AIVFp.jpg

 

imd0U.jpg

 

TtCm3.jpg

 

 

 

And here the full recharge

 

 

 

BPkru.jpg

DjJZB.jpg

fJKkG.jpg

 

 

 

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!

Link to comment
Share on other sites

  • 0

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 by tkaiser
Not => Now ;) Gut!
Link to comment
Share on other sites

  • 0

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 by wildcat_paris
Now! It is time to moderate drinking "a few beers"
Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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

 

 

 

YLqRQ.jpg

 

QOpvQ.jpg

 

oBqy7.jpg

 

 

Link to comment
Share on other sites

  • 0

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...

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0

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).

Link to comment
Share on other sites

  • 0

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?

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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?

Link to comment
Share on other sites

  • 0

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)

Link to comment
Share on other sites

  • 0

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:

Link to comment
Share on other sites

  • 0

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

post-904-0-29684700-1459463002_thumb.jpg

post-904-0-93312600-1459463016_thumb.jpg

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0

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  :unsure:

 
@tk if you need any specific info, let me know.
 
MvhuHer.png
qyLbLtk.png
 
0lLgZ1d.png
Link to comment
Share on other sites

  • 0

Most things look OK to me except for the Network stats. I’ve transferred approximately 100GBs to the Cubietruck from my file servers  :unsure:

 
@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.

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0

You can take armbianmonitor-daemon and these three templates:

And then rely on the discussions in these two threads:

to further improve this stuff. I won't look into it for at least a month or maybe even more.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...