Provided by: gpsd_3.4-2_amd64 bug


       gpsd - interface daemon for GPS receivers


       gpsd [-F control-socket] [-S listener-port] [-b] [-l] [-G] [-n] [-N] [-h] [-P pidfile]
            [-D debuglevel] [-V] [[source-name]...]


       If you have a GPS attached on the lowest-numbered USB port of a Linux system, and want to
       read reports from it on TCP/IP port 2947, it will normally suffice to do this:

           gpsd /dev/ttyUSB0

       For the lowest-numbered serial port:

           gpsd /dev/ttyS0

       Change the device number as appropriate if you need to use a different port. Command-line
       flags enable verbose logging, a control port, and other optional extras but should not be
       needed for basic operation; the one exception, on very badly designed hardware, might be
       -b (which see).

       On Linux systems supporting udev, gpsd is normally started automatically when a USB plugin
       event fires (if it is not already running) and is handed the name of the newly active
       device. In that case no invocation is required at all.

       For your initial tests set your GPS hardware to speak NMEA, as gpsd is guaranteed to be
       able to process that. If your GPS has a native or binary mode with better performance that
       gpsd knows how to speak, gpsd will autoconfigure that mode.

       You can verify correct operation by first starting gpsd and then xgps, the X windows test

       If you have problems, the GPSD project maintains a >FAQ to assist troubleshooting.


       gpsd is a monitor daemon that collects information from GPSes, differential-GPS radios, or
       AIS receivers attached to the host machine. Each GPS, DGPS radio, or AIS receiver is
       expected to be direct-connected to the host via a USB or RS232C serial device. The serial
       device 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 (differing) extended NMEA dialects used by MKT-3301, iTrax, Motorola
       OnCore, Sony CXD2951, and Ashtech/Thales devices. It can also interpret the binary
       protocols used by EverMore, Garmin, Navcom, Rockwell/Zodiac, SiRF, Trimble, and uBlox
       ANTARIS devices. It can read heading and attitude information from the Oceanserver 5000
       orv TNT Revolution digital compasses.

       The GPS reporting formats supported by your instance of gpsd may differ depending on how
       it was compiled; general-purpose versions support many, but it can be built with protocol
       subsets down to a singleton for use in constrained environments. For a list of the GPS
       protocols supported by your instance, see the output of gpsd -l

       gpsd effectively hides the differences among the GPS types it supports. It also knows
       about and uses commands that tune these GPSes for lower latency. By using gpsd as an
       intermediary applications avoid contention for serial devices.

       gpsd can use differential-GPS corrections from a DGPS radio or over the net, from a ground
       station running a DGPSIP server or a Ntrip broadcaster that reports RTCM-104 data; this
       will shrink position errors 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 that accept RTCM corrections (this is dependent on the type
       of the GPS; not all GPSes have the firmware capability to accept RTCM correction packets).
       See the section called “ACCURACY” and the section called “FILES” for discussion.

       Client applications will communicate with gpsd via a TCP/IP port, 2947 by default). Both
       IPv4 and IPv6 connections are supported and a client may connect via either.

       The program accepts the following options:

           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.

           Set TCP/IP port on which to listen for GPSD clients (default is 2947).

           Broken-device-safety mode, otherwise known as read-only mode. Some popular bluetooth
           and USB receivers lock up or become totally inaccessible when probed or reconfigured.
           This switch prevents gpsd from writing to a receiver. This means that gpsd cannot
           configure the receiver for optimal performance, but it also means that gpsd cannot
           break the receiver. A better solution would be for Bluetooth to not be so fragile. A
           platform independent method to identify serial-over-Bluetooth devices would also be

           This flag causes gpsd to listen on all addresses (INADDR_ANY) rather than just the
           loop back (INADDR_LOOPBACK) address. For the sake of privacy and security, TPV
           information is now private to the local machine until the user makes an effort to
           expose this to the world.

           List all drivers compiled into this gpsd instance. The letters to the left of each
           driver name are the gpsd control commands supported by that driver.

           Don't wait for a client to connect before polling whatever GPS is associated with it.
           Some RS232 GPSes wait in a standby mode (drawing less power) when the host machine is
           not asserting DTR, and some cellphone and handheld embedded GPSes have similar
           behaviors. Accordingly, waiting for a watch request to open the device may save
           battery power. (This capability is rare in consumer-grade devices and nonexistent in
           USB GPSes which lack a DTR line.)

           Don't daemonize; run in foreground. This switch is mainly useful for debugging.

           Display help message and terminate.

           Specify the name and path to record the daemon's process ID.

           Set debug level. At debug levels 2 and above, gpsd reports incoming sentence and
           actions to standard error if gpsd is in the foreground (-N) or to syslog if in the

           Dump version and exit.

       Arguments are interpreted as the names of data sources. Normally, a data source is the
       device pathname of a local device from which the daemon may expect GPS data. But there are
       three other special source types recognized, for a total of four:

       Local serial or USB device
           A normal Unix device name of a serial or USB device to which a sensor is attached.
           Example: /dev/ttyUSB0.

       TCP feed
           A URI with the prefix "tcp://", followed by a hostname, a colon, and a port number.
           The daemon will open a socket to the indicated address and port and read data packets
           from it, which will be interpreted as though they had been issued by a serial device.
           Example: tcp://

       UDP feed
           A URI with the prefix "udp://", followed by a hostname, a colon, and a port number.
           The daemon will open a socket listening for UDP datagrams arriving on the indicated
           address and port, which will be interpreted as though they had been issued by a serial
           device. Example: udp://

       Ntrip caster
           A URI with the prefix "ntrip://" followed by the name of an Ntrip caster (Ntrip is a
           protocol for broadcasting differential-GPS fixes over the net). For Ntrip services
           that require authentication, a prefix of the form "username:password@" can be added
           before the name of the Ntrip broadcaster. For Ntrip service, you must specify which
           stream to use; the stream is given in the form "/streamname". An example DGPSIP URI
           could be "dgpsip://" and a Ntrip URI could be
           "ntrip://". Corrections from the caster
           will be send to each attached GPS with the capability to accept them.

       DGPSIP server
           A URI with the prefix "dgpsip://" followed by a hostname, a colon, and an optional
           colon-separated port number (defaulting to 2101). The daemon will handshake with the
           DGPSIP server and read RTCM2 correction data from it. Corrections from the server will
           be set to each attached GPS with the capability to accept them. Example:

       Remote gpsd feed
           A URI with the prefix "gpsd://", followed by a hostname and optionally a colony and a
           port number (if the port is absent the default gpsd port will be used). The daemon
           will open a socket to the indicated address and port and emulate a gpsd client,
           collecting JSON reports from the remote gpsd instance that will be passed to local

       (The "ais:://" source type supported in some older versions of the daemon has been retired
       in favor of the more general "tcp://".)

       Internally, the daemon maintains a device pool holding the pathnames of devices and remote
       servers 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 the
       section called “GPS DEVICE MANAGEMENT” for details on this). Daemon startup will abort
       with an error if neither any devices nor a control socket are specified.

       When a device is activated (i.e. a client requests data from it), gpsd attempts to execute
       a hook from /etc/gpsd/device-hook with first command line argument set to the pathname of
       the device and the second to ACTIVATE. On deactivation it does the same passing DEACTIVATE
       for the second argument.

       gpsd can export data to client applications in three ways: via a sockets interface, via a
       shared-memory segment, and via D-Bus. The next three major sections describe these


       Clients may communicate with the daemon via textual request and responses over a socket.
       It is a bad idea for applications to speak the protocol directly: rather, they should use
       the libgps client library and take appropriate care to conditionalize their code on the
       major and minor protocol version symbols.

       The request-response protocol for the socket interface is fully documented in


       gpsd has two other (read-only) interfaces.

       Whenever the daemon recognizes a packet from any attached device, it writes the
       accumulated state from that device to a shared memory segment. The C and C++ client
       libraries shipped with GPSD can read this segment. Client methods, and various
       restrictions associated with the read-only nature of this interface, are documented at
       libgps(3). The shared-memory interface is intended primarily for embedded deployments in
       which gpsd monitors a single device, and its principal advantage is that a daemon instance
       configured with shared memory but without the soickets interface loses a significant
       amount of runtime weight.

       The daemon may be configured to emit a D-Bus signal each time an attached device delivers
       a fix. The signal path is path /org/gpsd, the signal interface is "org.gpsd", and the
       signal name is "fix". The signal payload layout is as follows:

       Table 1. Satellite object
       │Type             │                                  │
       │                 │        Description               │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Time (seconds since Unix  │
       │                 │        epoch)                    │
       │DBUS_TYPE_INT32  │                                  │
       │                 │        mode                      │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Time uncertainty          │
       │                 │        (seconds).                │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Latitude in degrees.      │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Longitude in degrees.     │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Horizontal uncertainty in │
       │                 │        meters, 95% confidence.   │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Altitude in meters.       │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Altitude uncertainty in   │
       │                 │        meters, 95% confidence.   │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Course in degrees from    │
       │                 │        true north.               │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Course uncertainty in     │
       │                 │        meters, 95% confidence.   │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Speed, meters per second. │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Speed uncertainty in      │
       │                 │        meters per second, 95%    │
       │                 │        confidence.               │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Climb, meters per second. │
       │DBUS_TYPE_DOUBLE │                                  │
       │                 │        Climb uncertainty in      │
       │                 │        meters per second, 95%    │
       │                 │        confidence.               │
       │DBUS_TYPE_STRING │                                  │
       │                 │        Device name               │


       gpsd maintains an internal list of GPS devices (the "device pool"). 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.

       A device may will also be dropped from the pool if GPSD gets a zero length read from it.
       This end-of-file condition indicates that the' device has been disconnected.

       When gpsd is properly installed along with hotplug notifier scripts feeding it device-add
       commands over the control socket, gpsd should require no configuration or user action to
       find devices.

       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.

       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.

       To send a binary control string to a specified device, write to the control socket a '&',
       followed by the device name, followed by '=', followed by the control string in paired hex

       Your client may await a response, which will be a line beginning with either "OK" or
       "ERROR". An ERROR response 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 pool. 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.


       The base User Estimated Range 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 in ionospheric signal lag than latitude/longitude is, 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 by a factor of 4, provided you are within about 100mi
       (160km) of a DGPS ground station from which you are receiving corrections.

       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 and later, 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.

       The time reporting of the GPS system itself has an intrinsic accuracy limit of 14
       nanoseconds, but this can only be approximated by specialized receivers using that send
       the high-accuracy PPS (Pulse-Per-Second) over RS232 to cue a clock crystal. Most GPS
       receivers only report time to a precision of 0.01s or 0.001s, and with no accuracy
       guarantees below 1sec.

       If your GPS uses a SiRF chipset at firmware level 231, reported UTC time may be off by the
       difference between whatever default leap-second offset has been compiled in and whatever
       leap-second correction is currently applicable, from startup until complete subframe
       information is received. 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.

       There are exactly two circumstances under which gpsd relies on the host-system clock:

       In the GPS broadcast signal, GPS time is represented using a week number that rolls over
       after 2^10 or 2^13 weeks (about 19.6 years, or 157 years), depending on the spacecraft.
       Receivers are required to disambiguate this to the correct date, but may have difficulty
       due to not knowing time to within half this interval, or may have bugs. Users have
       reported incorrect dates which appear to be due to this issue.  gpsd uses the startup time
       of the daemon detect and compensate for rollovers while it is running, but otherwise
       reports the date as it is reported by the receiver without attempting to correct it.

       If you are using an NMEA-only GPS (that is, not using SiRF or Garmin or Zodiac binary
       mode), gpsd relies on the system clock to tell it the current century. If the system clock
       returns an invalid value near zero, and the GPS does not emit GPZDA at the start of its
       update cycle (which most consumer-grade NMEA GPSes do not) then the century part of the
       dates gpsd delivers may be wrong. Additionally, near the century turnover, a range of
       dates as wide in seconds as the accuracy of your system clock may be referred to the wrong


       gpsd can provide reference clock information to ntpd, to keep the system clock
       synchronized to the time provided by the GPS receiver. 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

       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. In addition, if your kernel provides the RFC 2783 kernel PPS API then gpsd will
       use that for extra accuracy.

       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

           fudge time1 0.420 refid GPS

           server prefer
           fudge refid GPS1

       Users of ntpd older than revision ntp-4.2.5p138 should instead use this ntp.conf snippet:

           server minpoll 4 maxpoll 4
           fudge time1 0.420 refid GPS

           server minpoll 4 maxpoll 4 prefer
           fudge refid GPS1

       The magic pseudo-IP address identifies unit 0 of the ntpd shared-memory
       driver; 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 binary, 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

       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.


       gpsd can provide reference clock information to chronyd similar to the way it talks to
       ntpd. The advantage to using chrony is that the PPS time resolution is in nSec. This is
       1,000 times more precision than the time resolution provided to ntpd.

       gpsd talks to chronyd using a socket named /tmp/chrony.ttyXX.sock (where ttyXX is replaced
       by the GPS device name. This allows multiple GPS to feed one chronyd.

       No gpsd configuration is required to talk to chronyd. To get chronyd to connect to gpsd
       using the SHM method add this to your /etc/chrony/chonry.conf file.

           # delay 0.0 is right, but use 0.2 to avoid NMEA
           # time fighting with PPS time
           refclock SHM 0 offset 0.0 delay 0.2
           refclock SHM 1 offset 0.0 delay 0.0

       To get chronyd to connect to gpsd using the more precise socket method add this to your
       /etc/chrony/chrony.conf file (replacing ttyXX with your device name):

           #refclock PPS
           /dev/pps0 refclock SOCK /tmp/chrony.ttyXX.sock


       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.


       gpsd, if given the -G flag, will listen for connections from any reachable host, and then
       disclose the current position. Before using the -G flag, consider whether you consider
       your computer's location to be sensitive data to be kept private or something that you
       wish to publish.

       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" (or another userid as set by
       configure) 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).


       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), a 'TPV'
       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.

       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.

       Generation of position error estimates (eph, epv, epd, eps, epc) from the incomplete data
       handed back by GPS reporting protocols involves both a lot of mathematical black art and
       fragile device-dependent assumptions. This code has been bug-prone in tbe past and
       problems may still lurk there.

       AIDVM decoding of types 16-17, 22-23, and 25-26 is unverified.

       GPSD presently fully recognizes only the 2.1 level of RTCM2 (message types 1, 3, 4, 5, 6,
       7, 9, 16). The 2.3 message types 13, 14, and 31 are recognized and reported. Message types
       8, 10-12, 15-27, 28-30 (undefined), 31-37, 38-58 (undefined), and 60-63 are not yet

       The ISGPS used for RTCM2 and subframes decoder logic is sufficiently convoluted to confuse
       some compiler optimizers, notably in GCC 3.x at -O2, into generating bad code.

       Devices meant to to use PPS for high-precision timekeeping may fail if they are specified
       after startup by a control-socket command, as opposed to on the daemon's original command
       line. (Root privileges are dropped early, and some Unix varients require them in order to
       set the PPS line discipline.)


           Prototype TTY device. After startup, gpsd sets its group ID to the owning group of
           this device if no GPS device was specified on the command line does not exist.

           Optional file containing the device activation/deactivation script. Note that while
           /etc/gpsd is the default system configuration directory, it is possible to build the
           GPSD source code with different assumptions.


       The official NMEA protocol standard is available on paper from the National Marine
       Electronics Association, but is proprietary and expensive; the maintainers of gpsd have
       made a point of not looking at it. The GPSD project website links to several documents
       that collect publicly disclosed information about the protocol.

       gpsd parses the following NMEA sentences: RMC, GGA, GLL, GSA, GSV, VTG, ZDA. It recognizes
       these with either the normal GP talker-ID prefix, or with the GN prefix used by GLONASS,
       or with the II prefix emitted by Seahawk Autohelm marine navigation systems, or with the
       IN prefix emitted by some Garmin units, or with the EC prefix emitted by ECDIS units. It
       recognizes some vendor extensions: the PGRME emitted by some Garmin GPS models, the OHPR
       emitted by Oceanserver digital compasses, the PTNTHTM emitted by True North digital
       compasses, and the PASHR sentences emitted by some Ashtech GPSes.

       Note that gpsd JSON returns pure decimal degrees, not the hybrid degree/minute format
       described in the NMEA standard.

       Differential-GPS corrections are conveyed by the RTCM-104 protocol. The applicable
       standard for RTCM-104 V2 is RTCM Recommended Standards for Differential GNSS (Global
       Navigation Satellite) Service RTCM Paper 136-2001/SC 104-STD. The applicable standard for
       RTCM-104 V3 is RTCM Standard 10403.1 for Differential GNSS Services - Version 3 RTCM Paper
       177-2006-SC104-STD. Ordering instructions for the RTCM standards are accessible from the
       website of the Radio Technical Commission for Maritime Services under "Publications".

       AIS is defined by ITU Recommendation M.1371, Technical Characteristics for a Universal
       Shipborne Automatic Identification System Using Time Division Multiple Access. The
       AIVDM/AIVDO format understood by this program is defined by IEC-PAS 61162-100, Maritime
       navigation and radiocommunication equipment and systems.A more accessible description of
       both can be found at AIVDM/AIVDO Protocol Decoding, on the references page of the GPSD
       project website.

       Subframe data is defined by IS-GPS-200E, GLOBAL POSITIONING SYSTEM WING (GPSW) SYSTEMS
       understood by this program is defined in Section 20 (Appendix II) of the IS-GPS-200E, GPS

       The API for PPS time service is speciied by RFC 2783, Pulse-Per-Second API for UNIX-like
       Operating Systems, Version 1.0


       gpsdctl(8), gps(1), libgps(3), gpsd_json(5), libgpsd(3), gpsprof(1), gpsfake(1),
       gpsctl(1), gpscat(1),


       Authors: Eric S. Raymond, Chris Kuethe, Gary Miller. Former authors whose bits have been
       plowed under by code turnover: Remco Treffcorn, Derrick Brashear, Russ Nelson. This manual
       page by Eric S. Raymond