[Loadstone] Sean, two feature requests

Charlie Richardson charlieofalbany at hotmail.com
Wed Apr 11 00:16:15 BST 2007


I tried walking pass a point I marked previously and found the first pass 
said 7 yards at it's closest point.  I passed a second time to come within 
12 yards of that point and a third time at 8 yards.  I couldn't get any 
closer moving back and forth in a straight line.  Truthfully for what I 
marked that point for I was still in front of the store that I marked.  A 
few yards off here and there isn't making the difference.  I've thought 
about a different receiver with better accuracy, but then wondered what I 
would do with being 1 to 3 yards away from a point as oppose to 7 to 12 
yards.

As far as the error of the software saying not connected and already 
connected at the same time I've found that removing the battery from both 
units for a few minutes and replacing them relieves the problem.  Sometimes 
it takes more than a couple minutes, but I'm not going to be stuck on a 
street corner trying to fix my GPS.  I take the batteries out and get around 
like I did before having Loadstone.  We should try not to become too 
dependent on technology and remember the old fashion ways of getting things 
done.


----- Original Message ----- 
From: "R. Neill Hadder" <neill.hadder at gmail.com>
To: <loadstone at loadstone-gps.com>
Sent: Tuesday, April 10, 2007 1:36 PM
Subject: Re: [Loadstone] Sean, two feature requests


> 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