1GPSD(8)                       GPSD Documentation                       GPSD(8)
2
3
4

NAME

6       gpsd - interface daemon for GPS receivers
7

SYNOPSSIS

9       gpsd [OPTIONS]
10
11       gpsd -h
12
13       gpsd -V
14

QUICK START

16       If you have a GPS attached on the lowest-numbered USB port of a Linux
17       system, and want to read reports from it on TCP/IP port 2947, it will
18       normally suffice to do this, as root:
19
20           # gpsd /dev/ttyUSB0
21
22       For the lowest-numbered serial port:
23
24           # gpsd /dev/ttyS0
25
26       gpsd may be started as a normal user, or by using sudo, but some
27       functionality will be lost.
28
29       Change the device number as appropriate if you need to use a different
30       port. Command-line flags enable verbose logging, a control port, and
31       other optional extras but should not be needed for basic operation; the
32       one exception, on very badly designed hardware, might be -b (which
33       see).
34
35       On Linux systems supporting udev, gpsd is normally started
36       automatically when a USB plugin event fires (if it is not already
37       running) and is handed the name of the newly active device. In that
38       case no invocation is required at all.
39
40       For your initial tests set your GPS hardware to speak NMEA, as gpsd is
41       guaranteed to be able to process that. If your GPS has a native or
42       binary mode with better performance that gpsd knows how to speak, gpsd
43       may autoconfigure that mode.
44
45       You can verify correct operation by first starting gpsd. Then xgps, the
46       X windows test client or cgps the curses based terminal client.
47
48       If you have problems, the GPSD project maintains a FAQ to assist
49       troubleshooting.
50

DESCRIPTION

52       gpsd is a monitor daemon that collects information from GPSes,
53       differential-GPS radios, or AIS receivers attached to the host machine.
54       Each GPS, DGPS radio, or AIS receiver is expected to be directly
55       connected to the host via a USB or RS232C serial device. The serial
56       device may be specified to gpsd at startup, or it may be set via a
57       command shipped down a local control socket (e.g. by a USB hotplug
58       script). Given a GPS device by either means, gpsd discovers the correct
59       port speed and protocol for it.
60
61       gpsd should be able to query any GPS that speaks either the standard
62       textual NMEA 0183 protocol, or the (differing) extended NMEA dialects
63       used by MKT-3301, iTrax, Motorola OnCore, Sony CXD2951, Ashtech/Thales
64       and some other devices. It can also interpret the binary protocols used
65       by EverMore, Garmin, Javad, Navcom, Rockwell/Zodiac, SiRF, Trimble, and
66       u-blox devices. Under Linux it can read NMEA2000 packets through the
67       kernel CAN socket. It can read heading and attitude information from
68       the Oceanserver 5000 or TNT Revolution digital compasses.
69
70       The GPS reporting formats supported by your binary of gpsd may differ
71       depending on how it was compiled; general-purpose versions support
72       many, but it can be built with protocol subsets down to a singleton for
73       use in constrained environments. For a list of the GPS protocols
74       supported by your binary, see the output of gpsd -l
75
76       gpsd effectively hides the differences among the GPS types it supports.
77       It also knows about and uses commands that tune these GPSes for lower
78       latency. By using gpsd as an intermediary, applications avoid
79       contention for serial devices.
80
81       gpsd can use differential-GPS corrections from a DGPS radio or over the
82       net, from a ground station running a DGPSIP server or a Ntrip
83       broadcaster that reports RTCM-104 data; this may shrink position
84       errors. When gpsd opens a serial device emitting RTCM-104, it
85       automatically recognizes this and uses the device as a correction
86       source for all connected GPSes that accept RTCM corrections (this is
87       dependent on the type of the GPS; not all GPSes have the firmware
88       capability to accept RTCM correction packets).
89
90       Client applications typically communicate with gpsd via a TCP/IP port,
91       port 2947 by default. Both IPv4 and IPv6 connections are supported and
92       a client may connect via either.
93

OPTIONS

