When looking for options to test the capacity of a power bank, the following two seem to be the most common.
Using a USB power meter.
Using a smartphone app for monitoring charging.
I assume that the latter should be possible with Librem 5. Does there happen to be an application relevant to that purpose? If there is none, is it possible to poll the current and voltage readings?
cat /sys/class/power_supply/tps6598x-source-psy-0-003f/uevent
Does that work for what you want to see?
Some years ago someone did extensive testing on Librem 5 discharging and charging using a USB power meter and an app on the L5 with lots of graphs and photographs but I have not been able to find the threads.
Blog post maybe rather than a topic?
The values of POWER_SUPPLY_CURRENT_MAX and POWER_SUPPLY_VOLTAGE_MAX show the maximum current and voltage negotiated between Librem 5 and the power bank. The real values must be different. I saw a photo with the output of that command on a Librem 5 connected to a power meter in another post.
Maybe “A Humble Librem 5 Daily User Review” or “USB-DCP-5V-1.5A protocol and Librem 5” by @Quarnero ?
There is a blog post from Purism “Charging the Librem 5” but it concerns the battery capacity, not the currents. They do not mention what software they used to get the data and make the graphs.
Yes (although the voltage will usually be relatively uninteresting).
As you say, the pathname given by @amarok above reflects the USB PD negotiation and the negotiated maxima, not the instantaneous values.
Various people have had a hack at it e.g. Librem5 BatteryJuice measurement or Script to Play a Battery Charge Notification or Warning although I personally am using info out of /sys/class/power_supply/max170xx_battery and, yes, I don’t know what script that blog post author was using to collect data.
Maybe my memory is mixing together forum posts and blog posts. But I thought I saw pictures of screens showing graphs with charging and discharging.
Maybe it was about Librem laptops.
You can use LibreOffice to do that i.e. convert a CSV file to a JPG or other image file containing a chart of the data in the CSV file. Unfortunately I do this so infrequently that I can’t remember the details, and so infrequently that I haven’t bothered to write myself a tutorial.
Perhaps it is obvious but the data collection frequency needs to be low enough so as not to materially affect the power consumption that is being measured. A kind of Heisenbug I guess.
I do electronic data collection in my work. You want the testing to be automated, if possible. You can write down a few measurements and learn very little. Or you can allow a computer to collect and store data 24/7 by itself, at lightning speed, including when you sleep. You want to collect data over multiple different test conditions, most prominently, at high and low power draw conditions.
The most basic test configuration would be to test the battery. The circuit between the Librem 5 and its battery needs to be interrupted to get a current measurement. The voltage measurement can be taken accross the two wires between the battery and the phone, without needing to interrupt that circuit. I would measure both voltage and current. At some point if the phone puts a significant enough electrical load stress on the battery, then the voltage might drop some. If that happens, the power always drops also as a result. Since power = voltage x current, a deceptive picture could emerge if we assume that the battery voltage will not drop at some point.
To measure current, the electrical connection to any test instrument has to come from where the battery input goes in to the rest of the phone. It might be worth taping the battery upside down, on the upper back side of the phone. That leaves room to string a short length of wires between any test probes, the battery electrical contacts, and the phone electrical contacts.
Probably the easiest way to measure the power consumption would be to carry a couple of small dataloggers in a project box and just leave them running from when the battery is fully charged, until the battery goes dead. All you would really need to record is current, voltage, and time about once per minute. You can buy adequate dataloggers in a lot of electronics hobbyist stores or as kits that you build yourself. When you have a whole charge cycle worth of data, just upload it to a PC and plot it in something like Ms-Excel, or Matlab. Then build a pivot chart to display anything you want to see about the battery, graphically. You can also run statistics to summarize the overall battery performance.
The FNIRSI FNB48(S) USB power meter is widely available and has data logging capability and there is a project on github that supports it and some other models that is essentially a single python script that prints in ASCII to stdout.
The sample rate is 100/second, but it is easy to write an averaging filter in your language of choice. It also calculates and prints Watt seconds and Amp seconds (which should be subsampled rather than averaged).
Negative voltages and currents are not supported by the device, so reverse currents and negative voltages should be avoided. USB breakout gadgets can be used to monitor non-USB voltage/current that meet voltage/current restrictions.
You won’t have negative voltage if you don’t measure the phone battery while charging it. Current should only flow in one direction. Sampling over time is only needed to get a picture of power consumption over time in this case. The whole process is very slow and doesn’t change much over a period of one second. At work, I have built test setups that collected data at up to 200 Ms/S. That’s mega samples per second. That was to test a 12-bit ADC (analog to digital converter) at maximum throughput rate using a 12-bit parallel data bus. With the high reference at 3.3V and the low reference at Ground, that’s roughly 806uV per step-up on a ramp between 0V and 3.3V (4096 steps). The point is that you only need a high sampling speed when things are changing both rapidly and significantly over very short periods of time. Interpolation when measuring something like a battery can cover between very slow changes without missing anything significant. I would set the sample at a rate in that case of one sample per second. If you’re going to store and plot data over a period of around twenty-four hours without needing expensive equipment, that’ll probably do. Inexpensive datalogging meters would work for that job if you want to keep them attached to the phone during the entirity of the data collection period.
Also, if you’re going to post-process the data in Ms-Excel, you are limited to roughly 500,000 rows of data, period. Ms-Excel can’t hold more data than that. At 100 samples/Second, you’ll get roughly 10x that much data over a 24-hour period. If you can’t slow down the datalogger, then you’ll need to find a slower datalogger.
Seeing as the discussion has gone off in a different direction, I should clarify that when I wrote
I of course meant … if you are collecting the data on the phone itself e.g. a cron job that wakes up every X minutes and samples e.g. current now, voltage now and charge level.
That should work if the measurements are reasonably accurate. Your script will still need to record those values in a log file. But your way is much easier and avoids messing with additional hardware. My only concern is that you’ll need a way to validate the data itself. Maybe if you let the phone stay on until the battery dies and then see if your measured mAh through a full discharge cycle matches the battery specification of mAh. Let us know how it goes.
An aside, just to “enhance” accuracy:
According to Microsoft’s Support site, Excel’s maximum number of lines is 1,048,576.
Which, admittedly, may still not be enough, if:
Same goes for LibreOffice Calc.
Apparently LibreOffice Base (and whatever Microsoft’s equivalent is called) can handle greater data sets, which can be manipulated and reduced for export to Calc or Excel.
I think you are right about about the increase in Ms-Excel’s capacity being something like just over a million lines now in the later versions of Excel. I used to build these macros to import and convert a 200 to 500 large text files (4096 lines each) full of data in to one big Excel spreadsheet, by stacking all of the text files one on top of the other, in to one Excel file, before building the charts and tables. I learned several years ago that if I start with too much data, that the macros get only part way through the execution and then they crash. Some of them can take around two hours or more to complete the post-processing, even with the screen updating turned off. I would come back an hour later and see that my macro crashed after running for over an hour before hitting Excel’s limit on number of lines. The only fix if you exceed Excel’s limit on number of lines of data is to break the data in to smaller portions and to reprocess each portion separately in to a different spreadsheet. When you’re dealing with that much data, there is little you can even do manually. Even just scrolling all the way down manually through hundreds of thousands of lines can easily take half an hour. If you leave screen updating turned on when you run a large macro with a lot of data, the macro might start out processing one text file per second at first. Then as it’s nearing the end of its hundredth file, each text file may take around five to ten seconds to process as the hardware and software resources struggle to fill that Excel file to the limit. Whereas if you write the program in Perl, the same amount of data will post process instantly. Even opening an Excel file full of that much data can take a ten to twenty second wait, which is probably why Microsoft limits the number of lines. So my point is that when using automated data collection, smaller amounts of data are better where possible, as long as you can still get a good enough resolution.
Nope. As I wrote, it is trivial to write an averaging (or less desirable, subsampling,) filter.
As to excel, everyone that cares about floating point accuracy should be familiar with How Futile are Mindless Assessments of Roundoff in Floating-Point Computation ? https://people.eecs.berkeley.edu/~wkahan/Mindless.pdf by William Kahan, who is essentially the father of IEEE 754-1985 and IEEE 854-1987.
That’s per sheet though (allegedly). So you may be able to push things further by using multiple sheets in a single workbook.
But for that volume of data I wouldn’t use either spreadsheet software product.
Maybe that’s Microsoft Access.
That’s it. Been a long time since I had to use it.
Thank you for all the great suggestions!
A USB power data logger is something I should include on my shopping list.
/sys/class/power_supply/ seems to contain directories for three devices usually:
bq25890-charger-0 for an on-board BQ25890 charger that I would expect to be responsible for charging the battery and distributing power between the phone and the battery;max170xx_battery for a MAX170xx battery gauge and monitor that should report the state of the Librem 5 battery;tps6598x-source-psy-0-003f for a TPS6598x power delivery controller that I would expect to be responsible for negotiating the maximum current and voltage allowed to pass over USB.Only the first two seem to provide momentary current values. However, the values fluctuate dramatically, so I am not sure whether it makes sense to try to use those values to calculate the provided charge, unless I am going to collect them faster than they fluctuate. The battery additionally provides an average current but it also fluctuates quickly.
Surprisingly, the charger current is slightly lower than the battery current most of the time with similar voltage, so I am not sure what the values mean. The charger current becomes zero when there is no external power supply or the battery is full and not charging. Instead, I expected the current to continue after the battery was charged. The battery current is positive when charged and negative when discharged. But it should not account for the charge being drawn by the phone itself.
I tried logging the battery capacity POWER_SUPPLY_CHARGE_NOW when starting and finishing charging with the power bank. I turned off the phone when charging to minimize the losses due to the phone’s operation. I have tested two power banks this way so far. In both cases, the calculations showed a charge of half of their rated capacities delivered to the phone’s battery. I am unsure how to interpret the results. Could it be that 25% are lost by the power bank and another 25% lost by the phone when charging the battery due to energy conversion or for some other reason? Would it make sense?