>
> * LeeE -- Monday 14 April 2008:
> > I'm running a nasal loop at 1/(frame-rate/2), which typically works
> > out to between 10-20 Hz, but because the gps update rate is much
> > slower (0.45 sec if I'm interpreting the code correctly) the
> > results aren't very smooth - the effect is that
So summarising the current state of play - research seem to show
that gps units can have update rates of 50Hz+ but cost a lot of
money.
In view of that it seems reasonable to make the FG gps update rate
configurable - that was the main purpose of researching it - I
didn't want to make it confi
On Monday 14 April 2008 18:55, Melchior FRANZ wrote:
> * Curtis Olson -- Monday 14 April 2008:
> > Let's say I want to do a simple moving average ... so the new
> > value is (let's say) 9 parts the previous filtered value + 1
> > part of the latest sensor reading. Doing that as a simple
> > averag
On Mon, Apr 14, 2008 at 2:01 PM, Mike Schuh <[EMAIL PROTECTED]> wrote:
> On Mon, 14 Apr 2008, Melchior FRANZ wrote:
>
> >* Curtis Olson -- Monday 14 April 2008:
> >> Let's say I want to do a simple moving average ...
> >
>
> >FlightGear has an aircraft.angular_lowpass() in $FG_ROOT/Nasal/aircraf
On Mon, 14 Apr 2008, Melchior FRANZ wrote:
>* Curtis Olson -- Monday 14 April 2008:
>> Let's say I want to do a simple moving average ...
>
>FlightGear has an aircraft.angular_lowpass() in $FG_ROOT/Nasal/aircraft.nas.
>It filters sin() and cos() separately, and builds the angle from that again.
T
* LeeE -- Monday 14 April 2008:
> I'm running a nasal loop at 1/(frame-rate/2), which typically works
> out to between 10-20 Hz, but because the gps update rate is much
> slower (0.45 sec if I'm interpreting the code correctly) the
> results aren't very smooth - the effect is that the results fo
On Mon, Apr 14, 2008 at 12:55 PM, Melchior FRANZ wrote:
> * Curtis Olson -- Monday 14 April 2008:
> > Let's say I want to do a simple moving average ... so the new value is
> > (let's say) 9 parts the previous filtered value + 1 part of the latest
> > sensor reading. Doing that as a simple averag
* Curtis Olson -- Monday 14 April 2008:
> Let's say I want to do a simple moving average ... so the new value is
> (let's say) 9 parts the previous filtered value + 1 part of the latest
> sensor reading. Doing that as a simple average though will glitch if your
> values are coming in around 0/360.
On Mon, Apr 14, 2008 at 11:29 AM, LeeE wrote:
> Oops - meant an exponential filter - seems to work ok, except for
> the inevitable glitch between 360/0 deg (I'm using
> indicated-track-true-deg) but then it resolves in 0.45 sec, which
> isn't too bad. The lag affected a couple of controllers but
On Monday 14 April 2008 15:47, LeeE wrote:
> On Monday 14 April 2008 15:09, Curtis Olson wrote:
> > On Mon, Apr 14, 2008 at 8:38 AM, LeeE wrote:
> > > I've been doing some experimentation using the gps instrument
> > > for navigation functions but I've hit a minor problem due to
> > > the gps instr
http://www.k300performance.co.uk/driftbox.htm
may be of interest and is a little more affordable, possibly around 1000 of
your US dollahs
Best Regards
Willie Fleming
-
This SF.net email is sponsored by the 2008 JavaOne(SM
On Monday 14 April 2008 15:09, Curtis Olson wrote:
> On Mon, Apr 14, 2008 at 8:38 AM, LeeE wrote:
> > I've been doing some experimentation using the gps instrument
> > for navigation functions but I've hit a minor problem due to
> > the gps instrument update rate.
> >
> > I'm running a nasal loop a
On Mon, Apr 14, 2008 at 8:38 AM, LeeE wrote:
> I've been doing some experimentation using the gps instrument for
> navigation functions but I've hit a minor problem due to the gps
> instrument update rate.
>
> I'm running a nasal loop at 1/(frame-rate/2), which typically works
> out to between 10-
13 matches
Mail list logo