95       The program accepts the following options:
96
97       -?, -h, ---help
98           Display help message and terminate.
99
100       -b, --readonly
101           Broken-device-safety mode, otherwise known as read-only mode. A few
102           bluetooth and USB receivers lock up or become totally inaccessible
103           when probed or reconfigured; see the hardware compatibility list on
104           the GPSD project website for details. This switch prevents gpsd
105           from writing to a receiver. This means that gpsd cannot configure
106           the receiver for optimal performance, but it also means that gpsd
107           cannot break the receiver. A better solution would be for Bluetooth
108           to not be so fragile. A platform independent method to identify
109           serial-over-Bluetooth devices would also be nice.
110
111       -D LVL, --debug LVL
112           Set debug level. Default is 0. At debug levels 2 and above, gpsd
113           reports incoming sentence and actions to standard error if gpsd is
114           in the foreground (-N) or to syslog if in the background. See
115           LOGGING below.
116
117       -F FILE, --sockfile FILE
118           Create a control socket for device addition and removal commands.
119           Default is None. You must specify a valid pathname on your local
120           filesystem; this will be created as a Unix-domain socket to which
121           you can write commands that edit the daemon’s internal device list.
122
123       -f FRAME, --framing FRAME
124           Fix the framing to the GNSS device. The framing parameter is of the
125           form: [78][ENO][012]. Most GNSS are 8N1. Some Trimble default to
126           8O1. The default is to search for the correct framing.
127
128       -G, --listenany
129           This flag causes gpsd to listen on all addresses (INADDR_ANY)
130           rather than just the loop back (INADDR_LOOPBACK) address. For the
131           sake of privacy and security, gpsd information is private by
132           default to the local machine until the user makes an effort to
133           expose this to the world.
134
135       -l, --drivers
136           List all drivers compiled into this gpsd instance. The letters to
137           the left of each driver name are the gpsd control commands
138           supported by that driver. Then exit.
139
140       -n, --nowait
141           Don’t wait for a client to connect before polling whatever GPS is
142           associated with it. Some RS232 GPSes wait in a standby mode
143           (drawing less power) when the host machine is not asserting DTR,
144           and some cellphone and handheld embedded GPSes have similar
145           behaviors. Accordingly, waiting for a watch request to open the
146           device may save battery power. (This capability is rare in
147           consumer-grade devices). You should use this option if you plan to
148           use gpsd to provide reference clock information to ntpd or chronyd.
149           This option will also enable clients to see data from the receiver
150           sooner on connection.
151
152       -N, --foreground
153           Don’t daemonize; run in foreground. This switch is mainly useful
154           for debugging.
155
156       -p, --passive
157           Passive mode. Do not autoconfigure the receiver, but allow manual
158           configuration changes.
159
160       -P FILE, --pidfile FILE
161           Specify the name and path to record the daemon’s process ID.
162
163       -r, --badtime
164           Use GPS time even with no current fix. Some GPSs have battery
165           powered Real Time Clocks (RTC’s) built in, making them a valid time
166           source even before a fix is acquired. This can be useful on a
167           Raspberry Pi, or other device that has no battery powered RTC, and
168           thus has no valid time at startup. Use with caution.
169
170       --port PORT, -S PORT
171           Set TCP/IP port on which to listen for GPSD clients (default is
172           2947).
173
174       -s SPEED, --speed SPEED
175           Fix the serial port speed to the GNSS device. Allowed speeds are:
176           4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800 and 921600.
177           The default is to autobaud. Note that some devices with integrated
178           USB ignore port speed.
179
180       -V, --version
181           Dump version and exit.
182
183       Arguments are interpreted as the names of data sources. Normally, a
184       data source is the device pathname of a local device from which the
185       daemon may expect GPS data. But there are three other special source
186       types recognized, for a total of four:
187
188       Local serial or USB device
189           A normal Unix device name of a serial or USB device to which a
190           sensor is attached. Examples: /dev/ttyS0, or /dev/ttyUSB0.
191
192       Local PPS device
193           A normal Unix device name of a PPS device to which a PPS source is
194           attached. The device name must start with "/dev/pps" and a local
195           serial or USB GPS device must also be available. Example:
196           /dev/pps0.
197
198       TCP feed
199           A URI with the prefix "tcp://", followed by a hostname, a colon,
200           and a port number. The daemon will open a socket to the indicated
201           address and port and read data packets from it, which will be
202           interpreted as though they had been issued by a serial device.
203           Example: tcp://data.aishub.net:4006.
204
205       UDP feed
206           A URI with the prefix "udp://", followed by a hostname, a colon,
207           and a port number. The daemon will open a socket listening for UDP
208           datagrams arriving in the indicated address and port, which will be
209           interpreted as though they had been issued by a serial device.
210           Example: udp://127.0.0.1:5000.
211
212       Ntrip caster
213           A URI with the prefix "ntrip://" followed by the name of an Ntrip
214           caster (Ntrip is a protocol for broadcasting differential-GPS fixes
215           over the net). For Ntrip services that require authentication, a
216           prefix of the form "username:password@" can be added before the
217           name of the Ntrip broadcaster. For Ntrip service, you must specify
218           which stream to use; the stream is given in the form "/streamname".
219           An example DGPSIP URI could be "dgpsip://dgpsip.example.com" and a
220           Ntrip URI could be
221           "ntrip://foo:bar@ntrip.example.com:80/example-stream". Corrections
222           from the caster will be sent to each attached GPS with the
223           capability to accept them.
224
225       DGPSIP server
226           A URI with the prefix "dgpsip://" followed by a hostname, a colon,
227           and an optional colon-separated port number (defaulting to 2101).
228           The daemon will handshake with the DGPSIP server and read RTCM2
229           correction data from it. Corrections from the server will be set to
230           each attached GPS with the capability to accept them. Example:
231           dgpsip://dgps.wsrcc.com:2101.
232
233       Remote gpsd feed
234           A URI with the prefix "gpsd://", followed by a hostname and
235           optionally a colon and a port number (if the port is absent the
236           default gpsd port will be used). Then followed optionally by a
237           second colon and the remote device name The daemon will open a
238           socket to the indicated address and port and emulate a gpsd client,
239           collecting JSON reports from the remote gpsd instance that will be
240           passed to local clients. Example: gpsd://gpsd.io:2947:/dev/ttyAMA0.
241
242       NMEA2000 CAN data
243           A URI with the prefix "nmea2000://", followed by a CAN devicename.
244           Only Linux socket CAN interfaces are supported. The interface must
245           be configured to receive CAN messages before gpsd can be started.
246           If there is more than one unit on the CAN bus that provides GPS
247           data, gpsd chooses the unit from which a GPS message is first seen.
248           Example: nmea2000://can0.
249
250       (The "ais:://" source type supported in some older versions of the
251       daemon has been retired in favor of the more general "tcp://".)
252
253       Additionally, two serial device name have a side effect, if your binary
254       was compiled with the MAGIC_HAT option:
255
256       /dev/ttyAMA0
257           The UART device on a Raspberry Pi. Has the side effect of opening
258           /dev/pps0 for RFC2783 1PPS data.
259
260       /dev/gpsd0
261           Generic GPS device 0. Has the side effect of opening /dev/pps0 for
262           RFC2783 1PPS data.
263
264       Note, however, that if /dev/pps0 is the fake "ktimer" PPS, then
265       /dev/pps1 will be used instead.
266
267       Internally, the daemon maintains a device pool holding the pathnames of
268       devices and remote servers known to the daemon. Initially, this list is
269       the list of device-name arguments specified on the command line. That
270       list may be empty, in which case the daemon will have no devices on its
271       search list until they are added by a control-socket command. Daemon
272       startup will abort with an error if no devices and no control socket is
273       specified.
274
275       When a device is activated (i.e. a client requests data from it), gpsd
276       attempts to execute a hook from /etc/gpsd/device-hook with first
277       command line argument set to the pathname of the device and the second
278       to ACTIVATE. On deactivation, it does the same passing DEACTIVATE for
279       the second argument.
280
281       gpsd can export data to client applications in three ways: via a
282       sockets interface, via a shared-memory segment, and via D-Bus. The next
283       three major sections describe these interfaces.
284

