[Xastir] Re:Xastir and GPS

Curt Mills, WE7U hacker at tc.fluke.com
Tue Mar 18 15:04:17 EST 2003


On Tue, 18 Mar 2003, Mike Fenske wrote:

> Further to my previous questions, I did some testing yesterday with CVS
> from Saturday, March 15. It appears that the GPS check interval is not
> working or I am not understanding it's purpose. With GPS check interval set
> to 20 seconds, I noticed that my position on the map is actually updated
> about every second, which is about the same as how often my gps outputs
> data. In order to reduce the CPU load on my old laptop, I was hoping to
> have Xastir check gps position less often.

Just looked at the code:  Xastir sends a Control-E to an AUX_TNC
interface at the GPS check interval and then sets up for the next
interval.  If you had a KPC-3+ or a dual-port picopacket TNC, you'd
be seeing GPS strings at the check interval due to that Control-E
being sent.  Each Control-E causes the TNC to spit out the GPS
sentences of interest.

With any other kind of GPS interface, the data streams in all the
time and the GPS Check Interval has nothing to do with when the data
is parsed.  It's parsed as it comes in to the computer.  This is the
operation you are seeing.  This probably needs to be changed in
order to support slower laptops and keep CPU usage down.

Option 1) Each GPS port should receive lines of data and store them
in unique storage locations for the type of string, then dump all of
those strings for processing at the GPS Check Interval.  I do
remember though that one type of string in a Garmin can be sent
three times in sequence, and provides info about all satellites that
are in view.

Option 2) Really an implementation of Option 1:  Keep a circular
queue that is large enough to contain all of the unique sorts of
strings that the GPS can send (GPRMC/GPGGA to the next GPRMC/GPGGA
string) and dumps that entire queue (about 10 strings or so) for
processing immediately at the GPS Check Interval.  At other times
it'll just keep overwriting the circular queue with new data and not
process the strings.

Option 3) Dump all GPS data on the ground until the GPS Check
Interval, at which point Xastir grabs and processes all GPS strings
received for about two seconds, then the GPS interfaces start
dumping the data on the ground again.

Option 4) Close the GPS port when we're not actively wanting data.
This might interfere with the TNC_AUX operation and interfere with
sending APRS stations as waypoints to the GPS.  It also can result
in partial sentences being received during the open/close times.

I think option 4 is out.  I like option 2.  It seems the most
appropriate.

We could have the GPS interfaces create queues that are linked into
the port structure, then in main.c:UpdateTime(), run through all of
those queues, flush them out to be processed, then reset the GPS
Check Interval timer.  The GPS interfaces would be busy writing to
the circular queues and wouldn't care whether or when they got read.

-- 
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!"



More information about the Xastir mailing list