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 instrument update rate.
> > >
> > > 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 follow a sawtooth pattern i.e. they ramp up
> > > while the gps output is unchanged but then drop back down
> > > when the gps output is updated, and then start to ramp up
> > > again.
> > >
> > > Increasing the gps update rate to 0.1 sec in instrument_mgr
> > > helps to smooth the output because each 'tooth' is smaller,
> > > with the result that each ramp-up and drop-back is similarly
> > > reduced in size.
> > >
> > > What I was wondering though, is what is the max update rate
> > > for NAVSTAR gps receivers?
> > >
> > > I dug out my Garmin e-trex manual, because I knew that had a
> > > battery save mode that reduces the  update rate but it only
> > > says that the unit will update once per second or
> > > 'continuously'.
> > >
> > > After a bit of digging around on the web I found a discussion
> > > where it was stated that "The theoretical limit is down to
> > > the integration time for the receiver, typically 1-10ms" but
> > > the practical limit turns out to be more down to the
> > > receiver's processing power.
> > >
> > > Does anyone else here know anything about this?
> > >
> > > Ideally, I'd like to make the gps update rate configurable -
> > > can anyone foresee any problems in doing this?
> >
> > I don't know specific update rates for every device, but my
> > understanding is that a typical consumer handheld device will
> > update every 1-2 seconds.
> >
> > I have a u-blox gps on my UAS and that updates at 4hz.  I've
> > seen other gps units that update at 5hz, but I've heard it's
> > almost, but not quite 5, so you end up closer to 4hz anyway.
> >
> > I have seen some trimble differential units that update at
> > 10hz, but those are starting to get really expensive.
> >
> > I wouldn't be surprised to find an inertially augmented system
> > that could report approximate locations at much higher rates. 
> > My UAS flight computer computes position estimates at 10hz
> > based on a 4hz gps + gyro & accelerometer data.  I could
> > probably bump that up to a higher rate if I wanted to.
> >
> > So a true 0.1sec update interval is plausible, but expensive
> > and probably not characteristic of the typical gps you would
> > see on an aircraft.  But I could be way off on that ... (?)
> >
> > Regards,
> >
> > Curt.
>
> In the discussion I found (on www.dsprelated.com) one person said
> they'd seen 20Hz units, but they cost US$2/3K, and they knew of
> 50Hz units which were much more expensive.  Another poster
> reckoned that he'd been using an automotive unit that seemed to
> be limited by it's 60MHz 32bit MIPS cpu and maxed out at around
> 10Hz.  I also found an automotive racing company that did 10Hz &
> 20Hz units - no prices but I'd guess they'd be in the several
> thousand US$ range too.
>
> For a pro racing car or military aircraft I'd guess a few
> thousand US$ is ok but it might be a bit steep for GA.
>
> Perhaps another possibility is to use a noise spike filter with a
> 0.45 resolution time to smooth the output between the 0.45 sec
> updates but this would mean that the data is always going to be
> 0.45 sec late.  This might be less of a problem than the
> roughness in the output though - I'll have to play with it.
>
> LeeE

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 they 
were easily re-tuned.

LeeE

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to