Notices

I normally get a position in less than that, but lets say that's a number.

Sure, then give it 30 seconds to try? User-definable setting for timeout?

I have a simple python script that gives me GPS coordinates. I don't understand it (partially since I don't understand the location API in the Python code) but it seems to always, in a reasonable way, figure out the current GPS coordinate, and it's always pretty accurate.

I live out in the country, and by celltower it locates me sometimes 6 kilometers from where I am! I hope you understand that isn't even a little bit useful?

Actually, for me, "last GPS coordinate" is probably of more use than cell tower.

Ideally, make it configurable:

#1 - how long it tries
#2 - what it does when it fails, i.e. "keep last GPS point" or "revert to Celltower"

As said, for me, celltower is almost worse than useless.

So if I set up a cron job that every 30 minutes runs my gps.py (which gives the proper GPS position), that wil cause your tool to give the accurate coordinate? But what about all the times in between - your tool will fallback on the inaccurate coordinate?

I wouldn't want that.

I actually tried to extend the Python code I had to do latitude, but something went wrong in the auth stage (even though I seem to be doing exactly what everyone else is doing... very strange).

Here's my suggestion:

You give the user these options:

UI = Update interval (seconds):
GO = How long to keep the GPS on (seconds):

So you update every UI seconds.
If GO is zero, then DO NOT USE GPS AT ALL, use celltower.
If GO is nonzero, but less than UI, turn on the GPS for GO seconds every interval, then turn off.
If GO is nonzero but equal to or greater than UI, then keep GPS on constantly.


That's easy, and not so many user interface controls, and gives the total flexibility, and saves YOU the problem of deciding how long to try the GPS.

The only remaining question is, what to do when GPS doesn't lock, fall back to celltower, or use the last working GPS position. Personally I suggest give the user an option for that too, i.e.

When no GPS Lock use:
[ ] Celltower position
[ ] Retain last GPS position

Please?

Pretty please?

I'll send flowers!

/Z

ok, uploaded my current code to git as "experimental" branch

Maybe

UI = Update interval (seconds, default 30min):
Cell (default) / Cell+Gps / Gps
GO = How long wait for a coordinate (default 30sec)

if not network, then not update

with cell, always i have a coordinate
with cell+gps, if the gps NOT fix, then fallback to cell
with gps, if the gps NOT fix, then not update

waiting for yours comments...

btw: the qtm location do not work well, never stop the gps, and always use the gps

Yep, that would work.

That's too bad if that's the case. Is that why this problem is in so many apps??

/Z

rlinfati is there a problem in using a .ui file in the control panel? Or you didn't like my ui? Tell me and I will fix it...

googlelatitude (0.6-0) unstable; urgency=low

* Daemon at boot time (default off)
* If not network, do not try to update
* Use of gps
* Max 120s for a fix, min of 5 in cell-mode and 15 in gps-mode, default 30s
* Updates between 1800s, min 300, max 3600

@traysh the .ui file are "expensive" in cpu/ram..., also the use of dbus

TODO:
-integrate the plugins for the control panel, only if not use .ui file
-maybe integrate the code to not update the location with a less accurate position...

googlelatitude (0.6-1) unstable; urgency=low

* auto update setting for daemon, fix start at boot time, fix NaN in gps eph

Wouldn't call that a workaround. Since settings aren't changed that often, restarting the daemon should be fine...

As the config in the system settings is a standalone binary, it is not a problem, it won't be run very often, only when it is necessary to change a setting.

About DBus, removing the gui from the daemon reduced the ram usage from 20MB to 2MB, and that's very little, so DBus is not the reason of memory (nor cpu) usage, it's already loaded by the other app anyway and shared between applications.

I noticed start daemon doesn't do much, when you stop the GUI there are no updates.
Enabling daemon at boot and rebooting seems to have started the daemon, waiting now to confirm it is updating.

In the UI I had disabled GPS, but whenever I start the UI app, the GPS still goes on.

OK, the deamon seems to work (is updating), but it always switches on the GPS, even if I have that disabled!