[Announce] ZapLoc - a Gowalla/Foursquare/Facebook places/Latitude aggregator - "All your location based services are belong to us" ;) - Page 22 - maemo.org

Active Topics

The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 17 hrs, 6 mins ago
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 6 days, 5 hrs ago
more...

Page 22 of 35

Thread Tools

MasterZap	2011-06-08 , 05:46
Posts: 214 \| Thanked: 140 times \| Joined on Aug 2010	#211

Originally Posted by woody14619

There is one thing to consider about A-GPS: The liblocation sub-library does send data to sup.nokia.com to ask where it's at given then tower list. Unlike the iPhone, the N900 doesn't cache that info locally to do local look ups. So if the interval is really short it may eat some GPRS data if it's checking A-GPS location every 5 minutes.

Yeah, but these are not many bits... surely if you have an N900 you are on a data plan

Anyway, as clarified above, if you are in wifi, it doesn't even try to start the GPS or celltower stuff at all.

Originally Posted by woody14619

It could be if you don't want to generate the A-GPS data, but still want the auto-checking functionality based on the wifi info.

Oh yeah. I just said "I never *thought* about that as useful", emphasis on "didn't think about that". It's actually quite clever, and I will try to support that in a next version.

Originally Posted by woody14619

I get having the interval to make sure you're not checking into a place if you pass it while walking past it. But I could see a use for allowing no GPS checking at all. If all the places you want to check in have wifi, there's no need to turn on GPS at all. Either you can see the wifi or you can't...

Right. Agreed. I'll do it. Heck, WiFi is actually more useful than cell location (I never really found cell location useful at all, but users explicitly wanted it, so it's in there as an option....)

Originally Posted by woody14619

I was unaware of the option. I'll give it a try to see if I can figure out why it's not working for me with GPS coordinates. I've been auto-checked in a few times now, but only to places where I've set the wifi network as the trigger area. Good news: Wifi based check-in works great! So I'll try the verbose mode, output to a file, to see what it's thinking about and why it's not liking the GPS enough to check me into places.

Yeah, the verbose mode is quite useful for debugging. It was funny, though, if you archeologize through this thread, there was once a bug in that I had - by pure accident - put code that actually did work inside the verbose printout section, meaning... any time you turned on "verbose printout" everything worked... when you turned it off - it stopped working. Quite a debugging aid

That's fixed now, tho.

Originally Posted by woody14619

One question on the wifi checking: Is this based only on the SSID, or do you register the MAC address in some way as well?