LOGGING

286       When gpsd is running as a daemon (not in the foreground) is sends all
287       of its logging to syslog(3). Logging is sent with ident "gpsd" using
288       facility "LOG_USER".
289
290       If you are using syslog-ng, then you can send all gpsd logs to a file
291       /var/log/gpsd. Put this at the end of your
292       /etc/syslog-ng/syslog-ng.conf file:
293
294           destination gpsdf { file("/var/log/gpsd"); };
295           filter f_gpsd { program("gpsd"); };
296           log { source(src); filter(f_gpsd); destination(gpsdf); };
297

THE SOCKET INTERFACE

299       Clients may communicate with the daemon via textual request and
300       responses over a socket. It is a bad idea for applications to speak the
301       protocol directly: rather, they should use the libgps client library
302       and take appropriate care to conditionalize their code on the major and
303       minor protocol version symbols.
304
305       The request-response protocol for the socket interface is fully
306       documented in gpsd_json(5).
307

SHARED-MEMORY AND DBUS INTERFACES

309       gpsd has two other (read-only) interfaces.
310
311       Whenever the daemon recognizes a packet from any attached device, it
312       writes the accumulated state from that device to a shared memory
313       segment. The C and C++ client libraries shipped with GPSD can read this
314       segment. Client methods, and various restrictions associated with the
315       read-only nature of this interface, are documented at libgps(3). The
316       shared-memory interface is intended primarily for embedded deployments
317       in which gpsd monitors a single device, and its principal advantage is
318       that a daemon instance configured with shared memory but without the
319       sockets interface loses a significant amount of runtime weight.
320
321       The daemon may be configured to emit a D-Bus signal each time an
322       attached device delivers a fix. The signal path is "path /org/gpsd",
323       the signal interface is "org.gpsd", and the signal name is "fix". The
324       signal payload layout is as follows:
325
326       Table 1. Satellite object
327       ┌─────────────────┬───────────────────────────┐
328       │                 │                           │
329       │Type             │ Description               │
330       ├─────────────────┼───────────────────────────┤
331       │                 │                           │
332       │DBUS_TYPE_DOUBLE │ Time (seconds since Unix  │
333       │                 │ epoch)                    │
334       ├─────────────────┼───────────────────────────┤
335       │                 │                           │
336       │DBUS_TYPE_INT32  │ mode                      │
337       ├─────────────────┼───────────────────────────┤
338       │                 │                           │
339       │DBUS_TYPE_DOUBLE │ Time uncertainty          │
340       │                 │ (seconds).                │
341       ├─────────────────┼───────────────────────────┤
342       │                 │                           │
343       │DBUS_TYPE_DOUBLE │ Latitude in degrees.      │
344       ├─────────────────┼───────────────────────────┤
345       │                 │                           │
346       │DBUS_TYPE_DOUBLE │ Longitude in degrees.     │
347       ├─────────────────┼───────────────────────────┤
348       │                 │                           │
349       │DBUS_TYPE_DOUBLE │ Horizontal uncertainty in │
350       │                 │ meter.                    │
351       ├─────────────────┼───────────────────────────┤
352       │                 │                           │
353       │DBUS_TYPE_DOUBLE │ Altitude MSL in meters.   │
354       ├─────────────────┼───────────────────────────┤
355       │                 │                           │
356       │DBUS_TYPE_DOUBLE │ Altitude uncertainty in   │
357       │                 │ meters.                   │
358       ├─────────────────┼───────────────────────────┤
359       │                 │                           │
360       │DBUS_TYPE_DOUBLE │ Course in degrees from    │
361       │                 │ true north.               │
362       ├─────────────────┼───────────────────────────┤
363       │                 │                           │
364       │DBUS_TYPE_DOUBLE │ Course uncertainty in     │
365       │                 │ meters                    │
366       ├─────────────────┼───────────────────────────┤
367       │                 │                           │
368       │DBUS_TYPE_DOUBLE │ Speed, meters per second. │
369       ├─────────────────┼───────────────────────────┤
370       │                 │                           │
371       │DBUS_TYPE_DOUBLE │ Speed uncertainty in      │
372       │                 │ meters per second.        │
373       ├─────────────────┼───────────────────────────┤
374       │                 │                           │
375       │DBUS_TYPE_DOUBLE │ Climb, meters per second. │
376       ├─────────────────┼───────────────────────────┤
377       │                 │                           │
378       │DBUS_TYPE_DOUBLE │ Climb uncertainty in      │
379       │                 │ meters per second.        │
380       ├─────────────────┼───────────────────────────┤
381       │                 │                           │
382       │DBUS_TYPE_STRING │ Device name               │
383       └─────────────────┴───────────────────────────┘
384
385       Uncertainty values are provided by the GNSS receiver. Check your
386       receiver documentation to see if is specifies what its "uncertainty"
387       means.
388

