[Loadstone] 2 requests: move point and reconnect

Shawn Kirkpatrick shawn at odyssey.cm.nu
Wed Apr 11 02:46:17 BST 2007

You get this message if loadstone hasn't received anything from your gps 
receiver in over 5 seconds. Normally your receiver should be sending data 
every second.

On Tue, 10 Apr 2007, Mikolaj Rotnicki wrote:

> I wonder if the info provided on the disconnection issue refers to "Gps
> clock seems to have stopped ticking..."?
> I experienced the message "GPS clock seems.." few times with my newly bought
> Wintec WBT-300 based on Antaris 4 uBlox chipset.
> It happened suddnly in normal operation. I wonder what might be reason fr
> that. I also have a Nokia LD-3W - but I did not experience that problem.
> What does "Gps clock seems to have stopped ticking..." message mean?
> Does it mean  that there is something wrong with GPS module or it's BT
> connectivity?
> What exactly (from application point of view) causes LS to show Gps clock
> seems to have stopped ticking.." message?
> I also tried WBT-300 with other GPS aplications (AFTrack, TomTom5) and did
> not observe any connection loss.
> Are there any LS users haveing Wintec WBT-300 receiver and experiencing same
> problem?
> Would it be helpful if I send a log file to the LS developpers?
> -----
> Mikolaj Rotnicki
> ----- Original Message -----
> From: "Shawn Kirkpatrick" <shawn at odyssey.cm.nu>
> To: <loadstone at loadstone-gps.com>
> Sent: Tuesday, April 10, 2007 3:49 AM
> Subject: Re: [Loadstone] 2 requests: move point and reconnect
>> 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.
>> On Mon, 9 Apr 2007, R. Neill Hadder wrote:
>>> Hi guys,
>>> A 2-item wish list:
>>> 1) it seems like it would be possible to implement a "move current point"
>>> feature to help counteract the tendency to be say 10m off when you're
>>> walking along setting waypoints and then another 10m off, possibly the
>>> other
>>> direction, when you're going back through.  I constantly wish I could
>>> just
>>> "fix" a point, literally, when I find myself on the wrong side of the
>>> street
>>> from what the unit was reporting should be the case: 3 o'clock is as
>>> likely
>>> to really be 9:00 as not, within 12 meters, and only trigonometrically
>>> better at greater distances.  I'm sure moving a point x meters in a
>>> cardinal
>>> direction or clockface orientation translates into some decimal value of
>>> milliseconds in the coordinates.  I have a hunch that a little routine to
>>> accept input and make this calculation could double the tracking
>>> accuracy.
>>> Discussion welcome.
>>> 2) As I noted in my comments on the i-blue 737, there's some fairly
>>> common
>>> if not random condition that prompts the gps receiver to stop sending
>>> data
>>> to the phone, even though it's still actively tracking umpteen satelites.
>>> Loadstone disconnects, but can reconnect within a couple of seconds. I
>>> would
>>> like to try a setting that allows loadstone to try an automatic hot start
>>> before disconnecting.  Even if it's a low battery or low bluetooth signal
>>> issue, this would be helpful.  Invariably, the one time that I really
>>> need
>>> it in a high-traffic urban environment, the gps will go out and I am
>>> stuck
>>> fiddling with things, possibly for a prohibitive period of time.  Seems
>>> like
>>> it's worth a try.  Again, my own experience is with the 6682 and mtk.
>>> Gracias.
>>> --Neill
>>> _______________________________________________
>>> Loadstone mailing list
>>> Loadstone at loadstone-gps.com
>>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>> _______________________________________________
>> Loadstone mailing list
>> Loadstone at loadstone-gps.com
>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>> --
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.446 / Virus Database: 269.0.0/754 - Release Date: 2007-04-09
>> 22:59
> _______________________________________________
> Loadstone mailing list
> Loadstone at loadstone-gps.com
> http://www.loadstone-gps.com/mailman/listinfo/loadstone

More information about the Loadstone mailing list