[Loadstone] Sean, two feature requests

R. Neill Hadder neill.hadder at gmail.com
Tue Apr 10 18:36:44 BST 2007


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.

More information about the Loadstone mailing list