Jump to content

Testers wanted: sunxi adjustments for RPi-Monitor


tkaiser

Recommended Posts

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.

Link to comment
Share on other sites

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

post-904-0-94945100-1459463107_thumb.jpg

Link to comment
Share on other sites

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

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

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

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

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

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

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

Important Information

Terms of Use - Privacy Policy - Guidelines