GPS DEVICE MANAGEMENT

390       gpsd maintains an internal list of GPS devices (the "device pool"). If
391       you specify devices on the command line, the list is initialized with
392       those pathnames, otherwise the list starts empty. Commands to add and
393       remove GPS device paths from the daemon’s device list must be written
394       to a local Unix-domain socket which will be accessible only to programs
395       running as root. This control socket will be located wherever the -F
396       option specifies it.
397
398       A device may will also be dropped from the pool if GPSD gets a zero
399       length read from it. This end-of-file condition indicates that the
400       device has been disconnected.
401
402       When gpsd is installed along with working hotplug notifier scripts
403       feeding it device-add commands over the control socket, gpsd should
404       require no configuration or user action to find hotplug devices.
405
406       Sending SIGHUP to a running gpsd forces it to close all GPSes and all
407       client connections. It will then attempt to reconnect to any GPSes on
408       its device list and resume listening for client connections. This may
409       be useful if your GPS enters a wedged or confused state but can be
410       soft-reset by pulling down DTR.
411
412       When gpsd is called with no initial devices (thus, expecting devices to
413       be passed to it by notifications to the control socket), and reaches a
414       state where there are no devices connected and no subscribers after
415       some devices have been seen, it shuts down gracefully. It is expected
416       that future device hotplug events will reactivate it.
417
418       To point gpsd at a device that may be a GPS, write to the control
419       socket a plus sign ('+') followed by the device name followed by LF or
420       CR-LF. Thus, to point the daemon at /dev/foo. send "+/dev/foo\n". To
421       tell the daemon that a device has been disconnected and is no longer
422       available, send a minus sign ('-') followed by the device name followed
423       by LF or CR-LF. Thus, to remove /dev/foo from the search list, send
424       "-/dev/foo\n".
425
426       To send a control string to a specified device, write to the control
427       socket a '!', followed by the device name, followed by '=', followed by
428       the control string.
429
430       To send a binary control string to a specified device, write to the
431       control socket a '&', followed by the device name, followed by '=',
432       followed by the control string in paired hex digits.
433
434       Your client may await a response, which will be a line beginning with
435       either "OK" or "ERROR". An ERROR response to an 'add' command means the
436       device did not emit data recognizable as GPS packets, an ERROR response
437       to a remove command means the specified device was not in gpsd’s device
438       pool. An ERROR response to a '!' command means the daemon did not
439       recognize the devicename specified.
440
441       The control socket is intended for use by hotplug scripts and other
442       device-discovery services. This control channel is separate from the
443       public gpsd service port, and only locally accessible, in order to
444       prevent remote denial-of-service and spoofing attacks.
445

