Keep GPS Warm mode

[jidanni]

I noticed that when Tower Collector is running, and some other app that uses GPS launches, that other app has to start the GPS cold. So, maybe Tower collector needs a new mode in options, (or more conveniently located) which would always keep the GPS Warm. That way, we wouldn't need an additional tisinadev.activegps app.

[zamojski]

So other apps have to cold start or Tower Collector has an issue obtaining the location? What would GPS Warm mode mean - keep it constantly on?

[jidanni]

Hmmm, if other apps need several seconds to get a fix while TowerCollector is running, that means TowerCollector also does too[?]. But TowerCollector-recorded coordinates seem pretty accurate. So it seems TowerCollector must be checking every second if it is now more than 20 meters from the last point it recorded, etc. to decide if it should record a new point. But then why can't other apps take advantage that TowerCollector is checking the GPS every second, and not need to warm up the GPS for several seconds before obtaining a fix? Android 8.

[zamojski]

As far as I know the location is managed internally by Android and in most of the cases (on my phone) the fix is almost instant if other app is using GPS at the same time. Maybe this is an issue with your device?

[jidanni]

Well, all I know is, with Tower collector running, take a picture. Okay now check the stored coordinates of that picture.

Because we just launched the camera app one second before we took the picture, its coordinates are still way off. So it didn't get any boost from having Tower collector running.

[Lee-Carre]

Other apps having to cold-start GNSS is (in my experience) due to switching between them.

Plus, re keeping GNSS warm in the background; from #145 (comment):

The disadvantage to this is one has no control the accuracy. The app will be happy with a 25m accuracy, not giving a chance for it to settle down before collecting the point.

A technique I use is to have the GNSS receiver perma-enabled (while out & about, not 24/7) by using a small (memory-footprint) app which has a toggle function. Examples:

• My Location (Lock G[NS]S) (has other useful features, including the ability to query UnifiedNLP backends)
• OpenTracks (Start G[NS]S, which is distinct from starting to record a track)

The idea of these seems to be exactly that of allowing the receiver time to stabilise, achieve good position fix accuracy, before actually recording any data. When recording a track, for example, this avoids the familiar ‘squiglies’ seen when track-recording starts at the same moment that GNSS does. 🙂

I'll start it several minutes before I'm due to head out. By then I'll have 5m (or less) uncertainty of position. This becomes especially necessary when using carrier-phase (particularly without dual-frequency reception), or when lacking ephemeris (orbital, Augmented-GPS) data; then it can take on the order of 15 minutes to stabilise.

However, for context;

• I'm running more than just Tower Collector (other radio-data loggers, and often doing map surveying)
• I use an external battery, so energy consumption isn't a concern for me

Besides starting data-collection with good accuracy, I can switch apps with carefree abandon, and otherwise always have a good fix immediately available. Anything which uses the passive location provider also benefits from readily available fixes as I'm on the move (think of the likes of weather apps & automation tools).

The benefits of this POSIX-philosophy approach (each app doing one job, in order to do it well) is that other apps can remain simpler, and not have to be concerned with ‘warning up’ the receiver first. Each app need only set sensible (for its own needs) parameters for receiving position updates from the GPS provider (like Tower Collector does, with min-distance of some 20+ metres). Plus, granular control over when it's enabled (instead of each app guessing); defining my own trade-off between performance versus energy-saving.

The problem with wanting each app to do this (to compensate for a problem outside said app), is that many apps would have to implement the same. Depending how it's done, it still may not solve the problem of the GNSS being reset when switching apps.

Tower Collector itself keeping GNSS perma-enabled would seem to be against its own interests (low power usage).

The generic (separate app) approach is far superior, in my assessment & experience.

Tower Collector should be kept simple(r). Power-users (evidently) know how to achieve the results they want.

I must vote against the OP proposal / request.

[jidanni]

The above comment mentions several apps to keep GPS locked on. My question is why doesn't TowerCollector have the same effect? Why can't I use to TowerCollector as a GPS Locker?

[Lee-Carre]

@jidanni

The above comment mentions […].

[…] why doesn't TowerCollector have the same effect? Why can't I use to TowerCollector as a GPS Locker?

The comment you reference addressed your questions:

The benefits of this POSIX-philosophy approach (each app doing one job, in order to do it well) is that other apps can remain simpler, and not have to be concerned with ‘warning up’ the receiver first. Each app need only set sensible (for its own needs) parameters for receiving position updates from the GPS provider (like Tower Collector does, with min-distance of some 20+ metres). Plus, granular control over when it's enabled (instead of each app guessing); defining my own trade-off between performance versus energy-saving.

The problem with wanting each app to do this (to compensate for a problem outside said app), is that many apps would have to implement the same. Depending how it's done, it still may not solve the problem of the GNSS being reset when switching apps.

Tower Collector itself keeping GNSS perma-enabled would seem to be against its own interests (low power usage).

The generic (separate app) approach is far superior, in my assessment & experience.

Tower Collector should be kept simple(r). Power-users (evidently) know how to achieve the results they want.

If you want to understand why, then I strongly recommend reading The Art of Unix Programming (by Eric Raymond, author of Cathedral & Bazaar).

For example (a few among many; read the book);

• simpler implementation tends to be more robust (doing its one job well)
• the more general purpose something is, the less good it is in each area; Tower Collector fills a particular niche, if you (like me) want to use it in power-mode, that's beyond the scope of Tower Collector itself — expecting the same vehicle to have sports-car performance and carry 20 tons of cargo, isn't gonna be any good at either
• ignoring hard-learned principles results in displeasing software (e.g. inefficient bloatware riddled with bugs)
• why reinvent the wheel, when there's an existing (& superior) method for achieving the desired effect?
• different tools for different jobs, hence why the likes of a sonic screwdriver (which magically fixes any problem) is observed only in fiction — well-designed software allows & enables tools to be combined for the-whole-is-greater-than-the-sum-of-the-parts effect (see Introduction to the Command Line for explanation & examples of feeding the output of one tool into another) — smart use of (software) tools is in finding ways of combining niche tools to achieve your desired resultant outcome; the successful combination can be stored in a (shell) script for easier invocation
• modular systems strongly tend to be superior (in multiple attributes) to all-in-one designs
• the generic approach solves the general case, regardless of specific apps

Be mindful that you're not falling afoul of The XY Problem.

[jidanni]

Okay, maybe you're trying to tell me that tower collector is taking little naps. All I know is when I try to click on those Blue Links here in the GitHub app they all go nowhere special.

[Lee-Carre]

Disclaimer; this turned into quite an essay; more than I was expecting. Hopefully it helps to explain some of the ‘why’ & background.

tower collector is taking little naps.

While I'm not familiar with running Tower Collector without anything else, I believe this is the case.

Besides it not needing the GNSS receiver on all the time (think battery-drain), or super-high accuracy, the idea is that it sits in the background using few resources.

For clarity, Tower Collector (or any other app) doesn't (to my understanding) control the GNSS receiver directly. All it does is request service from the GPS provider with a set of parameters describing the characteristics of the service it would like. For example, the min-distance interval being ~25m (instead of 1m or 0m), the time interval is probably set to 1 second, too (zamojski is welcome to correct me with the real numbers). This means that Tower Collector is telling the location provider that it only wants updates when those criteria are met. Instead of frequent updates which are useless to it. So, TC doesn't even know that it's moved 30+ metres until it is sent a new fix by the GPS provider (otherwise it would have to process & filter-out many frequent updates). This is much more efficient (both for the device, and Tower Collector; less processing, things only happening when the right conditions are met (moving far enough to warrant taking a new sample)). All Tower Collector sees, is a position update when the phone has moved (at least) 20–35m (whatever number it sets in the parameters when querying the location provider). For contrast, something like a navigation app will want an update every 1s and/or 1m (whichever happens first), and an app to record your path / route / track might set 0s & 0m (meaning; supply updates as fast as the system can). TC doesn't need that much; it would be excessive. Especially when stationary; no updates (very efficient). The point that I'm getting to, is; between updates, what happens with the GNSS receiver (the hardware chip) is entirely the decision of the system. When stationary, and nothing else is wanting position updates, then it might turn off the receiver (to reduce power use, to preserve the battery). There are other things to compensate for this, and make it possible to get a moderately-accurate fix within a couple seconds of starting the receiver (which is good enough for most apps); Augmented-GPS is an example of such a method. Why? Because it's a good trade-off for most cases, because the performance is still good, while saving a lot of power. To want & do otherwise, is unusual.

