Active Topics
-
The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 14 hrs, 1 min ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 6 days, 2 hrs ago - more...
| The Following User Says Thank You to MasterZap For This Useful Post: | ||
 |
|
2011-05-23
, 20:42
|
|
Posts: 2,050 |
Thanked: 1,425 times |
Joined on Dec 2009
@ Bucharest
|
#122
|
15 seconds is plenty with a-GPS.
Configuration of timeout could be nice, but if it's not locked in 15 secs you probably don't have a-GPS or haven't locked before, meaning the next timeout is the full GPS cycle of 90 seconds plus in perfect conditions, 4-5 minutes under less than ideal. It's a bit on the large side?
Configuration of timeout could be nice, but if it's not locked in 15 secs you probably don't have a-GPS or haven't locked before, meaning the next timeout is the full GPS cycle of 90 seconds plus in perfect conditions, 4-5 minutes under less than ideal. It's a bit on the large side?
__________________
N900 dead and Nokia no longer replaces them. Thanks for all the fish.
Keep the forums clean: use "Thanks" button instead of the thank you post.
N900 dead and Nokia no longer replaces them. Thanks for all the fish.
Keep the forums clean: use "Thanks" button instead of the thank you post.
|
|
2011-05-24
, 05:37
|
|
Posts: 214 |
Thanked: 140 times |
Joined on Aug 2010
|
#123
|
Originally Posted by ndi
Yes, 15 seconds is plenty with good reception, I "normally" get a fix within about 5 seconds (or as little as 3). But since my code does have a 15 second timeout (where it then reverts to the cell tower location), and I've found that, sometimes, I still get cell-towers (maybe when the phone is in my pocket or whatnot), clearly 15 seconds isn't quite enough.
15 seconds is plenty with a-GPS.
Configuration of timeout could be nice, but if it's not locked in 15 secs you probably don't have a-GPS or haven't locked before, meaning the next timeout is the full GPS cycle of 90 seconds plus in perfect conditions, 4-5 minutes under less than ideal. It's a bit on the large side?
I will probably be adding a third mode that is "Always use GPS", which has the same logic and timeouts, but simply will *never* use a cell location, simply not posting any update at all if it didn't get a "gps quality" fix within the timeout. Then you, as a user, have the choice suitable for your environment, i..e
- very urban (New York city-canyons and offices): Cell only
- medium (smaller city with some open spaces): Cell+GPS
- rural (nearly always good gps fixes): GPS only
Should be a trivial change.
/Z
|
|
2011-05-24
, 06:53
|
|
Posts: 214 |
Thanked: 140 times |
Joined on Aug 2010
|
#124
|
Hi Guys, a question:
I think I may have been a bit too paranoid with the Daemon settings in the UI of ZapLoc.
I'm starting to think of changing it like this:
- default "Background Updates" to off (I still think I need to have somethign like this off by default so people are always aware when they turn it on... or do you think people is smart enough to realize this anyway? I don't want to get liable for my app sharing stuff people didn't want....)
- remove the settings of "when to start" and "when to stop" the daemon.
The new logic would be:
- if "background updates" is on, daemon starts at boot and never stops
- If "background updates" is off, daemon either a) doesn't run at all, or b) just runs while the main program is visible.
My questions to you:
#1 Does this change make sense?
#2 Should it do a) or b) for "background updates"=Off mode?
I just realized I was being overzealous here: For example, "auto checkins" and "latitude updates" are ALSO both off by default. Lots of stuff to turn on before it actually works
/Z
Last edited by MasterZap; 2011-05-24 at 06:56.
I think I may have been a bit too paranoid with the Daemon settings in the UI of ZapLoc.
I'm starting to think of changing it like this:
- default "Background Updates" to off (I still think I need to have somethign like this off by default so people are always aware when they turn it on... or do you think people is smart enough to realize this anyway? I don't want to get liable for my app sharing stuff people didn't want....)
- remove the settings of "when to start" and "when to stop" the daemon.
The new logic would be:
- if "background updates" is on, daemon starts at boot and never stops
- If "background updates" is off, daemon either a) doesn't run at all, or b) just runs while the main program is visible.
My questions to you:
#1 Does this change make sense?
#2 Should it do a) or b) for "background updates"=Off mode?
I just realized I was being overzealous here: For example, "auto checkins" and "latitude updates" are ALSO both off by default. Lots of stuff to turn on before it actually works
/Z
Last edited by MasterZap; 2011-05-24 at 06:56.
|
|
2011-05-24
, 07:15
|
|
Posts: 210 |
Thanked: 37 times |
Joined on Nov 2010
|
#125
|
how can I add a new place? 
|
|
2011-05-24
, 07:18
|
|
Posts: 214 |
Thanked: 140 times |
Joined on Aug 2010
|
#126
|
Originally Posted by amadeukaos
You can't... this is a consumption app, not a creation app.
how can I add a new place?
For Gowalla, I suggest m.gowalla.com
For FourSquare I suggest www.cotchin.com/m
For Facebook Places I don't know what to suggest any more, in the past touch.facebook.com worked on the N900, but Facebook has removed that site in favour of a crappy mobile site
Maybe someone has a tip how to add facebook places on the N900?
/Z
 |