ACCURACY

447       The base User Estimated Range Error (UERE) of GPSes is 8 meters or less
448       at 66% confidence, 15 meters or less at 95% confidence. Actual
449       horizontal error will be UERE times a dilution factor dependent on
450       current satellite position. Altitude determination is more sensitive to
451       variability in ionospheric signal lag than latitude/longitude is, and
452       is also subject to errors in the estimation of local mean sea level,
453       base error is 12 meters at 66% confidence, 23 meters at 95% confidence.
454       Again, this will be multiplied by a vertical dilution of precision
455       (VDOP) dependent on satellite geometry, and VDOP is typically larger
456       than HDOP. Users should not rely on GPS altitude for life-critical
457       tasks such as landing an airplane.
458
459       These errors are intrinsic to the design and physics of the GPS system.
460       gpsd does its internal computations at sufficient accuracy that it will
461       add no measurable position error of its own.
462
463       DGPS correction may reduce UERE, provided you are within about 100
464       miles (160 km) of a DGPS ground station from which you are receiving
465       corrections.
466
467       On a 4800bps connection, the time latency of fixes provided by gpsd
468       will be one second or less 95% of the time. Most of this lag is due to
469       the fact that GPSes normally emit fixes once per second, thus expected
470       latency is 0.5sec. On the personal-computer hardware available in 2005
471       and later, computation lag induced by gpsd will be negligible, on the
472       order of a millisecond. Nevertheless, latency can introduce significant
473       errors for vehicles in motion, at 50 km/h (31 mi/h) of speed over
474       ground, 1 second of lag corresponds to 13.8 meters change in position
475       between updates.
476
477       The time reporting of the GPS system itself has an intrinsic accuracy
478       limit of 14 nanoseconds, but this can only be approximated by
479       specialized receivers using that send the high-accuracy PPS
480       (Pulse-Per-Second) over RS232 to cue a clock crystal. Most GPS
481       receivers only report time to a precision of 0.01s or 0.001s, and with
482       no accuracy guarantees below 1sec.
483
484       If your GPS uses a SiRF chipset at firmware level 231, reported UTC
485       time may be off by the difference between whatever default leap-second
486       offset has been compiled in and whatever leap-second correction is
487       currently applicable, from startup until complete subframe information
488       is received. Firmware levels 232 and up don’t have this problem. You
489       may run gpsd at debug level 4 to see the chipset type and firmware
490       revision level.
491
492       There are exactly two circumstances under which gpsd relies on the
493       host-system clock:
494
495       In the GPS broadcast signal, GPS time is represented using a week
496       number that rolls over after 2^10 or 2^13 weeks (about 19.6 years, or
497       157 years), depending on the spacecraft. Receivers are required to
498       disambiguate this to the correct date, but may have difficulty due to
499       not knowing time to within half this interval, or may have bugs. Users
500       have reported incorrect dates which appear to be due to this issue.
501       gpsd uses the startup time of the daemon detect and compensate for
502       rollovers while it is running, but otherwise reports the date as it is
503       reported by the receiver without attempting to correct it.
504
505       If you are using an NMEA-only GPS (that is, not using SiRF or Garmin or
506       Zodiac binary mode), gpsd relies on the system clock to tell it the
507       current century. If the system clock returns an invalid value near
508       zero, and the GPS does not emit GPZDA at the start of its update cycle
509       (which most consumer-grade NMEA GPSes do not) then the century part of
510       the dates gpsd delivers may be wrong. Additionally, near the century
511       turnover, a range of dates as wide in seconds as the accuracy of your
512       system clock may be referred to the wrong century.
513

