Power consumption - overview

[Menion]

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 "good" old method? To test, if there isn't any clear error on the background, thanks a lot!

[michaelbechtold]

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

[Menion]

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.

[michaelbechtold]

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.

[Menion]

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

[michaelbechtold]

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

[Menion]

Michael, in the test directory, 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!

[michaelbechtold]

Michael, in the test directory, 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

[Menion]

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 

[michaelbechtold]

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

[Menion]

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!

[michaelbechtold]

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.

[jonny.blue]

Interesting thread ... I'm always looking for a reason why my battery discharges so fast while motorcycling in comparison to hiking/biking.

[Graf Geo]

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)

[michaelbechtold]

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!