Messages

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.

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

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

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

OK, understand your priorities, Menion.

Then at least the GM share with their plus codes needs to fly seamlessly (not "tap nearby, then ...")
And I have no idea how you will resolve the restricted data set problem.
The nicest and most consistent solution is in trouble, if you cannot trust the results (in the sense "why is so much missing ...").
Good luck for you and team!

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.

Very good background information, Menion, TXs a lot!

Yet, while on your server you must not use Google API, it would be not too hard to merge the local Android Google Search results with those from your server. Data feeds and presentation are two different architecture layers. And merging two feeds is no rocket science.
Once Locus server search is as comprehensive as Google Android API, the latter can be dropped. However, this may take years rather than months, I fear.
Do not get me wrong - I understand your strategy, and if you never start something new, you would never get there. But for the time being I strongly advise to combine the strenghts of both approaches rather than leaving the users with mediocre results (to be friendly) for unknown time.

Just my 2c.
Michael

@Jan: appreciate you see the looooong way ahead :-)))

What I do not understand: before the new search system, Locus DID use Google APIs, right? Not exactly maybe as GM itself does, but good enough to leverage the huge dataset Google has.
I do not see any reason that would stop you to feed such a Google API result set as an ADD-ON to your datasets.
Once your and Google datasets are comparable in size, you can drop that API call :-)
OSM alone is definitely not the way to go. When you do some maths like number of OSM objects/country size or /population, you will see that CZ, Germany and very few others stand out. The rest is not exactly desert, but way below practical or reliable.

Also, pls. mind what Tapio wrote below. The Google + location format is a must indeed.
And pls put priority to those fixes rather than taking users hostage.

TXs for your understanding.
Cheers
Michael

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

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

Thank you Menion.
Just checked: Use offset: NO, SRTM data: don't use, Medium filter (for GPS I suppose)

Can confirm - really bad.

@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

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

Die neue Version der Suche nutzt leider intern nicht mehr Google Maps API.
Habe deren Such-Entwicklings-Team gerade eine Nachricht geschrieben.

Ein Downgrade ist riskant, wenn man nicht technisch gut drauf ist (von Google Drive alte Version laden, alle Daten sichern (!!!), 4.17 de-installieren, alte version (4.15 sollte tun, vielleicht auch 4.16) aufspielen, Daten restaurieren.
Euer aktueller Ort ist nicht gerade der, wo man so etwas zum ersten Mal probieren sollte ...