USE WITH NTP

515       gpsd can provide reference clock information to ntpd or chronyd, to
516       keep the system clock synchronized to the time provided by the GPS
517       receiver.
518
519       On Linux, gpsd includes support for interpreting the PPS pulses emitted
520       at the start of every clock second on the carrier-detect lines of some
521       serial GPSes, this pulse can be used to update NTP at much higher
522       accuracy than message time provides. You can determine whether your GPS
523       emits this pulse by running at -D 5 and watching for carrier-detect
524       state change messages in the logfile. In addition, if your kernel
525       provides the RFC 2783 kernel PPS API then gpsd will use that for extra
526       accuracy.
527
528       gpsd communicates with ntpd using shared memory segments (SHMs). The
529       SHMs are numbered SHM(0) to SHM(7). and have a name (key) of NTP0 to
530       NTP7. The first local time source on the command line may use NTP0 and
531       NTP1. The second may use NTP2 and NTP3, etc.
532
533       You can see the output of gpsd to ntpd in real time with the ntpshmmon
534       command.
535
536       Other daemons, such as ptp4l may also be using the same SHMs to talk to
537       ntpd.
538
539       Detailed instructions for using GPSD to set up a high-quality time
540       service can be found among the documentation on the GPSD website.
541

USE WITH D-BUS

543       On operating systems that support D-BUS, gpsd can be built to broadcast
544       GPS fixes to D-BUS-aware applications. As D-BUS is still at a pre-1.0
545       stage, we will not attempt to document this interface here. Read the
546       gpsd source code to learn more.
547

SECURITY AND PERMISSIONS ISSUES

549       gpsd, if given the -G flag, will listen for connections from any
550       reachable host, and then disclose the current position. Before using
551       the -G flag, consider whether you consider your computer’s location to
552       be sensitive data to be kept private or something that you wish to
553       publish.
554
555       gpsd must start up as root in order to open the NTPD shared-memory
556       segment, open its logfile, and create its local control socket. Note
557       that starting gpsd with sudo is not the same as starting as root.
558       Before doing any processing of GPS data, it tries to drop root
559       privileges by setting its UID to "nobody" (or another configured
560       userid) and its group ID to the group of the initial GPS passed on the
561       command line — or, if that device doesn’t exist, to the group of
562       /dev/ttyS0.
563
564       Privilege-dropping is a hedge against the possibility that carefully
565       crafted data, either presented from a client socket or from a subverted
566       serial device posing as a GPS, could be used to induce misbehavior in
567       the internals of gpsd. It ensures that any such compromises cannot be
568       used for privilege elevation to root.
569
570       The assumption behind gpsd’s particular behavior is that all the tty
571       devices to which a GPS might be connected are owned by the same
572       non-root group and allow group read/write, though the group may vary
573       because of distribution-specific or local administrative practice. If
574       this assumption is false, gpsd may not be able to open GPS devices in
575       order to read them (such failures will be logged).
576
577       In order to fend off inadvertent denial-of-service attacks by port
578       scanners (not to mention deliberate ones), gpsd will time out inactive
579       client connections. Before the client has issued a command that
580       requests a channel assignment, a short timeout (60 seconds) applies.
581       There is no timeout for clients in watcher or raw modes; rather, gpsd
582       drops these clients if they fail to read data long enough for the
583       outbound socket write buffer to fill. Clients with an assigned device
584       in polling mode are subject to a longer timeout (15 minutes).
585

