Idea: setting for minimum/maximum GPS interval
israel-lugo opened this issue · comments
This is something that came to me yesterday as I was testing the CPU wake for issue #50 (thanks for fixing that).
What do you think about adding a setting to let the person define a minimum and maximum poll time?
For example, user A might want to preserve his battery or CPU sleep time, and doesn't care about perfect granularity because he knows he won't move much today. He could set min poll time to 5 or 10 minutes, and max poll to something large like 30 minutes.
User B on the other hand is visiting the streets of a new city by car, and wants to map exactly where he passed. He doesn't care about battery because the phone is plugged in. He could set minimum poll to 0 and max poll to 2 or 5 minutes.
User C works near a datacenter below ground level, and doesn't have GPS reception for long periods of time. He would like to avoid waking the phone every 2 minutes to check for signal. He could set TTT on pause (issue #49), but he's afraid he'll forget to unease when he goes to lunch. He could set min poll to a higher value like 10 minutes during the work week, knowing he will sacrifice a bit of GPS accuracy.
I realize this can mostly be achieved by time percentage setting, especially user B (just set to a very high %). However, for users A or C, a low percentage doesn't necessarily mean high intervals. I haven't looked at the algorithm properly, but if it works like I imagine, if the phone takes 2s to acquire location, even a 5% setting could mean waking every 40s to take a new reading.
This would be a complement to the existing % setting, working like a hard limit. Basically, the sleep time would be a function of max(minPoll, nextSignificantEvent).
I haven't programmed much in Android specifically, but I could take a shot at implementing this. I can send you a pull request if you think it's a good idea.
@israel-lugo
I like the idea of setting poll time.
I remember reading somewhere that there are limits as to the values you can specify.
Also, what do you think of this?
As I have said, I have no idea which is a better solution. Maybe a combination of your idea and this will be better?
Isreal-lugo, please go ahead. I'll pretty much open to new features as long
as they don't make the core functionality too complicated. I'll simply add
it under the new advanced category in the settings.
Collectorgeneral, I'll have to look into this more. I'm pretty convinced
just checking the phones accelerometer and orientation sensors will be most
helpful, but maybe this will work, too.
On 24 Sep 2016 20:51, "collectorgeneral" notifications@github.com wrote:
@israel-lugo https://github.com/israel-lugo
I like the idea of setting poll time.
I remember reading somewhere that there are limits as to the values you
can specify.Also, what do you think of this
#49 (comment)—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#52 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB1W0nAFZ_IPsbgSRefsWZaxnQRskt4Tks5qtRzUgaJpZM4KFnzX
.
The reason, or two, I thought about this was:
- Do all phones have the accelerometer and gyoroscopic sensors? Even entry level models? I am very out of date with phone hardware, they might have it. If so ignore this
- The second reason is, from my understanding, you are thinking to see if the phone 'moves'. You are probably thinking to check the sensors to see if there is a movement, and if there is, then query points. If not, after a set time, drop the app to a 'quiet' state.
The problem with point 2 is that you may have the phone moving, but not in a way that would require the tracking to go back to 'active' state. Take @israel-lugo 's example, say a person is in the basement of their office, and the GPS signal cannot be acquired. However, the person might have the phone in their pocket and might move around the office. I would assume that the sensors would get triggered by this constant moving, but there is no real need for the GPS to resume tracking.
Of course, if my understanding is wrong, then this whole thing goes out of the window.
If your method is far easier to implement, then by all means you can do it and leave this for some other time (if viable that is).