[Loadstone] Sean, two feature requests

Shawn Kirkpatrick shawn at odyssey.cm.nu
Wed Apr 11 02:42:25 BST 2007

You bring up an interesting point regarding database accuracy. Since our 
database is compiled from various free sources the accuracy of points will 
probably vary a bit. Some points will probably be very accurate, being 
entered from data gathered with much better equipment than we have, others 
will be user entered, the accuracy will depend on the user's gps receiver 
and where they were when the point was marked. Other points, like the street 
intercections, are computed. The accuracy of these will depend on the 
accuracy of the data used to run the calculations. Will all this I'm not 
sure you'd be able to come up with a constant correction factor that would 
work. For every point you corrected you'd throw others off. In three years 
of working with this thing I've never seen any pattern to the error that 
could be applied consistantly.
I'll have to do some experimenting with the disconnection timeout and see if 
something better can be worked out.
As for the gps commands not working, I meant the commands in the gps 
commands menu, cold start, warm start, etc. The specification of what the 
gps receiver sends out is very well defined and documented. This isn't the 
case for what you're supposed to send to the gps receiver thoe. Every 
manufacturer can pretty much do whatever they want for this and they don't 
always document things. I'd be curious to know if any of the commands work 
on your receiver since you said it uses the mtk chipset. From what I 
understand that chipset uses different commands from the sirf chipset. The 
best command to try would be the cold start command when you have a gps 
signal. If this works you should have to wait a while before you reaquire 
the signal again. The hot and warm start commands would be a lot harder to 
verify. They might appear to work since loadstone resets itself when any of 
the  start commands are issued. In that case you'd probably get a no signal 
message followed almost right away by a signal acquired message.
This doesn't mean the command actually did 
anything to the receiver thoe. We hope to fix all this in a future version 
as more documentation about the various chipsets is found.

On Tue, 10 Apr 2007, R. Neill Hadder wrote:

> Sean,
> Well, first I do appreciate this well-articulated reply.  Regarding your
> reasons why a move point function wouldn't help much, I am aware of all the
> factors you mention but disagree, at least from my casual userly
> perspective, on whether "not much" would constitute a useful amount.  If I'm
> liable to be drifted several meters off in any direction as I pass a point,
> the fact remains that I can pull that point consistently several meters a
> little closer to reality with a flick of the numbers, and that amount can be
> up to one side of the street versus another.  I could pull it in far enough,
> for example, that it'd overcomes average drift without getting mixed up with
> other urban features.  If I go down a street five times and twice I'm
> reported to be 17 meters to the left  of the actual building I'm passing and
> twice I'm ostensibly 3 meters to the left of it and the other time I'm right
> on it, I can pretty much determine that the time it was on target was a
> statistical outlier and the point in the database is really someplace in the
> middle of the street a few meters to my right.  The points entered from
> Google Maps are more accurate because it might still be trash out but wasn't
> trash in.  Naturally I understand that y'all have to set your priorities,
> but my vote is that it would be worthwhile to see if others get favorable
> results that might surprise you, even though the drift and parallel track
> phenomena aren't going away.  My sense from using the equipment is that "not
> much" might also be "somewhat helpful," which would count.  Possibly a
> PC-side little program to do the math and some manual editing of the
> database before putting it back on the phone would be a simple way to test
> this?  Regarding receiver disconnects, maybe increasing the timeout or
> putting a timeout option in the Settings dialog would work around the issues
> you list regarding how it would cause problems for certain other receivers.
> Blaming the phone might be entirely correct, but hey, we're stuck with these
> Nokia phones for now and seems like the software should at least try to
> implement some flexible workarounds that might be set differently by the
> user for different phones.  If you disagree, then I won't press the issue.
> Disconnect timeout would likely be a good candidate, just like static
> threshholding was.  BTW: another need is for Loadstone to check whether
> bluetooth is active before attempting to connect to the default receiver,
> and if it's not, it would be helfpul if it asked "Bluetooth is currently
> switched off.  Switch on?" the way several other programs do.  On my setup,
> if I forget to turn bluetooth on before running loadstone and then turn it
> on or even exit loadstone and come back in, what happens is that Loadstone
> will say "not connected" when I hit a cursor key but will say "already
> connected" when I tap on "Connect GPS receiver" and of course there's no
> "disconnect" option in the menu at this point.  So I have to reboot
> everything, which of course takes a couple of minutes on a noisy downtown
> street corner with me trying to plot an alternate route to get away from the
> nut case screaming at the top of his lungs at the end of the block, or to
> get away from the loose dogs going after my dog, both of these being
> incidents that happened last week.  This behavior--the loadstone behavior,
> that is-- has been true with two different brands of receivers and two
> different chips.  The human and dog behavior goes back thousands of years.
> Finally, I hadn't notice the gps commands not working on my I-blue 737:
> number of satelites, position information, and hot start do seem at least to
> work, judging from appearances.
> From: Shawn Kirkpatrick <shawn at odyssey.cm.nu>
> Subject: Re: [Loadstone] 2 requests: move point and reconnect
> To: loadstone at loadstone-gps.com
> Message-ID: <Pine.LNX.4.63.0704091807150.12249 at odyssey.cm.nu>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> I'll try to address both your points. First, I don't think that moving a
> point would help your problem very much. There's at least two factors
> effecting this. The first is the accuracy the point was saved with. The
> second is the accuracy of your gps receiver at the current time. Let's
> assume a perfect point accuracy for the moment and deal with the receiver
> accuracy. There are several conditions that'll effect this, the number of
> satellites, surrounding buildings etc. No matter what you do you'll still be
> subject to the gps drift when standing still. If your receiver is waas/egnos
> capable and you get a differencial gps fix then this drift can go down to as
> low as one metre. Otherwise, around 10 metres of drift is about normal. You
> could test this by standing still and hitting the select key to see how much
> the closest point drifts. Some receivers are better for this than others.
> Taking all this in to account moving a point probably won't fix things much.
> You could move a point 10 metres one way and it might be accurate for that
> moment but then it's just as likely to drift 10 metres the other way 30
> seconds later. When you're on the move this situation should be a lot better
> since the drifting isn't as much of a problem.
> The disconnecting problem could be a bit tricky. The clock tick logic was
> implemented because some receivers when there batteries die can get to a
> point where the receiver isn't sending gps data but can still keep the
> bluetooth connection open. To fix this loadstone will disconnect if it
> hasn't heard from the receiver in over 5 seconds. In normal opperation this
> isn't a problem, normally the receiver will send data once per second. If
> your receiver is getting in to a state where it's sending data slower than
> that then this might be causing it to disconnect. This might also account
> for your accuracy problems if the data isn't caught up to where you actually
> are. Maybe the receiver has some kind of power saving mode? You'd have to
> look up information on that unit to find out if that's the case. If that's
> the case then it would be good to turn that mode off. There's a couple other
> situations where the receiver can be disconnected. The first is during long
> searches with the find point function. This is a bug and at some point that
> searching system is going to get a rewrite to hopefully fix things like
> this. The other reason the receiver can disconnect is if you're in an area
> with a lot of rf interference. This can be an area with a lot of computer
> equipment, other bluetooth devices, or something else generating radio
> interference that knocks out the connection. There's not a whole lot you can
> do in that situation. If the gps disconnects consistantly in an area then
> this is probably the reason. The only thing you might be able to do in that
> case is move the receiver closer to the phone. Another problem could be
> glitches in the bluetooth implementation in your phone or gps receiver.
> Nokia is well known for breaking things in there bluetooth implementations.
> In that case a firmware upgrade for the phone might help.
> As to what can be done to fix this problem, maybe a few tweaks to the timing
> logic, maybe increasing the timeout to 10 seconds might work. I don't think
> trying to write a command to the receiver would be a good idea. If it really
> has disconnected then the program could end up in a long wait trying to
> write resulting in a write failure at the end. If the battery is dying but
> the bluetooth connection is still open then the write might appear to go
> through but have no effect. If the receiver has entered a low power state of
> some kind then a hot start may or may not bring it out of that mode. For
> that case a better solution would be to figure out how to get the receiver
> not to go into that mode in the first place. Trying to reconnect might work
> but presents its own problems. If the gps really is disconnected then you
> end up with a long wait and a connection error. The other problem is it
> seems to take a while for the phone to register the fact that a bluetooth
> connection really is gone. This isn't only happening for loadstone, on my
> n70 this happens for headsets and any other type of bluetooth connection.
> Trying to reconnect during this period results in an error. This seems to be
> phone dependant so would be kind of hard to work around.
> Speaking of commands, you've probably noticed that none of the gps commands
> work with a gps receiver using the mtk chipset. This is a known issue, the
> commands are currently for the sirf chipset. We plan to implement a setting
> to set the chipset so the propper commands will get sent.
> _______________________________________________
> Loadstone mailing list
> Loadstone at loadstone-gps.com
> http://www.loadstone-gps.com/mailman/listinfo/loadstone

More information about the Loadstone mailing list