LIMITATIONS

587       If multiple NMEA talkers are feeding RMC, GLL, and GGA sentences to the
588       same serial device (possible with an RS422 adapter hooked up to some
589       marine-navigation systems), a 'TPV' response may mix an altitude from
590       one device’s GGA with latitude/longitude from another’s RMC/GLL after
591       the second sentence has arrived.
592
593       gpsd may change control settings on your GPS (such as the emission
594       frequency of various sentences or packets) and not restore the original
595       settings on exit. This is a result of inadequacies in NMEA and the
596       vendor binary GPS protocols, which often do not give clients any way to
597       query the values of control settings in order to be able to restore
598       them later.
599
600       Some receivers do not report VDOP/TDOP/GDOP figures and associated
601       error estimates. In that case they may be computed by gpsd instead.
602       This computation does not exactly match what chips do internally, which
603       includes some satellite weighting using parameters gpsd cannot see.
604
605       Autobauding on the Trimble GPSes can take as long as 20 seconds, or
606       more, if the device speed is not matched to the GPS speed. Use the -s
607       option to avoid autobaud delays.
608
609       Generation of position error estimates (eph, epv, epd, eps, epc) from
610       the incomplete data handed back by GPS reporting protocols involves
611       both a lot of mathematical black art and fragile device-dependent
612       assumptions. This code has been bug-prone in the past and problems may
613       still lurk there.
614
615       AIDVM decoding of types 16-17, 22-23, and 25-26 is unverified.
616
617       GPSD presently fully recognizes only the 2.1 level of RTCM2 (message
618       types 1, 3, 4, 5, 6, 7, 9, 16). The 2.3 message types 13, 14, and 31
619       are recognized and reported. Message types 8, 10-12, 15-27, 28-30
620       (undefined), 31-37, 38-58 (undefined), and 60-63 are not yet supported.
621
622       The ISGPS used for RTCM2 and subframes decoder logic is sufficiently
623       convoluted to confuse some compiler optimizers, notably in GCC 3.x at
624       -O2, into generating bad code.
625
626       Devices meant to use PPS for high-precision timekeeping may fail if
627       they are specified after startup by a control-socket command, as
628       opposed to on the daemon’s original command line. Root privileges are
629       dropped early, and some Unix variants require them in order to set the
630       PPS line discipline. Under Linux the POSIX capability to set the line
631       discipline is retained, but other platforms cannot use this code.
632
633       USB GPS devices often do not identify themselves through the USB
634       subsystem; they typically present as the class 00h (undefined) or class
635       FFh (vendor-specific) of USB-to-serial adapters. Because of this, the
636       Linux hotplug scripts must tell gpsd to sniff data from every
637       USB-to-serial adapter that goes active and is known to be of a type
638       used in GPSes. No such device is sent configuration strings until after
639       it has been identified as a GPS, and gpsd never opens a device that is
640       opened by another process. But there is a tiny window for non-GPS
641       devices not opened; if the application that wants them loses a race
642       with GPSD its device open will fail and have to be retried after GPSD
643       sniffs the device (normally less than a second later).
644

FILES

646       /dev/ttyS0
647           Prototype TTY device. After startup, gpsd sets its group ID to the
648           owning group of this device if no GPS device was specified on the
649           command line does not exist.
650
651       /etc/gpsd/device-hook
652           Optional file containing the device activation/deactivation script.
653           Note that while /etc/gpsd is the default system configuration
654           directory, it is possible to build the GPSD source code with
655           different assumptions. See above for further details on the
656           device-hook mechanism.
657

ENVIRONMENT VARIABLES

