[Xastir] NMEA v2.1 GSA Sentences case very high CPU load

[Curt Mills, WE7U]

On Thu, 6 Mar 2003, Chris Bell wrote:

> I agree we need some status on gps data (what cable just fell out the
> back?).

I just changed it.  We now assume that we have one good position
when we first bring up a GPS interface, whether we're getting good
decoding or not.  We decrement this counter each time we transmit.
When it hits zero and we have any GPS ports enabled, we get a popup
warning us that posits are disabled.

I also put the "Got GPS RMC Sentence" statusline messages under
debug_level 128 control, so you won't see them now unless you're
debugging.


> I have been looking at this gps-cpu issue as well.  My first
> guess at a fix was to limit the gps data to the gps-check-interval.
> It looks like it only checks gps data on the interval, but with a
> dedicated interface (like serial, or gpsd) all the other strings get
> processed at once.  We should flush out the old data, then just
> process one set and go on with life.

My first idea just now was to close the port, and open it when we
want some data.  If we're putting the aprs objects onto a garmin map
screen though, this method won't work.  Best to flush the incoming
data and then snag new strings each time as you said.


> My normal setup uses the second
> port off the kpc3+ to get gps data, so it is polled, and only gets one
> set, which works great.  CPU usage is very low.  When I switched to
> gpsd for a bit, it would queue up ALL the data collected in the
> interval, and try to process it all at once.  Each datapoint created
> more trackpoints, screen updates, and screen status messages.  My P3
> 1Ghz laptop could not keep up.

Interesting.  Add that data to the buglist?

-- 
Curt Mills, WE7U                    hacker_NO_SPAM_ at tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto:    A tax on people who are bad at math!"
"Windows:  Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"