[Loadstone] Sean, two feature requests

monty at loadstone-gps.com monty at loadstone-gps.com
Tue Apr 10 20:09:41 BST 2007


Hello Neill,


Thanks for your suggestions and comments.  We definitely try to include 
user suggested functions when possible.  At the moment we are focussing 
most of our time on making Loadstone compatible with Nokia/Symbian
3RD  Edition  handsets but this "big push" will hopefully bear fruit 
sooner than later and we will be able to continue to implement additional 
functionality.

As a short-term solution, have you tried updating the point(s in question 
to the coordinates  you believe are more accurate?  Via the Exploration 
mode, giving the point in question focus, then the pound key.  Once there 
you can either edit the longitude/latitude manually or press Key1 (for 
options) and select "Save using current" to use your current GPS location.

Best regards,
   Monty
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