659       By setting the environment variable GPSD_SHM_KEY, you can control the
660       key value used to create the shared-memory segment used for
661       communication with the client library. This will be useful mainly when
662       isolating test instances of gpsd from production ones.
663

RETURN VALUES

665       0
666           on success.
667
668       1
669           on failure
670

APPLICABLE STANDARDS

672       The official NMEA protocol standards for NMEA0183 and NMEA2000 are
673       available from the National Marine Electronics Association, but are
674       proprietary and expensive; the maintainers of gpsd have made a point of
675       not looking at them. The GPSD project website links to several
676       documents that collect publicly disclosed information about the
677       protocol.
678
679       gpsd parses the following NMEA sentences: RMC, GGA, GLL, GSA, GSV, VTG,
680       ZDA, GBS, HDT, DBT, GST. It recognizes these with either the normal GP
681       talker-ID prefix, or with the GN prefix used by GLONASS, or with the II
682       prefix emitted by Seahawk Autohelm marine navigation systems, or with
683       the IN prefix emitted by some Garmin units, or with the EC prefix
684       emitted by ECDIS units, or with the SD prefix emitted by depth
685       sounders, or with the HC and TI prefix emitted by some Airmar
686       equipment. It recognizes some vendor extensions: the PGRME emitted by
687       some Garmin GPS models, the OHPR emitted by Oceanserver digital
688       compasses, the PTNTHTM emitted by True North digital compasses, the
689       PMTK omitted by some San Jose Navigation GPSes, and the PASHR sentences
690       emitted by some Ashtech GPSes.
691
692       Note that gpsd JSON returns pure decimal degrees, not the hybrid
693       degree/minute format described in the NMEA standard.
694
695       Differential-GPS corrections are conveyed by the RTCM protocols. The
696       applicable standard for RTCM-104 V2 is RTCM Recommended Standards for
697       Differential GNSS (Global Navigation Satellite) Service RTCM Paper
698       136-2001/SC 104-STD. The applicable standard for RTCM-104 V3 is RTCM
699       Standard 10403.1 for Differential GNSS Services - Version 3 RTCM Paper
700       177-2006-SC104-STD. Ordering instructions for the RTCM standards are
701       accessible from the website of the Radio Technical Commission for
702       Maritime Services under "Publications".
703
704       AIS is defined by ITU Recommendation M.1371, Technical Characteristics
705       for a Universal Shipborne Automatic Identification System Using Time
706       Division Multiple Access. The AIVDM/AIVDO format understood by this
707       program is defined by IEC-PAS 61162-100, Maritime navigation and
708       radiocommunication equipment and systems. A more accessible description
709       of both can be found at AIVDM/AIVDO Protocol Decoding, on the
710       references page of the GPSD project website.
711
712       Subframe data is defined by IS-GPS-200, GLOBAL POSITIONING SYSTEM WING
713       (GPSW) SYSTEMS ENGINEERING & INTEGRATION, INTERFACE SPECIFICATION
714       IS-GPS-200. The format understood by this program is defined in Section
715       20 (Appendix II),
716
717       JSON is specified by RFC 7159, The JavaScript Object Notation (JSON)
718       Data Interchange Format.
719
720       The API for PPS time service is specified by RFC 2783, Pulse-Per-Second
721       API for UNIX-like Operating Systems, Version 1.0
722

AUTHORS

724       Authors: Eric S. Raymond, Chris Kuethe, Gary Miller. Former authors
725       whose bits have been plowed under by code turnover: Remco Treffcorn,
726       Derrick Brashear, Russ Nelson.
727
728       This manual page by Eric S. Raymond <esr@thyrsus.com>.
729

SEE ALSO

731       gpsd(8), gpsctl(1), gps(1), gpsprof(1), gpsfake(1). gpscat(1),
732       *ntpshmmon(1), libgps(3), libgpsmm(3), gpsd_json(5),  gpsdctl(8),
733       ntpd(8)
734

RESOURCES

736       Project web site: https://gpsd.io/ GPSD Time Service HOWTO:
737       https://gpsd.io/gpsd-time-service-howto.html Introduction to Time
738       Service: https://gpsd.io/time-service-intro.html
739

COPYING

741       This file is Copyright 2013 by the GPSD project
742       SPDX-License-Identifier: BSD-2-clause
743
744
745
746GPSD, Version 3.24                2022-04-27                           GPSD(8)
Impressum