Provided by:
gpsd_2.30-1ubuntu3_i386 
NAME
gpsd - interface daemon for GPS receivers
SYNOPSIS
gpsd [-f GPS-devicename] [-F control-socket] [-S listener-port]
[-d DGPSIP-server] [-n] [-N] [-h] [-P pidfile] [-D debuglevel]
[-v] [[GPS-devicename]...]
DESCRIPTION
gpsd is a monitor daemon that watches a TCP/IP port (2947 by default),
waiting for applications to request information from GPSes or
differential-GPS radios attached to the host machine. Each GPS or radio
is expected to be direct-connected to the host via a USB or RS232C
serial port. The port may be specified to gpsd at startup, or it may be
set via a command shipped down a local control socket (e.g. by a USB
hotplug script). Given a GPS device by either means, gpsd discovers the
correct port speed and protocol for it.
gpsd should be able to query any GPS that speaks either the standard
textual NMEA 0183 protocol, or the binary Rockwell protocol used by
EarthMate and some other GPSes, the TSIP binary protocol used by
Trimble GPSes, or the binary SiRF protocol used by SiRf-II and
SiRF-Star chipsets, or the Garmin binary protocol used by the USB
version of the Garmin 18 and other Garmin USB GPSes, or the binary
protocol used by Evermore chipsets, or the extended NMEA used by iTrax.
gpsd effectively hides the differences among these. It also knows about
and uses commands that tune the GPS for lower latency, decrease
bandwidth usage, or increased accuracy on the San Jose Navigation FV18,
the Sony CXD2951, the uBlox, and the Motorola OnCore GT+. It can read
heading and attitude information from the True North Technologies
Revolution 2X Digital compass.
gpsd can use differential-GPS corrections from a DGPS radio or over the
net, from a ground station running a DGPSIP server that reports
RTCM-S104 data; this will improve user error by roughly a factor of
four. When gpsd opens a serial device emitting RTCM-104, it
automatically recognizes this and uses the device as a correction
source for all connected GPSes. See [xref to refsect1] and [xref to
refsect1] for discussion.
The program accepts the following options:
-f Set a GPS device name. This option is deprecated and may be
removed in a future version. Each command-line argument will be
treated as a device to be probed for the presence of a GPS;
that, rather than the -f option, is the preferred way of
specifying GPS devices at startup.
-F Create a control socket for device addition and removal
commands. You must specify a valid pathname on your local
filesystem; this will be created as a Unix-domain socket to
which you can write commands that edit the daemon’s internal
device list.
-S Set TCP/IP port on which to listen for GPSD clients (default is
2947).
-d Query a specific differential-GPS (DGPSIP) server. If a suffix
of the server name begins with ":" it is interpreted as a port
number, overriding the default IANA-assigned port of 2101.
-n Don’t wait for a client to connect before polling whatever GPS
is associated with it. The wait is a feature; many serial GPSes
go to a standby mode (not drawing power) before the host machine
asserts DTR, so waiting for the first actual request can save
valuable battery power on portable equipment. This option
combines well with -D2 to enable monitoring of the GPS data
stream.
-N Don’t daemonize; run in foreground. Also suppresses
privilege-dropping. This switch is mainly useful for debugging.
Its meaning may change in future versions.
-h Display help message and terminate.
-P Specify the name and path to record the daemon’s process ID.
-D Set debug level. At debug levels 2 and above, gpsd reports
incoming sentence and actions to standard error.
-v Dump version and exit.
Internally, the daemon maintains a device list holding the pathnames of
GPSes known to the daemon. Initially, this list is the list of
device-name arguments specified on the command line. That list may be
empty, in which case the daemon will have no devices on its search list
until they are added by a control-socket command (see [xref to
refsect1] for details on this). Daemon startup will abort with an error
if neither any devices nor a control socket are specified.
At any given time, each client will be listening to only one of the
GPSes on the device list. By default, a client’s device is the one that
most recently shipped information to the daemon at the time the client
first requests GPS information (that is, issues any command other than
F, K, W=0 or R=0).
The request protocol for gpsd clients is very simple. Each request
normally consists of a single ASCII character followed by a newline.
Case of the request character is ignored, Each request returns a line
of response text ended by a CR/LF. Requests and responses are as
follows, with %f standing for a decimal float numeral and %d for
decimal integer numeral:
a The current altitude as "A=%f", meters above mean sea level.
b The B command with no argument returns four fields giving the
parameters of the serial link to the GPS as "B=%d %d %c %d";
baud rate, byte size, parity, (N, O or E for no parity, odd, or
even) and stop bits (1 or 2). The command "B=%d" sets the baud
rate, not changing parity or stop bits; watch the response,
because it is possible for this to fail if the GPS does not
support a speed-switching command. In case of failure, the
daemon and GPS will continue to communicate at the old speed.
The B= form is rejected if more than one client is attached to
the channel.
c If the driver has the capability to change sampling rate the
command "C=%f" does so, setting a new cycle time in seconds. The
"C=" form is rejected if more than one client is attached to the
channel.
If the driver has the capability to change sampling rate, this
command always returns "C=%f %f" giving the current cycle time
in seconds and the minimum possible cycle time at the current
baud rate. If the driver does not have the capability to change
sampling rate, this returns, as "C=%f", the cycle time in
seconds only.
Either number may be fractional, indicating a GPS cycle shorter
than a second; however, if >1 the cycle time must be a whole
number. Also note that relatively few GPSes have the ability to
set sub-second cycle times; consult your hardware protocol
description to make sure this works.
This command will return ’?’ at start of session, before the
first full packet has been received from the GPS, because its
type is not yet known. To set up conditions for a real answer,
issue it after some command that reads position/velocity/time
information from the device.
d Returns the UTC time in the ISO 8601 format,
"D=yyyy-mm-ddThh:nmm:ss.ssZ". Digits of precision in the
fractional-seconds part will vary and may be absent.
e Returns "E=%f %f %f": three estimated position errors in meters
-- total, horizontal, and vertical (95% confidence level). Note:
many GPSes do not supply these numbers. When the GPS does not
supply them, gpsd computes them from satellite DOP using fixed
figures for expected non-DGPS and DGPS range errors in meters. A
value of zero for any of these numbers should be taken to mean
that component of DOP is not available. See also the ’q’
command.
f Gets or sets the active GPS device name. The bare command ’f’
requests a response containing ’F=’ followed by the name of the
active GPS device. The other form of the command is ’f=’, in
which case all following printable characters up to but not
including the next CR/LF are interpreted as the name of a trial
GPS device. If the trial device is in gpsd’s device list, it is
opened and read to see if a GPS can be found there. If it can,
the trial device becomes the active device for this client.
The ’f=’ command may fail if the specified device name is not on
the daemon’s device list. This device list is initialized with
the paths given on the command line, if any were specified. For
security reasons, ordinary clients cannot change this device
list; instead, this must be done via the daemon’s local control
socket declared with the -F option.
Once an ’f=’ command succeeds, the client is tied to the
specified device until the client disconnects.
Whether the command is ’f’ or ’f=’ or not, and whether it
succeeds or not, the response always lists the name of the
client’s device.
(At protocol level 1, the F command failed if more than one
client was attached, and multiple devices were not supported.)
g With =, accepts a single argument which may have either of the
values ’gps’ or ’rtcm104’, with case ignored. This specifies the
type of information the client wants and forces a device
assignment. Without =, forces a device assignment but doesn’t
force the type. This command is optional; if it is not given,
the client will be bound to whatever available device the daemon
finds first.
This command returns either ’?’ if no device of the specified
type(s) could be assigned, otherwise a string (’GPS’ or
’RTCM104’) identifying the kind of information the attached
device returns.
i Returns a text string identifying the GPS. The string may
contain spaces and is terminated by CR-LF. This command will
return ’?’ at start of session, before the first full packet has
been received from the GPS, because its type is not yet known.
k Returns a line consisting of "K=" followed by an integer count
of of all GPS devices known to gpsd, followed by a space,
followed by a space-separated list of the device names. This
command lists devices the daemon has been pointed at by the
command-line argument(s) or an add command via its control
socket, and has successfully recognized as GPSes. Because GPSes
might be unplugged at any time, the presence of a name in this
list does not guarantee that the device is available.
(At protocol level 1, there was no K command.)
l Returns three fields: a protocol revision number, the gpsd
version, and a list of accepted request letters.
m The NMEA mode as "M=%d". 0=no mode value yet seen, 1=no fix,
2=2D (no altitude), 3=3D (with altitude).
n Get or set the GPS driver mode. Without argument, reports the
mode as "N=%d"; N=0 means NMEA mode and N=1 means alternate mode
(binary if it has one, for SiRF and Evermore chipsets in
particular). With argument, set the mode if possible; the new
mode will be reported in the response. The "N=" form is rejected
if more than one client is attached to the channel.
o Attempts to return a complete time/position/velocity report as a
unit. Any field for which data is not available being reported
as ?. If there is no fix, the response is simply "O=?",
otherwise a tag and timestamp are always reported. Fields are as
follows, in order:
tag A tag identifying the last sentence received. For NMEA
devices this is just the NMEA sentence name; the
talker-ID portion may be useful for distinguishing among
results produced by different NMEA talkers in the same
wire.
timestamp
Seconds since the Unix epoch, UTC. May have a fractional
part of up to .01sec precision.
time error
Estimated timestamp error (%f, seconds, 95% confidence).
latitude
Latitude as in the P report (%f, degrees).
longitude
Longitude as in the P report (%f, degrees).
altitude
Altitude as in the A report (%f, meters).
horizontal error estimate
Horizontal error estimate as in the E report (%f,
meters).
vertical error estimate
Vertical error estimate as in the E report (%f, meters).
course over ground
Track as in the T report (%f, degrees).
speed over ground
Speed (%f, meters/sec). Note: older versions of the O
command reported this field in knots.
climb/sink
Vertical velocity as in the U report (%f, meters/sec).
estimated error in course over ground
Error estimate for course (%f, degrees, 95% confidence).
estimated error in speed over ground
Error estimate for speed (%f, meters/sec, 95%
confidence). Note: older versions of the O command
reported this field in knots.
climb/sink
Estimated error for climb/sink (%f, meters/sec, 95%
confidence).
p Returns the current position in the form "P=%f %f"; numbers are
in degrees, latitude first.
q Returns "Q=%d %f %f %f %f %f": a count of satellites used in the
last fix, and five dimensionless dilution-of-precision (DOP)
numbers -- spherical, horizontal, vertical, time, and total
geometric. These are computed from the satellite geometry; they
are factors by which to multiply the estimated UERE (user error
in meters at specified confidence level due to ionospheric
delay, multipath reception, etc.) to get actual circular error
ranges in meters (or seconds) at the same confidence level. See
also the ’e’ command. Note: Some GPSes may fail to report these,
or report only one of them (often HDOP); a value of 0.0 should
be taken as an indication that the data is not available.
Note: Older versions of gpsd reported only the first three DOP
numbers, omitting time DOP and total DOP.
r Sets or toggles ’raw’ mode. Return "R=0" or "R=1" or "R=2". In
raw mode you read the NMEA data stream from each GPS. (Non-NMEA
GPSes get their communication format translated to NMEA on the
fly.) If the device is a source of RTCM-104 corrections, the
corrections are dumped in the textual format described in
rtcm104(5).
The command ’r’ immediately followed by the digit ’1’ or the
plus sign ’+’ sets raw mode. The command ’r’ immediately
followed by the digit ’2’ sets super-raw mode; for non-NMEA
(binary) GPSes or RTCM-104 sources this dumps the raw binary
packet. The command ’r’ followed by the digit ’0’ or the minus
sign ’-’ clears raw mode. The command ’r’ with neither suffix
toggles raw mode.
Note: older versions of gpsd did not support super-raw mode.
s The NMEA status as "S=%d". 0=no fix, 1=fix, 2=DGPS-corrected
fix.
t Track made good; course "T=%f" in degrees from true north.
u Current rate of climb as "U=%f" in meters per second. Some GPSes
(non-Sirf-II based) do not report this, in that case gpsd
computes it using the altitude from the last fix (if available).
v The current speed over ground as "V=%f" in knots.
w Sets or toggles ’watcher’ mode (see the descroiption below).
Return "W=0" or "W=1".The command ’w’ immediately followed by
the digit ’1’ or the plus sign ’+’ sets watcher mode. The
command ’w’ followed by the digit ’0’ or the minus sign ’-’
clears watcher mode. The command ’w’ with neither suffix toggles
watcher mode.
x Returns "X=0" if the GPS is offline, "X=%f" if online; in the
latter case, %f is a timestamp from when the last sentence was
received.
(At protocol level 1, the nonzero response was always 1.)
y Returns Y=, followed by a sentence tag, followed by a timestamp
(seconds since the Unix epoch, UTC) and a count not more than
12, followed by that many quintuples of satellite PRNs,
elevation/azimuth pairs (elevation an integer formatted as %d in
range 0-90, azimuth an integer formatted as %d in range 0-359),
signal strengths in decibels, and 1 or 0 according as the
satellite was or was not used in the last fix. Each number is
followed by one space.
(At protocol level 1, this response had no tag or timestamp.)
z The Z command returns daemon profiling information of interest
to gpsd developers. The format of this string is subject to
change without notice.
Note that a response consisting of just ? following the = means that
there is no valid data available. This may mean either that the device
being queried is offline, or (for position/velocity/time queries) that
it is online but has no fix.
Requests can be concatenated and sent as a string; gpsd will then
respond with a comma-separated list of replies.
Every gpsd reply will start with the string "GPSD" followed by the
replies. Examples:
query: "p\n"
reply: "GPSD,P=36.000000 123.000000\r\n"
query: "d\n"
reply: "GPSD,D=2002-11-16T02:45:05.12Z\r\n"
query: "va\n"
reply: "GPSD,V=0.000000,A=37.900000\r\n"
When clients are active but the GPS is not responding, gpsd will spin
trying to open the GPS device once per second. Thus, it can be left
running in background and survive having a GPS repeatedly unplugged and
plugged back in. When it is properly installed along with hotplug
notifier scripts feeding it device-add commands, gpsd should require no
configuration or user action to find devices.
The recommended mode for clients is watcher mode. In watcher mode gpsd
ships a line of data to the client each time the GPS gets either a fix
update or a satellite picture, but rather than being raw NMEA the line
is a gpsd ’o’ or ’y’ response. Additionally, watching clients get
notifications in the form X=0 or X=%f when the online/offline status of
the GPS changes.
Sending SIGHUP to a running gpsd forces it to close all GPSes and all
client connections. It will then attempt to reconnect to any GPSes on
its device list and resume listening for client connections. This may
be useful if your GPS enters a wedged or confused state but can be
soft-reset by pulling down DTR.
GPS DEVICE MANAGEMENT
gpsd maintains an internal list of GPS devices. If you specify devices
on the command line, the list is initialized with those pathnames;
otherwise the list starts empty. Commands to add and remove GPS device
paths from the daemon’s device list must be written to a local
Unix-domain socket which will be accessible only to programs running as
root. This control socket will be located wherever the -F option
specifies it.
To point gpsd at a device that may be a GPS, write to the control
socket a plus sign (’+’) followed by the device name followed by LF or
CR-LF. Thus, to point the daemon at /dev/foo. send "+/dev/foo\n". To
tell the daemon that a device has been disconnected and is no longer
available, send a minus sign (’-’) followed by the device name followed
by LF or CR-LF. Thus, to remove /dev/foo from the search list. send
"-/dev/foo\n".
To send a control string to a specified device, write to the control
socket a ’!’, followed by the device name, followed by ’=’, followed by
the control string.
Your client may await a response, which will be a line beginning with
either "OK" or "ERROR". An ERROR reponse to an add command means the
device did not emit data recognizable as GPS packets; an ERROR response
to a remove command means the specified device was not in gpsd’s device
list. An ERROR response to a ! command means the daemon did not
recognize the devicename specified.
The control socket is intended for use by hotplug scripts and other
device-discovery services. This control channel is separate from the
public gpsd service port, and only locally accessible, in order to
prevent remote denial-of-service and spoofing attacks.
ACCURACY
The base user error (UERE) of GPSes is 8 meters or less at 66%
confidence, 15 meters or less at 95% confidence. Actual horizontal
error will be UERE times a dilution factor dependent on current
satellite position. Altitude determination is more sensitive to
variability to atmospheric signal lag than latitude/longitude, and is
also subject to errors in the estimation of local mean sea level; base
error is 12 meters at 66% confidence, 23 meters at 95% confidence.
Again, this will be multiplied by a vertical dilution of precision
(VDOP) dependent on satellite geometry, and VDOP is typically larger
than HDOP. Users should not rely on GPS altitude for life-critical
tasks such as landing an airplane.
These errors are intrinsic to the design and physics of the GPS system.
gpsd does its internal computations at sufficient accuracy that it will
add no measurable position error of its own.
DGPS correction will reduce UERE from roughly 8 meters to roughly 2
meters, provided you are within about 100mi (160km) of a DGPS ground
station.
On a 4800bps connection, the time latency of fixes provided by gpsd
will be one second or less 95% of the time. Most of this lag is due to
the fact that GPSes normally emit fixes once per second, thus expected
latency is 0.5sec. On the personal-computer hardware available in 2005,
computation lag induced by gpsd will be negligible, on the order of a
millisecond. Nevertheless, latency can introduce significant errors for
vehicles in motion; at 50km/h (31mi/h) of speed over ground, 1 second
of lag corresponds to 13.8 meters change in position between updates.
USE WITH NTP
gpsd can provide reference clock information to ntpd, to keep the
system clock synchronized to the time provided by the GPS receiver.
This facility is only available when the daemon is started from root.
If you’re going to use gpsd you probably want to run it -n mode so the
clock will be updated even when no clients are active.
Note that deriving time from messages received from the GPS is not as
accurate as you might expect. Messages are often delayed in the
receiver and on the link by several hundred milliseconds, and this
delay is not constant. On Linux, gpsd includes support for interpreting
the PPS pulses emitted at the start of every clock second on the
carrier-detect lines of some serial GPSes; this pulse can be used to
update NTP at much higher accuracy than message time provides. You can
determine whether your GPS emits this pulse by running at -D 5 and
watching for carrier-detect state change messages in the logfile.
When gpsd receives a sentence with a timestamp, it packages the
received timestamp with current local time and sends it to a
shared-memory segment with an ID known to ntpd, the network time
synchronization daemon. If ntpd has been properly configured to receive
this message, it will be used to correct the system clock.
Here is a sample ntp.conf configuration stanza telling ntpd how to read
the GPS notfications:
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.420 refid GPS
server 127.127.28.1 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.1 refid GPS1
The magic pseudo-IP address 127.127.28.0 identifies unit 0 of the ntpd
shared-memory driver; 127.127.28.1 identifies unit 1. Unit 0 is used
for message-decoded time and unit 1 for the (more accurate, when
available) time derived from the PPS synchronization pulse. Splitting
these notifications allows ntpd to use its normal heuristics to weight
them.
With this configuration, ntpd will read the timestamp posted by gpsd
every 16 seconds and send it to unit 0. The number after the parameter
time1 is an offset in seconds. You can use it to adjust out some of the
fixed delays in the system. 0.035 is a good starting value for the
Garmin GPS-18/USB, 0.420 for the Garmin GPS-18/LVC.
After restarting ntpd, a line similar to the one below should appear in
the output of the command "ntpq -p" (after allowing a couple of
minutes):
remote refid st t when poll reach delay
offset jitter
=========================================================================
+SHM(0) .GPS. 0 l 13 16 377 0.000 0.885
0.882
If you are running PPS then it will look like this:
remote refid st t when poll reach delay
offset jitter
=========================================================================
-SHM(0) .GPS. 0 l 13 16 377 0.000 0.885
0.882 *SHM(1) .GPS1. 0 l 11 16 377 0.000
-0.059 0.006
When the value under "reach" remains zero, check that gpsd is running;
and some application is connected to it or the ’-n’ option was used.
Make sure the receiver is locked on to at least one satellite, and the
receiver is in SiRF-II, Garmin binary or NMEA/PPS mode. Plain NMEA will
also drive ntpd, but the accuracy as bad as one second. When the SHM(0)
line does not appear at all, check the system logs for error messages
from ntpd.
When no other reference clocks appear in the NTP configuration, the
system clock will lock onto the GPS clock. When you have previously
used ntpd, and other reference clocks appear in your configuration,
there may be a fixed offset between the GPS clock and other clocks. The
gpsd developers would like to receive information about the offsets
observed by users for each type of receiver. Please send us the output
of the "ntpq -p" command and the make and type of receiver.
USE WITH D-BUS
On operating systems that support D-BUS, gpsd can be built to broadcast
GPS fixes to D-BUS-aware applications. As D-BUS is still at a pre-1.0
stage, we will not attempt to document this interface here. Read the
gpsd source code to learn more.
SECURITY AND PERMISSIONS ISSUES
gpsd must start up as root in order to open the NTPD shared-memory
segment, open its logfile, and create its local control socket. Before
doing any processing of GPS data, it tries to drop root privileges by
setting its UID to "nobody" and its group ID to the group of the
initial GPS passed on the command line -- or, if that device doesn’t
exist, to the group of /dev/ttyS0.
Privilege-dropping is a hedge against the possibility that carefully
crafted data, either presented from a client socket or from a subverted
serial device posing as a GPS, could be used to induce misbehavior in
the internals of gpsd. It ensures that any such compromises cannot be
used for privilege elevation to root.
The assumption behind gpsd’s particular behavior is that all the tty
devices to which a GPS might be connected are owned by the same
non-root group and allow group read/write, though the group may vary
because of distribution-specific or local administrative practice. If
this assumption is false, gpsd may not be able to open GPS devices in
order to read them (such failures will be logged).
In order to fend off inadvertent denial-of-service attacks by port
scanners (not to mention deliberate ones), gpsd will time out inactive
client connections. Before the client has issued a command that
requests a channel assignment, a short timeout (60 seconds) applies.
There is no timeout for clients in watcher or raw modes; rather, gpsd
drops these clients if they fail to read data long enough for the
outbound socket write buffer to fill. Clients with an assigned device
in polling mode are subject to a longer timeout (15 minutes).
LIMITATIONS
If multiple NMEA talkers are feeding RMC, GLL, and GGA sentences to the
same serial device (possible with an RS422 adapter hooked up to some
marine-navigation systems), an ’O’ response may mix an altitude from
one device’s GGA with latitude/longitude from another’s RMC/GLL after
the second sentence has arrived.
gpsd may change control settings on your GPS (such as the emission
frequency of various sentences or packets) and not restore the original
settings on exit. This is a result of inadequacies in NMEA and the
vendor binary GPS protocols, which often do not give clients any way to
query the values of control settings in order to be able to restore
them later.
If your GPS uses a SiRF chipset at firmware level 231, and it is after
1 Jan 2006, reported UTC time may be off by the difference between 13
seconds and whatever leap-second correction is currently applicable,
from startup until complete subframe information is received (normally
about six seconds). Firmware levels 232 and up don’t have this problem.
You may run gpsd at debug level 4 to see the chipset type and firmware
revision level.
When using SiRF chips, the VDOP/TDOP/GDOP figures and associated error
estimates are computed by gpsd rather than reported by the chip. The
computation does not exactly match what SiRF chips do internally, which
includes some satellite weighting using parameters gpsd cannot see.
Autobauding on the Trimble GPSes can take as long as 5 seconds if the
device speed is not matched to the GPS speed.
If you are using an NMEA-only GPS (that is, not using SiRF or Garmin or
Zodiac binary mode) and the GPS does not emit GPZDA at the start of its
update cycle (which most consumer-grade NMEA GPSes do not) and it is
after 2099, then the century part of the dates gpsd delivers will be
wrong.
FILES
/dev/ttyS0
Prototype TTY device. After startup, gpsd sets its group ID to
the owner of this device if no GPS device was specified on the
command line does not exist.
APPLICABLE STANDARDS
The official NMEA protocol standard is available on paper from the
National Marine Electronics Association: http://www.nmea.org/pub/0183/,
but is proprietary and expensive; the maintainers of gpsd have made a
point of not looking at it. The GPSD website: http://gpsd.berlios.de/
links to several documents that collect publicly disclosed information
about the protocol.
gpsd parses the following NMEA sentences: RMC, GGA, GSA, GSV, ZDA. It
recognizes these with either the normal GP talker-ID prefix, or with
the II prefix emitted by Seahawk Autohelm marine navigation systems, or
with the IN prefix emitted by some Garmin units. It recognizes one
vendor extension, PGRME. Note that gpsd returns pure decimal degrees,
not the hybrid degree/minute format described in the NMEA standard.
SEE ALSO
xgps(1), libgps(3), libgpsd(3), gpsprof(1), gpsfake(1), rtcm-104(5).
AUTHORS
Remco Treffcorn, Derrick Brashear, Russ Nelson, Eric S. Raymond. This
manual page by Eric S. Raymond <esr@thyrsus.com>. There is a project
page here: http://gpsd.berlios.de/.
GPSD(8)