From e5548e974f42f2080a74ed2a30d1e2927fe0ad9f Mon Sep 17 00:00:00 2001 From: "Gary E. Miller" Date: Mon, 19 Nov 2018 19:56:24 -0800 Subject: man: Move man pages, source and result, into main/ part of cleaning up the root directory. --- man/gpsd.xml | 905 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 905 insertions(+) create mode 100644 man/gpsd.xml (limited to 'man/gpsd.xml') diff --git a/man/gpsd.xml b/man/gpsd.xml new file mode 100644 index 00000000..49489690 --- /dev/null +++ b/man/gpsd.xml @@ -0,0 +1,905 @@ + + + +]> + +9 Aug 2004 + +gpsd +8 +The GPSD Project +GPSD Documentation + + +gpsd +interface daemon for GPS receivers + + + + + + gpsd + -b + -D debuglevel + -F control-socket + -G + -h + -l + -n + -N + -P pidfile + -r + -S listener-port + -V + + source-name + + + + +QUICK START + +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 (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 client. + +If you have problems, the GPSD project maintains a FAQ to +assist troubleshooting. + + +DESCRIPTION + +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 u-blox ANTARIS devices. Under Linux +it can read NMEA2000 packets through the kernel CAN socket. It can read +heading and attitude information from the Oceanserver 5000 or 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 + and 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: + + +-b +Broken-device-safety mode, otherwise known as +read-only mode. A few bluetooth and USB receivers lock up or become +totally inaccessible when probed or reconfigured; see the hardware +compatibility list on the GPSD project website for details. 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 nice. + + +-D + +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 background. + + + +-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. + + + +-G +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. + + +-h +Display help message and terminate. + + +-l +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. + + + +-n + +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). + + + + +-N +Don't daemonize; run in foreground. +This switch is mainly useful for debugging. + + + +-r +Use GPS time even with no current fix. Some GPS's have +battery powered Real Time Clocks (RTC's) built in, makeing them a valid time +source even before a fix is acquired. This can be useful on a Raspberry Pi, +or other device that has no battery powered RTC, and thus has no valid +time at startup. + + +-P + +Specify the name and path to record the daemon's process ID. + + + +-S +Set TCP/IP port on which to listen for GPSD clients +(default is 2947). + + +-V + +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. + + + +Local PPS device + +A normal Unix device name of a PPS device to which a PPS source +is attached. The device name must start with "/dev/pps" and a local +serial or USB GPS device must also be available. Example: +/dev/pps0. + + + +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://data.aishub.net:4006. + + + +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://127.0.0.1:5000. + + + +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://dgpsip.example.com" and a Ntrip +URI could be +"ntrip://foo:bar@ntrip.example.com:80/example-stream". 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: +dgpsip://dgps.wsrcc.com:2101. + + + +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 clients. + + + +NMEA2000 CAN data + +A URI with the prefix "nmea2000://", followed by a CAN +devicename. Only Linux socket CAN interfaces are supported. The +interface must be configured to receive CAN messages +before gpsd can be started. If +there is more then one unit on the CAN bus that provides GPS data, +gpsd chooses the unit from which a GPS message +is first seen. Example: nmea2000://can0. + + + + + +(The "ais:://" source type supported in some older versions of +the daemon has been retired in favor of the more general +"tcp://".) + +Additionally, two serial device names have a side effect: + + +/dev/ttyAMA0 + +The UART device on a Raspberry Pi. Has the side effect of +opening /dev/pps0 for RFC2783 1PPS data. + + + +Generic GPS device 0. Has the side effect of +opening /dev/pps0 for RFC2783 1PPS data/ + + + + + + + +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 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 +. On deactivation it does the same passing + 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 interfaces. + + +THE SOCKET INTERFACE + +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_json5. + + + +SHARED-MEMORY AND DBUS INTERFACES + +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 +libgps3. 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 sockets 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: + +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 + + + +
+ + + +GPS DEVICE MANAGEMENT + +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. + +When gpsd is called with no initial +devices (thus, expecting devices to be passed to it by notifications to +the control socket), and reaches a state where there are no devices +connected and no subscribers after after some +devices have been seen, it shuts down gracefully. It is expected that +future device hotplug events will reactivate 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. + +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 digits. + +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. + + +ACCURACY + +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 +century. + + +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. + +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. + +Detailed instructions for using GPSD to set up a high-quality +time service can be found among the documentation on the GPSD +website. + + +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, 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 +configured userid) 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), 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 +supported. + +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 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 variants require them in order to set +the PPS line discipline. Under Linux the POSIX capability to set the +line discipline is retained, but other platforms cannot use this +code. + +USB GPS devices often do not identify themselves through the USB +subsystem; they typically present as the class 00h (undefined) or +class FFh (vendor-specific) of USB-to-serial adapters. Because of +this, the Linux hotplug scripts must tell +gpsd to sniff data from every USB-to-serial +adapter that goes active and is known to be of a type used in +GPSes. No such device is sent configuration strings until after it has +been identified as a GPS, and gpsd never +opens a device that is opened by another process. But there is a tiny +window for non-GPS devices not opened; if the application that wants +them loses a race with GPSD its device open will fail and have to be +retried after GPSD sniffs the device (normally less than a second +later). + + +FILES + + + +/dev/ttyS0 + +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. + + + +/etc/gpsd/device-hook + +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. + + + + + + +ENVIRONMENT VARIABLES + +By setting the environment variable GPSD_SHM_KEY, +you can control the key value used to create the shared-memory segment +used for communication with the client library. This will be useful +mainly when isolating test instances of +gpsd from production ones. + + +APPLICABLE STANDARDS + +The official NMEA protocol standards for NMEA0183 and NMEA2000 +are available from the National Marine Electronics Association, but are +proprietary and expensive; the maintainers of +gpsd have made a point of not looking at +them. 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, GBS, HDT, DBT, GST. 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, or with the SD prefix emitted by depth sounders, or with the HC +and TI prefix emitted by some Airmar equipment. 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, the PMTK omitted by some San Jose +Navigation GPSes, 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 +protocols. 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 ENGINEERING & INTEGRATION, +INTERFACE SPECIFICATION IS-GPS-200 Revision E. The format +understood by this program is defined in Section 20 (Appendix II) of +the IS-GPS-200E, GPS NAVIGATION DATA STRUCTURE FOR DATA, +D(t) + +JSON is specified by RFC 7159, The JavaScript Object +Notation (JSON) Data Interchange Format. + +The API for PPS time service is specified by RFC 2783, +Pulse-Per-Second API for UNIX-like Operating Systems, +Version 1.0 + + +SEE ALSO + +gpsdctl8, +gps1, +libgps3, +gpsd_json5, +libgpsmm3, +gpsprof1, +gpsfake1, +gpsctl1, +gpscat1, + + + +AUTHORS + +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 +esr@thyrsus.com. + + + -- cgit v1.2.1