|
2011-05-24
, 07:20
|
|
Posts: 168 |
Thanked: 206 times |
Joined on Apr 2010
@ Finland
|
#127
|
Thanks for the great application!
Should I have several zaploc-daemon.py running parallel? After 1st start I have.
After each start of ZapLoc there will be a new zaploc-daemon.py running in addition to old ones. Does not matter if background updating is set to stop when app closes or not. Battery drain is also quite huge after enabling Zaplog even updates should happen in every 30min. Drain remains also after disabling background updates.
Last edited by Gusse; 2011-05-24 at 07:23.
Should I have several zaploc-daemon.py running parallel? After 1st start I have.
~ $ ps -w|grep zap*
18575 user 125m S /usr/bin/python /opt/zaploc/zaploc.py
18609 user 50072 S /usr/bin/python /opt/zaploc/zaploc-daemon.py -d
19116 user 50072 S /usr/bin/python /opt/zaploc/zaploc-daemon.py -d
19150 user 50072 S /usr/bin/python /opt/zaploc/zaploc-daemon.py -d
Last edited by Gusse; 2011-05-24 at 07:23.
|
|
2011-05-24
, 08:12
|
|
Posts: 650 |
Thanked: 497 times |
Joined on Oct 2008
@ Ghent, Belgium
|
#128
|
Originally Posted by MasterZap
For me, enable/disable daemon is more than enough, and in that context in OFF mode it should do b) - only update while the program is active....
The new logic would be:
- if "background updates" is on, daemon starts at boot and never stops
- If "background updates" is off, daemon either a) doesn't run at all, or b) just runs while the main program is visible.
My questions to you:
#1 Does this change make sense?
#2 Should it do a) or b) for "background updates"=Off mode?
I understand you're looking for new stuff to work on, but for me ZapLoc is good as it is
Or maybe.... you could add an option to let it behave like Android. On Android, latitude is updated more frequent and using GPS when you are moving. But I'd probably never use this anyway
__________________
Affordable mobile internet in Belgium: Try Mobile Vikings
2 GB, 1000 SMS and 15 euro of talk time for.... 15 euro
Affordable mobile internet in Belgium: Try Mobile Vikings
2 GB, 1000 SMS and 15 euro of talk time for.... 15 euro
|
|
2011-05-24
, 09:05
|
|
Posts: 13 |
Thanked: 1 time |
Joined on Feb 2010
|
#129
|
Originally Posted by MasterZap
Short answer:
- if "background updates" is on, daemon starts at boot and never stops
- If "background updates" is off, daemon either a) doesn't run at all, or b) just runs while the main program is visible.
Makes perfect sense in my opinion, this is how I would expect it to work and I bet everyone already has it configured this way.
I would go with mode b).
Long answer:
There are two separate cases in mode b):
- If you don't have the background daemon running, you are probably starting the main program in order to update your position and to see the map/check in - daemon should be on while the main program is running.
- If you already have the daemon running, you are probably starting the main program to see the map and/or check in - in this case the daemon should either:
b1) keep the same settings it had in background mode, or
b2) restart with the default settings
My humble (and possibly too laborious) suggestion is:
Keep the background daemon and the main program daemon separate from each other. When the user starts the main program, you could suspend the background daemon until the main program is closed. The settings should be separate as well, as the use cases for using the background daemon and running the main program are typically rather different.
|
|
2011-05-24
, 09:06
|
|
Posts: 214 |
Thanked: 140 times |
Joined on Aug 2010
|
#130
|
Originally Posted by Gusse
No, this should not happen. Which build are you running? Are you starting it from the icon or command line? And if from the command line, are you "user" or "root" when doing so?
Thanks for the great application!
Should I have several zaploc-daemon.py running parallel? After 1st start I have.
After each start of ZapLoc there will be a new zaploc-daemon.py running in addition to old ones. Does not matter if background updating is set to stop when app closes or not. Battery drain is also quite huge after enabling Zaplog even updates should happen in every 30min. Drain remains also after disabling background updates.
/Z
I can quite trivially add a switch in the configuration for that, or a keyboard toggle, or whatever.
I should probably increase that a little, 15 seconds is pretty tight... it's okay when you have good signal (like I have out on the countryside where I live) but in a tighter scenario it's probably touch-and-go. I will increase this timeout.
/Z