[Loadstone] Direction fix mode

Shawn Kirkpatrick shawn at odyssey.cm.nu
Mon Dec 3 06:28:18 GMT 2007


I'm not sure what this would get you. By the time the error has been figured 
out it's already gone passed. Unless the data was delayed enough to try to 
get rid of any errors. That unfortunately kills real time response.

On Mon, 3 Dec 2007, Stephen  Bennett wrote:

> Hi All
>
> Perhaps an off-shoot of this is the idea that we could eliminate
> multi-path by taking readings of the traveller's direction and screening
> out any that are just way off beam. Does this sound feasible?
>
> For example, if I've been going north or thereabouts for ten seconds
> then southwest for two seconds then north again for ten seconds the
> system could safely decide that the southwest was a multi-path and could
> be ignored.
>
> All the best
>
> Stephen
>
>
> -----Original Message-----
> From: loadstone-bounces at loadstone-gps.com
> [mailto:loadstone-bounces at loadstone-gps.com] On Behalf Of Shawn
> Kirkpatrick
> Sent: Monday, 3 December 2007 1:19 p.m.
> To: loadstone at loadstone-gps.com
> Subject: Re: [Loadstone] Direction fix mode
>
>
> After giving this some more thought I think what we're talking about is
> reinventing static navigation mode. The problem is like this: assume a
> walking speed of 4 kilometers per hour, that translates to just
> over 1 meter per second. Unfortunately that value is well within the
> drift
> for most receivers. Trying to compensate for that would mean knocking
> out
> speeds below the drift range and that would be pretty much all walking
> speeds. Waiting until a certain distance had gone passed might work but
> would result in intermitant speed readings. You'd only get a reading
> when
> the distance had been met and then it would drop back to 0 until the
> next
> calculation. If we assume that on a good day the receiver's drift radius
> is
> 8 meters then that means you'd only get a speed reading every 8 seconds,
> the
> rest of the time it would be 0. That's not a good situation at all. I
> think we'll have to see the results of software heading and speed
> calculations before we can think of how to fix the drift problem. There
> probably just isn't a good way around this, if the receiver's sending
> bad
> position data then there's no accurate way of correcting it.
>
> On Sun, 2 Dec 2007, Jurgen wrote:
>
>>> The biggest
>>> problem I can see with this would be a slow response
>>> at low speeds.
>>
>> Thats the point! A slow responce that is useful is much beter then a
>> useles fast one.
>>
>> And the ones who want to have the fast useles function, can set the
>> value to zerro - and gon!
>>
>> There is a possibility to find a better way, but it is combined with
>> collecting positions in a circle buffer with variable size. And I
>> think, it is much to complicated for this problem
>>
>> And for Your argument, that GPSReceivers would have this ...
>>
>> for the first, GPS for walkers still is not the main market. And there
>
>> is a big problem for the producers of receivers. Thay have to be
>> compatible to NMEA standard to fid then neets of the market and to
>> feed LS ;-). So they can only support, what NMEA can transport. there
>> is no NMEA data set, that can communicate, how the direction is
>> calculated. It's  the same problem as the one, that we don't get
>> information about battery status. deo You think, this is because  it
>> is so complicated to calculate battery status?
>>
>> J.
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> Loadstone mailing list
> Loadstone at loadstone-gps.com
> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>


More information about the Loadstone mailing list