I will ask now since I know others will ask you eventually - can you tell us about battery life?
2 Likes
I’ve not actively tested it, but I can tell you it is only a few hours right now. I would assume 6 to 8 with the baseband and camrea/mic off. I can tell you I’ve passed out without with it at full charge and on that setting it was fully drained before I woke up. I can test it out tommorow, but seeing the progress they have made on it already I’d assume it will be longer before evergreen comes out.
1 Like
The most notable thing I’ve had to deal with so far has been the fact I had to use SCP to send files to it after setting up the SSH server myself. Not the worst thing I’ve had to do to send files onto a system before, but I was fairly shocked they have not gotten MTP working yet as far as I can tell.
1 Like
I’ve set up a shell script to print the battery %, the battery life in the less human readable form that it has, and the time in in a CVS file to share with you all, I’ve had it running a few hours with it as a cron job that runs every minute. Currently it’s at idle in lockdown mode. I’ll keep letting it do that for the next few hours then post the file here. I’ll likely collect it regularly like this for the next few weeks on different setting to see the current state of the battery. If you’ed like I can post the shell script when I post the CVS file.
EDIT: https://github.com/dylanlester-librem/Librem5-battery-data I had to use a github account I made on the fly to host the files as I could not upload them here directly.
13 Likes
Thanks for all the updates dylanlesterpvcs, it is very much appreciated, please keep them coming.
Connecting back to separate topic (Planning ahead: what and how to report on L5 when the time comes) close to this: could it be possible to add a column or two to that script for more info? Load average would give some indication how much use device is getting (for instance cat /proc/loadavg , all five or just the first and fourth) selected in the script. And maybe data transferred (total cumulative up/down or individually by method/radio)?
General thoughts on this continued in the separate data gathering thread…
@dylanlesterpvcs,
If you have a scale, I would appreciate it if you could weigh Dogwood. Birch and Chestnut weighed 230 grams, but Dogwood has a higher-capacity battery and added a back metal plate for better heat dissipation and a plastic plate over the M.2 cards, so I expect that the weight has changed.
It would be cool if you could post the output from these commands:
sudo dmesg
sudo apt install lshw
sudo lshw
sudo apt install sysbench
sysbench --test=cpu --threads=1 run
sysbench --test=cpu --threads=4 run
sysbench --test=memory run
sysbench --test=fileio --file-test-mode=seqwr run
sudo apt install lm-sensors
sensors
3 Likes
@amosbatto could not get sysbench even installed as it could not find it in the repos, as for lm-sensors, it returned an error when I tried to run it. THe output from dmesg and lshw along with anything that lm-sensors might have spit out in a file called request.md it is really a txt file. https://github.com/dylanlester-librem/Librem5-battery-data
1 Like
Thanks @dylanlesterpvcs.
It looks like lshw shows the temperature info, so lm-sensors isn’t needed.
I’m surprised that there is no sysbench package. Is there a hardinfo package? That has some basic benchmarking.
Looking at your dmesg log, I’m struck by how long it takes to bring up the Wi-Fi (11.6 seconds) and the cellular modem (18.9 seconds), but everything else seems to boot really fast. It looks like the GNSS still isn’t being used.
2 Likes
Hi @Kyle_Rankin ! Just as a follow up to your last post, do you have a sense of timing for the publication of that next Evergreen update? Thanks!
1 Like
I’m working on it! 
10 Likes
A graph from @dylanlesterpvcs data, battery charge overlaid with CPU load averages over 400 minutes. Shows a quick drop after some use and I quess there was some activity after you plugged it in to recharge…?
3 Likes
I am convinced that when the Librem5 is finally shipped, sales will increase. Many people wait for it to be on the market to buy it.
Regards
1 Like
The time in seconds shows the gaps when I had the phone off to charge etc. if you graph the second column vs the time data in seconds itself you’ll see the raw battery data the phone sees I’ll be it at one minute intervals. The data is appended every minute the phone is on. It has gaps like that one you noticed any time I turn off the phone. those will be very clear if you graph the data vs the time in seconds. I’ll be making a graph myself for all of you to see in a few minutes that should give you a better idea of how long the batter lasts.
I’ll check it to see if it has a Hardinfo package in a few hours.
The rest of the data set’s battery vs time can be seen in the same place as the raw data itself. I’ll clear this up a bit as to why my graphs are smoother then yours for the battery data, I’m using the raw battery data in column two, it is in the form of 3,000,000 as 100% and 0 as 0% so to get the raw percentage I divided it by 30000. I also used the Unix time stamp in row three to find the relative time since the start of each set. In set three you can see when I got your request Implemented at 8 minutes in to the boot. Data set four was all active time as it was when I was working on @amosbatto 's request.
Edit: as for the rapid drop in the middle of of set number 3, I’m fairly sure that was me rebooting the phone. The active periods are never that steep. You can see active periods in the sets as flat parts in the first set and, as slight dips in the rest. Set four is the best example of an active period due to the fact I was engaged in running the screen, the wifi, bluetooth for a keyboard, and running fairly intensive programs all at the same time. At no point have I had the baceband on for longer then a few second, and I keep the microphone and camera always off as well.
1 Like
Is the screen on this entire time, and is it at 100% brightness?
Around 85% brightness, and yes it was on the entire time during data set four. I was typing commands in terminal and using the web browser during it.
Just checked, yes there is a package for it, if you’ed like me to install it and to use any commands from the tools it has just say so.
Ah, that explains it - gaps. It did seem odd without context. Thanks.
I’m thinking up new test protocols, which you may or may not want to do, but would be more thorough:
1A (“idling”) - A “baseline” dataset, with everything on (modems, wireless, BT - but no useage), 100% screen brightness (on all the time), idling: let it go from battery from 100% to 0 (shutdown). Only the data logging script running.
1B (“idling with more realistic screen”) - Same as 1A, but screen at some lesser brightness that looks usable (75-85%?).
2A (“idling securely”) - Same as 1A, but HW killed with switches.
2B (“idling securely with more realistic screen”) - Same as 1B, but HW killed with switches.
3A (“some use”) - Same as 1A, but this time some usage, like a really long youtube video (no screensaver, Firefox)
3B (“some use with more realistic screen”) - Same as 1A, but this time some usage, like a really long youtube video (no screensaver, Firefox)
4A (“actual use in offline/secure mode”) - same as 2A, but this time some usage, like a really long video from memorycard (offline)
4B (“actual use in offline/secure mode with more realistic screen”) - same as 2B, but this time some usage, like a really long video from memorycard (offline)
I think those should give an idea of what to expect from current Dogwood and give context to measure against when future improvements arrive. These, in a matrix, should let us to approximate the effects of the screen (brightness), HW switches (online/offline) and light usage to battery life. Possibly to heat also, if we can bet those measurements too. I’m sure these can be refined - they need to be reproducible and simple, yet still cover the different profiles.
A bit dull to do, I’ll admit, but that’s base data for you. And I’ll understand if it’s a bit too much to ask.
1 Like