Hi all!
I'm about to go on a long biking trip, and I'm trying to optimize my battery usage. Recently I bought a premium subscription, and I'm super excited to test Locus maps full potential.
Is there a table showing battery usage per feature in Locus maps?
So far, I've noticed that Locus turn-by-turn sound navigation drains the battery (screen off). I thought I could use a different navigation method instead. I came up with the idea of combining 'Point alert' and 'Screen on/off control'(Turn on when notified of a point). So I mark turns with a point, and 50m before I reach the point, I get a beep and screen on for 5s.
Does it make sense?
Has anyone tried that approach to save the battery?
Is it possible for app developers to estimate the battery usage in these two cases?
LM varsion: 4.16.0
Android 13
Regards
Marcin
For me, track recording is 4%, and optional navigation increases that to 8% (total). Will depend completely on battery size & condition & screen brightness. I therefore (mostly) never use navigation, and simply turn on the screen briefly before any potential turn. I find looking at the map far more informative & reliable than turn instructions. I have the screen timeout for 6s. Sometimes I use POI alert but to replace navigation commands would be very tedious if lots of turns.
Hmm, having a measured features and it's impact on battery is my dream. I've tried it a few times, but never get a reliable values.
Anyway, best is to avoid CPU hungry tasks if possible. We have a small FAQ about it here: https://docs.locusmap.app/doku.php?id=manual:faq:locus_performance
Generally, try to avoid mainly:
- screen on
- GPS on (funny, I know)
- extra map layers (overlay, WMS, WMTS)
- shading
- too many points & tracks visible on the screen
- and well, app navigation/guiding is still not perfectly optimized so IT IS CPU hungry feature
Quote from: Andrew Heard on May 17, 2023, 17:22:41For me, track recording is 4%, and optional navigation increases that to 8% (total). Will depend completely on battery size & condition & screen brightness. I therefore (mostly) never use navigation, and simply turn on the screen briefly before any potential turn. I find looking at the map far more informative & reliable than turn instructions. I have the screen timeout for 6s. Sometimes I use POI alert but to replace navigation commands would be very tedious if lots of turns.
I agree with Andrew.
In addition to keeping the consumption of Locus under control, it is also necessary to reduce that of the device.
If you don't need to be contacted by phone, you can put it in airplane mode.
If, on the other hand, a telephone connection is needed, but it is possible to give up the internet connection, data connectivity can be disabled.
Another thing I do at the start of the day when LM track recording will be on all day & I need to maximise battery time, is to run an app called KillApps. It kills (supposedly) around 50 useless background apps. I really don't know whether it has useful benefit but it makes me feel better;-)
@Menion:
my S10, old (now exploded) and new battery is depleted at 24-36% per hour while tracking!
- screen on: my screen is off 99% of the time, as I know the route by heart
- GPS on (funny, I know): as far as I recall Locus will deny tracking if GPS is off - has that changed?
- extra map layers (overlay, WMS, WMTS): overlay typically yes, but there is no display work, as screen is off
- shading: not active
- too many points & tracks visible on the screen: maybe one track and a few points
I had sent you a PM with logs files and more stuff, when Locus burnt 24%/h for sitting still in my room for 6 hours, no movement.
What tracking settings do you use, @Andrew, pls?
Mine are 10m dist., 5s interval, AND condition, GPS 50m acc.
All my background noise on the phone (incl. Locus NOT tracking, Locus GPS off) is 2%/h
I'm logging my BATT usage to WPs while hiking and had a look now. Recording settings is 8/8/50, no livetracking, some Tasker background action, voice navigation, lots of looking on phone, taking pictures and videos.
Device at 100% batt at start. Battery % loss increases over time.
- 6% batt/h in the beginning
- 12% batt/h towards the end (after 5-6 hours).
Huawei Mate20X, idk, 4 years old device.
With such huge consumption, you may do a few tests to check what exactly do the difference.
I would test, with the screen enabled for the whole time
- just turn on the device after the restart, to have some "baseline"
- start Locus and turn off everything possible, including GPS (here you should have mentioned 2%/h + screen
- then just turn GPS on, no track recording, no navigation, no map movement
- then start track recording, nothing more
Did anything from this make a difference in consumption? No matter what parameters you define for recording, no matter what you do in the app, it should never have 24%/h :o
TXs Menion.
Steps #1 and #2 I have proven: without tracking, Android GPS is on, but Locus location is off, so Android GPS is not working: result is the 2%/h
#3 I think I did once, but I am not sure about the results, so I'm running this test now: Locus GPS is on and location found, then I turned screen off. Let's wait for the results.
Quote from: michaelbechtold on May 18, 2023, 18:22:57What tracking settings do you use, @Andrew, pls?
Mine are 10m dist., 5s interval, AND condition, GPS 50m acc.
25m/ 240m/ 50m, I also have Tasker running, but doing very little. The Samsung phone is now 5 years old.
Quote from: Andrew Heard on May 18, 2023, 22:41:10Quote from: michaelbechtold on May 18, 2023, 18:22:57What tracking settings do you use, @Andrew, pls?
Mine are 10m dist., 5s interval, AND condition, GPS 50m acc.
25m/ 240m/ 50m, I also have Tasker running, but doing very little. The Samsung phone is now 5 years old.
25m dist, 50m acc, I assume, but what are the 240m then? And which interval do you use?
Quote from: michaelbechtold on May 18, 2023, 20:47:46TXs Menion.
Steps #1 and #2 I have proven: without tracking, Android GPS is on, but Locus location is off, so Android GPS is not working: result is the 2%/h
#3 I think I did once, but I am not sure about the results, so I'm running this test now: Locus GPS is on and location found, then I turned screen off. Let's wait for the results.
#3: Locus and Android GPS active, but no tracking: 2.5%/h
@michaelbechtold oki, thanks for the test. Anyway, I wrote, "with the screen enabled for the whole time".
Because
Quote from: michaelbechtold on May 18, 2023, 20:47:46Locus GPS is on and location found, then I turned screen off. Let's wait for the results.
causes the GPS is turned off when the screen goes off. You may prevent this by "Settings > GPS & sensors > Disable when the app is hidden". Disable this option to keep GPS on all the time.
If this will have still low consumption, then step 4 is enabling track recording ..., nothing more.
we can't directly compare the absolute value of each device battery consumption per hour because each device has a different size battery, I*think* mine is roughly 4mAh (4Ah). A small battery, with all else the same, will have a bigger drain per hour.
Quote from: Menion on May 19, 2023, 07:58:40@michaelbechtold
oki, thanks for the test. Anyway, I wrote, "with the screen enabled for the whole time".
Because
Quote from: michaelbechtold on May 18, 2023, 20:47:46Locus GPS is on and location found, then I turned screen off. Let's wait for the results.
causes the GPS is turned off when the screen goes off. You may prevent this by "Settings > GPS & sensors > Disable when the app is hidden". Disable this option to keep GPS on all the time.
If this will have still low consumption, then step 4 is enabling track recording ..., nothing more.
TXs @Menion. Luckily, that option I have set years ago for all my devices ;-)
Over night I had started a track recording, no movement of the device, screen off. The device did not even survive until the morning: 93% to 1% in 4.5 hrs -> 20%/h. Same effect you have in my older mail.
I ran the same test with my Tab S6l: 4%/h, which is very reasonable.
Only difference in settings I found was GPS accurracy: 50m for the S10, 200m for the Tab.
Quote from: Andrew Heard on May 19, 2023, 08:22:48we can't directly compare the absolute value of each device battery consumption per hour because each device has a different size battery, I*think* mine is roughly 4mAh (4Ah). A small battery, with all else the same, will have a bigger drain per hour.
Agreed in general, Andrew.
Yet: your 4% for pure tracking, like my tablet (completely different beast than your's), Tapio's initial 6%, they are all reasonable values.
Doubling at the end on Tapio's device needs to be understood (this is a FACTOR), and the extreme factor on my S10.
@Tapio: did those 12% appear for half of the trip, or only like in the last hour before end of battery capacity?
You could backup settings on good device, copy & restore on bad device, to test apples with apples? Something is very badly wrong. Sorry to hear.
Quote from: michaelbechtold on May 19, 2023, 13:42:31@Tapio: did those 12% appear for half of the trip, or only like in the last hour before end of battery capacity?
See attachment (bat log is every 5%), seems like with increasing time system eats more battery, but - I think it's rather system/hardware who create optimistic battery levels, the more charged it is, the decay of batt level speeds up, not the first device I observe it. And I'm fine with my consumption. Have always >40 when my outdoor activities are done, no need for a powerbank, good.
EDIT: No, I cannot generalize. Checked another hiking trip, except the first half hour I had pretty stable usage of around 13%/h the rest of the trip.
Mine has always been around 4%/h and goes down independent of total %. Lately it's going down a bit faster as battery is getting to end of life.
Quote from: Andrew Heard on May 19, 2023, 18:08:31Mine has always been around 4%/h and goes down independent of total %. Lately it's going down a bit faster as battery is getting to end of life.
Yes, after 4 years the S10 battery showed the same effect, but stronger, which led to the swap (including explosion and rebuild).
And yes, Andrew, config transfer from Tab was my plan, too. Done last night and WIN! 4.5%/h.
I will now compare the disaster config with the good one and report here.
From look and feel and handling I sense zero difference, so the difference must be something very interesting and hidden.
Quote from: michaelbechtold on May 20, 2023, 06:50:57And yes, Andrew, config transfer from Tab was my plan, too. Done last night and WIN! 4.5%/h.
I will now compare the disaster config with the good one and report here.
From look and feel and handling I sense zero difference, so the difference must be something very interesting and hidden.
well done!! will be very interesting to read the difference!
@Menion: I rushed to see the results from taking the Tab S6l config, so I did not care about wrong paths (EXT SD IDs of course differ). After the that test I started to correct the 4 of them:
1) backup - no problem while processing, neither after restart
2) maps - on the Tab (small INT SD), this is on EXT SD; on S10 it used to be in the main Locus folder (INT SD/Locus). Processing: a list of maps, well known to me, runs across the screen; after restart, maps is EMPTY !! (Real losses, as I did not expect such and did not backup those upfront)
There is definitely a logic error. Locus must NEVER delete anything from the target folder; IN PARTICULAR if the source is non-existent!
3) mapsVector - same amok. That one did not hurt, because it were LM3 maps, supposed to be updated anyway
4) srtm - OK, like #1
So I have been busy for a while ...
Config difference analysis to come later.
@Menion: once I had the 4 directories adapted to the S10, I ran another test.
And it went back to disaster: 20%/h
Then I renamed the huge srtm folder on EXT SD without adapting in Locus and started yet another test.
It seems we are back to 4%/h
The config differences between original S10 and original Tab are tedious to walk through.
The differences between original Tab (4%/h on S10) and adapated config (20%/h) are in the areas you can expect: screen positions and some paths.
I'm now testing the S10 without access to the srtms and the Tab with access to ist srtms - stay tuned ...
@Menion: now the brain twister for you:
- S10 with erroneous SRTM path is back to 4%/h
- Tab S6l with a working 30,000 hgt SRTM folder takes 1%/h
- difference is: the S10 SRTM is directly at EXT SD top level, which the Tab SRTM is in a LocusEXT sub-folder.
Any idea why that is?
More food for thoughts, Menion:
Moving the SRTM folder one level down does not help on S10 (Android 12, while Tab is Android 13)
I ran a number of tests today and this is the pattern:
- the pure existence of an empty SRTM folder on EXT SD does not harm
- putting the hgt of the track area into the SRTM folder increased the burn from 4% to 6%/h
- moving this stuff to INT SD does not help
- putting 100 1sec hgts into the INT SRTM folder blew up the burn to 12%/h
S10, Android 12.
Question to @Menion: why would Locus deal with ANY hgt file while recording??
@Menion: after a dozen tests or so, narrowing down the effect, this is the outcome:
- tracking with screen off, record only when moving, device always in the same place, hence only the normal GPS "noise" movements
- if the hgt file of the area is a 3sec file, the battery burn is 4%/h
- if the hgt file of the area is a single 1sec file, the battery burn is 12%/h
- if the srtm folder is full of 1sec files, the burn jumps to 20%/h
- this is regardless of INT or EXT SD
That strongly points to Locus doing (useless?) hgt file operations which tracking. At least I cannot explain why Locus should look at hgt files while it records a track.
Can you pls. check and advise?
TXs and cheers
Michael
What a nice observation!!!
I have no idea why this happens but will check it. I'm going to download a few (maybe more) 1" files ...
And why the app use them? Maybe some setup in the altitude manager?
Thank you Menion.
Just checked: Use offset: NO, SRTM data: don't use, Medium filter (for GPS I suppose)
PS: it can easily be that Locus touches the "local" hgt in any case, 1 or 3 alike, but the battery cost would be multiple in case of 1sec, depending on what it is doing.
Also shading and dynamic elevation are OFF, of course
Hello Michael,
complicated task. I've downloaded around 1000 1" DTM files and tested them properly with some Android tools, but there is no significant difference on my Pixel 5 device.
I remember well, that I had a problem with geocaching files. In case of a huge number of caches, the app downloaded all cache offline files into a single directory. In the case of 1000+ files per directory, performance went down a lot. Maybe this is the same issue.
But surprising is your "if the hgt file of the area is a single 1sec file, the battery burn is 12%/h". Also, this should make no difference between 1" and 3" files ... but that is, based on what you wrote, also not correct. Weird.
App touches DTM files for generating an object that is then sent over API to clients or to any other parts of the app when needed. It is made 2x per second and also includes elevation values of the map center. Anyway, this should have a zero impact on the CPU.
I'm thinking about what to do with it. App is loading HGT files into memory and up to 6 latest files should be kept in memory. So quite huge area should be covered by memory without need to touch the device disk again.
---
Hmm, may you please start track recording with 20%/h consumption and after few minutes, create and share big system log by this (http://docs.locusmap.app/doku.php?id=manual:faq:how_to_create_debug_log) "good" old method? To test, if there isn't any clear error on the background, thanks a lot!
TXs Menion.
I just sent you a link to the huge ZIP on GD.
Doing a brute force search through the debug data, I found the 6 hgts you mention. Beyond that I am not used to that kind of internals - you are :-)
None of those 6 is the N50E008 where the tracking happens.
On the other hand this local hgt SHOULD not be touched anyway ...
This is from an S10, Android 12.
And the effect is reproducible at will: whenever the 25MB-version of N50E008 is in the Locus srtm folder, the battery drain goes up 2-4 fold, compared to no file N50E008 or the small version.
Good luck and kind regards
Michael
FS/data/tombstones/tombstone_20: fd 107: /storage/6561-3431/srtm/N47E005.hgt (owned by RandomAccessFile 0xf7e876a)
FS/data/tombstones/tombstone_20: fd 109: /storage/6561-3431/srtm/N46E005.hgt (owned by RandomAccessFile 0x863ca2f)
FS/data/tombstones/tombstone_20: fd 119: /storage/6561-3431/srtm/N47E006.hgt (owned by RandomAccessFile 0x14b64f8)
FS/data/tombstones/tombstone_20: fd 150: /storage/6561-3431/srtm/N46E006.hgt (owned by RandomAccessFile 0xb75b036)
FS/data/tombstones/tombstone_20: fd 167: /storage/6561-3431/srtm/N45E005.hgt (owned by RandomAccessFile 0x248bd41)
grep: FS/data/tombstones/tombstone_20.pb: binary file matches
FS/data/tombstones/tombstone_28: fd 120: /storage/6561-3431/srtm/N53E006.hgt (owned by RandomAccessFile 0xc2c58e3)
grep: FS/data/tombstones/tombstone_28.pb: binary file matches
Thanks for the log Michael. Unfortunately, I see nothing useful inside ...
Will have to try on another device next few days because on my main Pixel5, no problem as I wrote before. Still, no idea why this should happen ...
Btw. you are using 1" files from Sonny from here right https://sonny.4lima.de > Germany DTM 1" ?
EDIT: I've added some more log messages into the app, so in the next Beta version, "Log to file" may produce some more info. I have one idea what may cause it so want to try.
Thank you Menion.
And yes, I'm using Sonny's 1sec.
What maybe of note: this S10 is on Android 12, while the Tab S6 lite is on Android 13, but does not suffer.
Android version should make no difference. Anyway, the app currently loads HGT files into memory and then computes elevation from these in-memory files. I have a suspicion, that aggressive memory management force app to discard these loaded files and app then has to re-load them again ... and again. So I've added some logs into the app to see, how often app re-loads these files from disk. The beta will be published, hmm hopefully tomorrow ...
I think you are right, @Menion.
For yet another test I have put the 1sec 25 MB hgt in place in the SRTM folder again and let Locus run: typical massive battery burn.
Then I simply DELETED this hgt file (the activity spike in the middle of the graph, also did a bit of other stuff), and afterwards the battery drain went half the rate!!
To me that means that Locus indeed is reading this file over and over again.
But it also means that it would do that with the smaller file (3"). As it is 1/8th of the size, the drain effect is smaller. Yet, Locus could save battery even with 3" hgt files.
Good luck killing this beast ...
Michael, in the test directory (http://bit.ly/lmVersionsTest), is a Beta version with
- logs
- a little optimized caching of HGT files
Give it a try. If consumption will be the same, please enable "Log to file" and create a small log for me, thanks!
Quote from: Menion on May 25, 2023, 14:33:52Michael, in the test directory (http://bit.ly/lmVersionsTest), is a Beta version with
- logs
- a little optimized caching of HGT files
Give it a try. If consumption will be the same, please enable "Log to file" and create a small log for me, thanks!
TXs Menion.
It is still twice the darin compare to no file or small file.
As I had the logging still active from the past, I will send you the log in PM.
Looking into it I found 1000s of dealings with the HGT file of the current region, as long as recording is running. Although recording uses GPS only (the DTM option is off).
Can you pls. advise?
TXs and cheers
Michael
Good evening,
it is a shame ... nothing useful here. The app works as expected. Damn. (but thanks a lot for the file!).
Log file - as I wrote before: "App touches DTM files for generating an object that is then sent over API to clients or to any other parts of the app when needed". This is why in the log you see a computation of elevation every second.
I really do not understand why this happens and I would really need a device that suffers by the same problem. I'll ask some other guys in team next week ...
You at least know a solution > use 3" data, simple ;)
Hmmmm, in the log I just checked what happens when I left the scope of the amok HGT file: locus continued to use this old file, although Locus - and I - were already outside its scope.
So, what is the use of providing a wrong location object via API? Also: why at all use DTM files for that if you have current GPS position for free?
And Locus runs just fine if there is NO HGT file for the region you are in.
Hence just pretend there was no HGT file(s) at all while recording, and Locus will safe battery for everybody. Always.
Cheers
Michael
This is not the correct solution Michael. If compute of elevation took so much power, this problem should be solved, not that some function use this method. The offline elevation is computed often, for online LoPoints, during routing, for shading, when you create a new point etc.
In this case, the app most probably computes elevation in the map screen center for every second. Anyway, oki, I've disabled this method and appropriately updated the code so try the next Beta if it helps. But in the moment you enable map shading, you'll be where you are now, maybe even worst because of the huge number of computes the app has to do!
That approach is worth trying, thank you.
Map shading while recording or following a route - that seems avoidable luxury to me, to be honest, hence nothing really lost.
Map shading I consider a planning help - and for documentation; i.e. time limited exercises.
I'll report the measurements ASAP.
Interesting thread ... I'm always looking for a reason why my battery discharges so fast while motorcycling in comparison to hiking/biking.
Very interesting! I came across this discussion by chance only a week ago.
I myself had noticed only a few weeks ago that Locus suddenly caused very high battery consumption, always when navigation and/or track recording was running. On day trips, a power bank had to be connected after only 3-4 hours.
Now we were hiking in the Liberec area (Czech Republic) for about 2 weeks. Very beautiful area by the way! Every day with track navigation along planned routes and track recording. Strangely enough, there were days when the battery lasted through the day without any problems, but on other days it was already empty after a few hours.
After reading this discussion I remembered that in March I had downloaded the 1" files of the elevation data (24.7 MB each) for the whole of Germany from Sonny, which coincides with the beginning of the high battery consumption.
These were not available for the Czech Republic, where I still have the small 3" files (2.7 MB).
Now the region west of Liberec is still covered by the Sonny file N50E14.hgt, while those from the city and further east are covered by the 3" file N50E15.hgt. And indeed, it was the tours in the west (Ještěd Mountains, etc.) where the battery consumption was extremely high. In the eastern Jizera Mountains, the battery lasted the whole day.
I would never have thought that this could be the cause without these posts on the forum. I then replaced all the 1" files with the small 3" files and the battery consumption was normal again. Even with another hike in the N50E14 range. 😊
Translated with www.DeepL.com/Translator (free version)
Another 1%/h battery saving (down to 5%/h while recording track, with a 1" hgt for the region of the track, on a Galaxy S10), now that the hgt evaluation once per second is avoided.
TXs a lot, Menion!
Hello,
I also encounter an issue with the power consumption of Locus Maps.
Thats (I think) also after I installed the 1" hgt files.
Could you please tell me how to get the new beta version?
I need the afa-Version, because it allows access to the /Locus/Data/srtm folder in the old structure.
Thank you
Each post from Menion includes all relevant links at its bottom.
For your convenience here is the one you need:
http://bit.ly/lmVersionsTest
I'm using the AFA version, too, BTW.
Cheers
Michael
Hello guys,
new Beta 4.17.1.3 just generated. I've found also one extra issue in consumption that may happen in the case, in the directory is really a lot of files. I've improved caching so it may help as well.
But I still do not know why with a single 1" you had so high power consumption Michael ...
Well, we know the HOW (dealing with the file once a second, over and over again, without ever caching it), but we do not understand the WHY. With this function call every second gone, it is no longer an issue - luckily :-)
As I wrote, working with a file every second should not be a problem. App does this with many files and it was never causing any issue. Probably here it was because of a huge number of files in the directory. Should be anyway improved in new Beta as I wrote.
I forgot to mention that I'm on 3.68 (Classic). Is there a beta available, too?
Btw. as I also encounter a higher current draw lately, is it likely for the Classic version to have a similar "problem" as V4.x?
I usually do not create a Beta version for the Classic version. But there will be probably one more bug-fix version next week ...
Hello Menion,
could you give me a hint where to access the newest Locus Classic AFA version?
Thank you very much :)
Greetings from Brunswick (and from Chamonix - in a few days :D )
@BlueCharge: just click on "LM4 final" in Menion's footer (label is misleading).
Then enter the LM3 sub-folder in GD.
Thank you!
Unfortunately, the latest Classic AFA-Version is still from May.
@Menion, do you plan an update via your footer in the near future?
Thank you very much,
Peter
Edit:
A closer look into the 3.68 (2023 05) folder showed a newer version from June :-)