[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gpsd-users
Subject:    [Gpsd-users] gpsd-2.18 is out -- major interface restructuring
From:       esr () snark ! thyrsus ! com (Eric S !  Raymond)
Date:       2005-03-23 20:08:36
Message-ID: 200503232008.j2NK8apN016930 () snark ! thyrsus ! com
[Download RAW message or body]

I just released 2.18.  There are a couple of pending bugs -- last I
heard from Gary Miller the Garmin driver was busted again -- but this
new release should be stable enough for use on the 80%+ of SiRF 
GPSes out there and give us a good place to stand in chasing down
the reported bugs.

The user-visible changes in this release are (a) that the data 
structures visible if you use libgps have changed, and (b) watcher
mode now reports using the new 'o' command.  Underneath this, there
are significantly larger changes.

What I have done, essentially, is re-orient the architecture towards
chipsets that can deliver an entire update (position, time, velocity,
and estimated errors) in one sentence or packet. (This class 
includes SiRF, Zodiac, and Garmin-binary GPSes.) There is now just 
one timestamp per fix, rather than individual timestamps for each
field.  The default reporting method, via 'o', ships everything.  

As a consequence, the gpsd code and data structures are simpler than they 
used to be.  There is now one data structure, struct gps_fix_t, that 
describes a volume in kinematic space (PVT and associeted
uncertainties); the user can easily copy these things around and
collect histories of them without carrying along GPS housekeeping
data like DGPS status or DOP numbers.

What I've traded away is that, for the small class of GPSes that 
cannot report entire fixes, some data in the report structure can
sometimes undetectably be up to one reporting cycle (e.g. one second)
old if you happen to poll at exactly the wrong time in the report
cycle; this is most likely to happen with altitude.

Also, note that gpsd now computes several error estimates if it doesn't
get them from the GPS, including horizontal/vertical position uncertainty
and groundspeed/vertical-speed uncertainty.  Those of you who are GPS
experts should review the code in libgpsd_core.c, after line 170, thar
does these computations.  Check my assumptions.

If anyone would care to contribute the trigonometry needed to compute
track uncertainty, I'd like to have that too.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The Bible is not my book, and Christianity is not my religion.  I could never
give assent to the long, complicated statements of Christian dogma.
	-- Abraham Lincoln

[prev in list] [next in list] [prev in thread] [next in thread]