That makes a lot of sense for the typical user (along with #1), I'm an odd duck and do things in power-mode (as you seem to want to, also). For instance, I run a bunch of UnifiedNlp backends which use the passive location provider and so only get a position (& collect data) if something else activates the GNSS receiver. I also run other data-collectors. I'm often doing map surveying, too. So, when I'm out, my GNSS receiver is perma-active (with duty-cycling disabled).

But, I also have a ~24Ah external battery in my pocket, so I don't (have to) care about power-usage (I want performance & accuracy).

This is not the case for the typical / average user. So, Tower Collector being efficient is important. That's how data is gathered by more than just hardcore dedicated enthusiasts & surveyors.

Regular users aren't happy when an app drains their battery (because it interferes with them checking Fa[r]cebook, watching cat videos, sharing memes, and whatever else normies do with their nano-computers). The risk is, that they'll stop using it, uninstall it, or (in the case of Tower Collector) otherwise stop collecting & uploading data. That would be Bad™.

The fewer resources Tower Collector uses, the longer it can be running, and by more users. All that means more data. Think about why it samples every 20+ metres, instead of every 1 metre. Because cell sites are far apart, so 20–35m is enough (along with 10–15m accuracy, which it can get easily from the GNSS receiver being active only briefly). The GNSS receiver uses a fair bit of power. So, keeping it off, most of the time, significantly reduces battery-drain. The result is a good compromise, yielding the best of both; useful data, minimal resource-usage.

So, adding the requested feature would be against so many of those goals & requirements.

So, Tower Collector can't (& shouldn't) do that.

Hence why I use an external battery; to have {dramatic voice:} unlimited (cosmic) power & do all the things, with all the settings turned up to 11.

However; there are ways to achieve what you seek, as I described, in good ways, without (adversely) affecting Tower Collector (and thus other users), or requiring any source-code change.

Think of it this way; you'll be collecting more accurate data, since position-fixes will have an accuracy of a few metres (& available immediately), rather than 10+ metres. It's something you can do immediately, without having to wait for whatever to be implemented. If you're really serious, then you'll also disable duty-cycling (in the Developer Options of Android), but that'll increase your battery-usage even more.

I'll use an analogy, to illustrate: imagine that you want a super-high-performance car (and have the money to spend). Beyond what ordinary folks want from a road-legal sports car (which includes reliability & not needing to do maintenance between each time it's driven). Most folks are happy with a powerful (but otherwise normal) engine. You, wanting extreme performance above all (including convenience & cost), desire a nitrous injection system (more oxygen, means more fuel–air mix for each piston cycle, which means more power (= acceleration & speed)). So, you ask the manufacturer why they don't include one as standard, because that's what you want.

Now, here's the difference. While that may be ideal for you, it's not for most drivers. Besides expense, it also has to be recharged (the tank refilled & pressurised) between uses. This is worth it to you, but not to most; it's too inconvenient & costly.

This is why it's not standard; because it's not the common case. What you seek is the exception. To impose the extreme option on everyone is unreasonable.

However, no-one is telling you that you can't, or aren't allowed. You just have to modify the stock / factory car to get the results you want. Yes, for you it's inconvenient compared to if it came from the manufacturer exactly the way you wanted it (but you're free to offer them payment for a custom build, if they're willing; the equivalent in software would be to fork the repo and make your own changes (or pay someone to do so)). However, the manufacturer is gonna do what the market demands, and most buyers are happy with a normal (but powerful) engine.

So, you just have to buy the factory-spec car, and take it to a workshop to have them pimp your ride (with the nitrous system for ultra-power). You can still get what you want, in the end.

That's basically what I'm describing, here; how you can get the effect (with Tower Collector) that you want, while the app remains sensible for most users.

Back in software terms; you're wanting to use an uncommon configuration. So, that means doing things a little differently.

Perhaps a different approach; what is the basis of your objection to using a separate app to keep the GNSS receiver active? That's the part which is unclear. If it's something more than just ‘I don't like it’ (in)convenience, then there might be another way to solve the problem.

---

when I try to click on those Blue Links here in the GitHub app they all go nowhere special.

That sounds like a bug with that app (because of how I make links; protocol-agnostic). I suggest reporting it to Github.

[jidanni]

Okay, thanks, your point is sinking in: I can't just make assumptions on how one app might affect another these days because what's going on under the hood is not necessarily handled as I assume it might be. Got it!