<html>
<font size=3>Some sort of user definable track smoothing would be
possible, we've seen that from the data gathered during the '3 receivers
test'. In fact, looking at the RTB the jumping around of heading is not
so bad at all in our test. Having said that, every receiver comes with
its own set of DOP masks as set by the manufacturer and you never know
what they are, since GPS receivers makers seem to be extremely careful
supplying this kind of data. It means, that every receiver needs its own
approach. Also I found that some receivers apply their own track
smoothing algorithms, so go figure. <br><br>
At 10/22/2007, you wrote:<br>
<blockquote type=cite class=cite cite>The position data from the receiver
is usually only about a second behind, <br>
maybe less. The speed data is maybe 2 seconds behind. I don't think
there's <br>
any way around this since you need some data to calculate speed. Since
the <br>
speed and position are both being provided by the receiver I doubt you
could <br>
use speed to correct position.<br>
At some point there will be software calculations for heading and speed
but <br>
that'll be to correct for those receivers that have proven almost useless
<br>
for pedestrian use. Those receivers seem to give accurate position data
<br>
thoe. If we had another source of data then maybe correction factors
could <br>
be applied.<br><br>
On Tue, 23 Oct 2007, Hasan Karahasan wrote:<br><br>
&gt; Hi folks,<br>
&gt; we all know that a gps based system takes some time to react on any
changes.<br>
&gt; When you are standing, yourr speed will be zero at optimal gps
conditions.<br>
&gt; When you suddenly start to move, the system needs several seconds to
notice<br>
&gt; this and to offer the correct data. This happens to any change.
The<br>
&gt; receiver's data is always some seconds behind the real data. Can we
improve<br>
&gt; that indolent and sluggish behaviour by doing some prediction? I am
sure<br>
&gt; that commercial software does similar things. We could do this
by<br>
&gt; calculating an acceleration factor. While one thread measures the
speed and<br>
&gt; calculates the accelleration periodically, another thread uses the
result to<br>
&gt; correct the receiver's position permanently. If speed is in an
increasing<br>
&gt; state, we know that the real position is more towards our current
direction.<br>
&gt; We can add some meters to the receiver's position.<br>
&gt; If speed is decreasing, we can subtract something from the
receiver's data.<br>
&gt; All loadstone functions would benefit from such a correction.<br>
&gt; What do you think about this?<br>
&gt;<br>
&gt; Hasan<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Loadstone mailing list<br>
&gt; Loadstone@loadstone-gps.com<br>
&gt;
<a href="http://www.loadstone-gps.com/mailman/listinfo/loadstone" eudora="autourl">http://www.loadstone-gps.com/mailman/listinfo/loadstone</a><br>
&gt;<br>
_______________________________________________<br>
Loadstone mailing list<br>
Loadstone@loadstone-gps.com<br>
<a href="http://www.loadstone-gps.com/mailman/listinfo/loadstone" eudora="autourl">http://www.loadstone-gps.com/mailman/listinfo/loadstone</a>
</font></blockquote></html>