It is actually based on what the Maemo "conic" library considers the "id" of the connection. I am not terribly certain what that is, but it is most certainly NOT the SSID (it's some long hex-number, but much longer than a mac adress)

I think it is the number is a database id in the connection database in Maemo (pure guess, though), and if so, maybe, then, if all Starbucks connect to the same Starbucks access point in your phone, there may be problems here, and I will need to start checking Mac's or somesuch (no idea how to do that, though....)

So I personally do not know if this id is per-basestation-unique or not; tests on this would be quite helpful. In "verbose" mode it informs you of any connection/disconnection events including spitting out the stupidly long hex-number-thingy, so if someone who lives somewhere where, say, multiple Starbucks exists, could test this, it would be... useful.

Originally Posted by woody14619

If it's based on MAC, or a combo of the two, that would prevent accidental check-ins.

Right. Unfortunately I don't know the exact meaning of the conic library's "id" number.

Originally Posted by woody14619

One comment: Not sure you're aware of this, but many people who use this are also likely to use a nav app on the phone. More than likely ModRana or NavIt. Both of those have settings to cache the tiles locally on the N900, and are happy to share those tiles with other apps. You may want to look that their threads to see how to access those tiles so you don't have to download them every time.

I do already cache the tiles, and I share the format (basically directory structure under /home/user/MyDocs/.maps/) with what CloudGPS uses. Not sure what ModRana or NavIt uses, though, but it wouldn't surprise me if it is already the same. I'll check those threads out. EDIT: It seems to be the same, so this is already in. Yay.

Originally Posted by woody14619

One small bug I've found: If the GPS fails to lock and I close the app before it locks, the app portion sometimes lives on in the background until kill it off

Interesting. Not sure why it would do that... perhaps a bug in the location subsystem, not liking to be turned off at some certain "point" in it's startup, or something?

I'll check the code, but I think I'm trying to shut the GPS down properly when exiting. Tho if there is an actual crash, my exit code may not always run.

Originally Posted by woody14619

Overall though, this is really a great program! I love the auto-checkin where it works, and even using it as a client to manually check-in most places is really nice thanks to the fluid interface. Very well done.

Thank you sir.

It all started as a toy for myself, and learning som oauth coding, and learning some heavier Python coding..... well frankly, it all started with me trying to teach my kid programming, and beginning work on a game.... (which you guys may see the results of some day... maybe...)

/Z

Last edited by MasterZap; 2011-06-08 at 06:18.

Quote & Reply |

	woody14619	2011-06-08 , 18:58
	Posts: 1,455 \| Thanked: 3,309 times \| Joined on Dec 2009 @ Rochester, NY	#212

Originally Posted by MasterZap

Yeah, but these are not many bits... surely if you have an N900 you are on a data plan

Yes and no.

Not all countries have "all you can eat" plans, so trimming usage is not a bad thing. But you're right in saying this probably won't break the bank. Allowing it to be turned off may be nice though.

Originally Posted by MasterZap

It's actually quite clever, and I will try to support that in a next version.

Happy!

The Wifi check-in part has been working quite well, just FYI.

Originally Posted by MasterZap

there was once a bug in that I had - by pure accident - put code that actually did work inside the verbose printout section,

I've seen that often enough to avoid doing that in code I make. I always make the debug info, and use macros to do the dirty work of logging it. When debugging, the only delta is that a file is opened vs not, and that only happens in the macro-coded area.

That prevents code from not getting called when debugging vs not most times.

Originally Posted by MasterZap

It is actually based on what the Maemo "conic" library considers the "id" of the connection. ... So I personally do not know if this id is per-basestation-unique or not; tests on this would be quite helpful.

I have at least 3 Paneras between home and my summer retreat, all with wifi with the same SSID. I'll check on the way there Friday to see what it says if someone doesn't beat me to it.

On the way back I'll have it registered to connect to see if that makes a difference?

Originally Posted by MasterZap

I do already cache the tiles, and I share the format (basically directory structure under /home/user/MyDocs/.maps/) EDIT: It seems to be the same, so this is already in. Yay.

Yes and no.

In tile mode they do all share. ModRana has a faster method using sqlite to store the tiles in one large file (or sets of large files). They take far less space on the device that way, and are just as quick as file access (faster in some cases). Guess which one I have my ModRana set to...

I may have to switch back to tiles to cache the local area. I may also need to watch what zoom level I'm on, since that may be different between navigating and four-squaring.

If you get ambitious, MartinK does document the format of the table he uses in sqlite to store the tiles. It's rather simple to access, from what I've read. But frankly for the limited area I use ZapLoc in, I can do two sets of tiles.

Originally Posted by MasterZap

Interesting. Not sure why it would do that... perhaps a bug in the location subsystem, not liking to be turned off at some certain "point" in it's startup, or something?

Wouldn't surprise me one bit. The GPS subsystem was clearly not as polished as the rest of the system when in launched, since "A-GPS" wasn't even seeding a rough-guess location to start from in PR 1.0. It's also one of the least used features, right next to the motion detection gizmo in priority. Still, better than the FreeRunner.

Originally Posted by MasterZap

Thank you sir.

It all started as a toy for myself, and learning som oauth coding, and learning some heavier Python coding..... well frankly, it all started with me trying to teach my kid programming, and beginning work on a game.... (which you guys may see the results of some day... maybe...)

Thank you! And if the game is half as good as this app, I'm sure it will be quite popular.

I'll let you know when I have results from the wifi stuff, probably Monday, unless someone beats me to it. Thanks again!

Quote & Reply |

MasterZap	2011-06-09 , 16:22
Posts: 214 \| Thanked: 140 times \| Joined on Aug 2010	#213

Originally Posted by woody14619

Happy! The Wifi check-in part has been working quite well, just FYI.

Build 53 will now allow "WiFi only" positioning. To use it, you must associate each ZapLoc with some wifi network you are connected to there, and then it will only send positions to latitude and/or check in, when you are on those WiFi networks. (Note that you must be *connected* to the network, not just be randomly near it, the conic library deals in connections, not what's in the air around you. I think polling what is in the air around you takes battery power, cpu and time, whereas just acknoweledging the fact that you are connected takes neither)

Originally Posted by woody14619

I've seen that often enough to avoid doing that in code I make. I always make the debug info, and use macros to do the dirty work of logging it. When debugging, the only delta is that a file is opened vs not, and that only happens in the macro-coded area. That prevents code from not getting called when debugging vs not most times.

Right, except I want to avoid CPU load to minimize battery, so I don't even want to *compute* the text when not in verbose mode. Yeah, I'm nerdy like that.

Originally Posted by woody14619

I have at least 3 Paneras between home and my summer retreat, all with wifi with the same SSID. I'll check on the way there Friday to see what it says if someone doesn't beat me to it. On the way back I'll have it registered to connect to see if that makes a difference?

You need to actually connect, as per above.

But debugging of this would be useful (tho I could probably set up a test using an extra router in the house with the same SSID or something... some day... maybe)

Originally Posted by woody14619

If you get ambitious, MartinK does document the format of the table he uses in sqlite to store the tiles.

I'm NOT really feeling THAT level of ambition tingling in me. The tile cache size has never bothered me, since you tend to stick to a rather small area in practice anyway.....

/Z

Quote & Reply |

	woody14619	2011-06-09 , 22:21
	Posts: 1,455 \| Thanked: 3,309 times \| Joined on Dec 2009 @ Rochester, NY	#214

Originally Posted by MasterZap

Build 53 will now allow "WiFi only"

Thanks!

Originally Posted by MasterZap

Right, except I want to avoid CPU load to minimize battery, so I don't even want to *compute* the text when not in verbose mode. Yeah, I'm nerdy like that.

I figured out a while ago that spending 2 or 3 releases trying to find such a bug is generally worth the extra micro-amp it takes to leave the strings in. Back in the day of sub Mhz processors and 64K of ram, it was worth it, but today? But, to each their own.

Variety of style is why we have such different systems already today, and that's a good thing IMHO.

Originally Posted by MasterZap

I'm NOT really feeling THAT level of ambition tingling in me.

Figured as much, but figured it wouldn't hurt to mention it.

So, as for the GPS thing: After watching the debug logs for a while, I think I've figured out what's going on. I think the cell-tower thing is actually hurting my chances, so I'm trying it now with that turned off.

What the log showed was, I would often turn on, get Mode 0 stuff (cell tower), then about 25 seconds in, I'd get a "GPS lock" Mode 3, with either a "error" that was too large (>50m), or I'd get something pretty close, between my actual position and where the cell tower said I last was, but it would commonly be JUST outside the window for the spot (52.5m for a 50m spot).

My best guess is that the first "lock" signal is offset by the system trying to pre-feed the location info from the cell tower location (aGPS), and that's what's killing it. So, I'll try it with that off and see if it takes longer to lock and/or if it comes back with a better first coordinate.

Maybe a good idea would be an option to ask for an update or two from the location system after a lock and see if it eventually stops "moving"? That would also cut down on the "just passing by" issues too maybe?

I'll play with the wifi ID thing later this weekend and post results. Thanks again!

Quote & Reply |

MasterZap	2011-06-10 , 12:50
Posts: 214 \| Thanked: 140 times \| Joined on Aug 2010	#215

Originally Posted by woody14619

I figured out a while ago that spending 2 or 3 releases trying to find such a bug is generally worth the extra micro-amp it takes to leave the strings in. Back in the day of sub Mhz processors and 64K of ram, it was worth it, but today? But, to each their own.

The day we stop caring about every cycle and think "the machine is fast enough" is the day that... well actually that is today, come to think of it. Is your 8 core multi-gigahz computer REALLY faster then that 64k sub Mhz machine?

Originally Posted by woody14619

So, as for the GPS thing: After watching the debug logs for a while, I think I've figured out what's going on. I think the cell-tower thing is actually hurting my chances, so I'm trying it now with that turned off.

You still receive cell towers first, though, that's how the location system works. It'll just ignore them more... as in... when it gives up (after the timeout), it simply rejects a tower sample in GPS-only mode, whereas if cell is checked, it accepts the last sample even if it's a tower when the timeout arrives.

I toyed with some code long ago that basically forces the GPS to take 2 or 3 samples, but took it out. On your message I tested to reinstate it, and noticed that more samples doesn't *necessarily* mean better accuracy, i.e. if I wait for the third sample, it's quite probably the third is worse than the 1st!

So I see two very simple "fixes" to this issue:

ONE: Decrease the "minimum accepted accuracy" (which is currently 150 m and hardcoded) and perhaps make it configurable ... but I don't want to overburden the user with lousy configurations that only nerds care about

or

TWO: When searching for nearest point, add the accuracy to the search, i.e. if it's within 52.5 meters, but your accuracy is 30m, well, consider it a hit anyway.

That has other dangers, but is surely easy to implement.

Originally Posted by woody14619

What the log showed was, I would often turn on, get Mode 0 stuff (cell tower), then about 25 seconds in, I'd get a "GPS lock" Mode 3, with either a "error" that was too large (>50m), or I'd get something pretty close, between my actual position and where the cell tower said I last was, but it would commonly be JUST outside the window for the spot (52.5m for a 50m spot).

I noticed 50m is quite cramped, and 25m may even be useless because the accuracy, even on a good day, is probably worse than 25m.

Originally Posted by woody14619

Maybe a good idea would be an option to ask for an update or two from the location system after a lock and see if it eventually stops "moving"? That would also cut down on the "just passing by" issues too maybe?

See above... I kinda tried that... but... accuracy doesn't by necessity increase.... until after MANY samples... which causes you to have the GPS on longer... which drains battery.... completely counter to the whole idea of this program (NOT to suck battery, if it can avoid it).

Originally Posted by woody14619

I'll play with the wifi ID thing later this weekend and post results. Thanks again!

That would be Most Helpful, thanks.

/Z

Quote & Reply |

	ndi	2011-06-10 , 23:14
	Posts: 2,050 \| Thanked: 1,425 times \| Joined on Dec 2009 @ Bucharest	#216

Originally Posted by MasterZap

The day we stop caring about every cycle and think "the machine is fast enough" is the day that... well actually that is today, come to think of it. Is your 8 core multi-gigahz computer REALLY faster then that 64k sub Mhz machine?

Yes, yes it is. I remember back then I had music as ADPCM WAV because playing MP3 took most of my CPU. I remember 5M/s disk sounded fast. I remember being afraid to move a mouse when writing a CD. I'm running at the same speed, so I still expect some things to take under the accepted no-wait 300 ms - but power? I have that.

As for optimization, it matters where. Some things are better left as they fall, others aren't. On my quad core OC machine I ended up unrolling loops to squeeze the last fraction out of an algorithm. If it's the algo that compares pixels in an image similarity construct that batch-compares all images in a folder to all others detecting similar pseudo-dupes, you better believe it. It has assembler in it.

And what's nerdy about knowing that you have squeezed 2 more ticks out of a loop when sitting on a water cooled, barely-stable, one degree away from failure, billion bytes juggling machine? Nothing I say.

Now if you'll excuse me, I have a grin to wipe off my face.

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

Quote & Reply |

mutanta	2011-06-11 , 20:39
Posts: 1 \| Thanked: 0 times \| Joined on Jun 2011	#217

Hi
When i start the program have message " HTTP Error 400 Bad request

"
Can you help me?

Quote & Reply |

MasterZap	2011-06-13 , 08:04
Posts: 214 \| Thanked: 140 times \| Joined on Aug 2010	#218

Originally Posted by mutanta

Hi
When i start the program have message " HTTP Error 400 Bad request "
Can you help me?

Immediately? On first start??

Strange. I have no idea really

Quote & Reply |

MasterZap	2011-06-14 , 11:48
Posts: 214 \| Thanked: 140 times \| Joined on Aug 2010	#219

Facebook did something to their places search, so I have to search w. a smaller radius for it to work properly. Fixed in build 55, which also allows listing of "homes" on FourSquare (these are otherwise hidden by default). This is off by default, though, change it in the "ZapLoc Checkins" config screen.

Enjoy.

Or not