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
