1GPSD(8) GPSD Documentation GPSD(8)
2
6 gpsd - interface daemon for GPS receivers
7
9 gpsd [-?] [--badtime] [--debug LVL] [--drivers] [--foreground]
10 [--framing FRAMING] [--help] [--listenany] [--nowait]
11 [--pidfile FILE] [--port PORT] [--sockfile SOCK] [--speed SPEED]
12 [--verbose] [-b] [-D debuglevel] [-F control-socket] [-f framing]
13 [-G] [-h] [-l] [-n] [-N] [-P pidfile] [-r] [-S listener-port]
14 [-s speed] [-V] [[source-name]...]
15
17 If you have a GPS attached on the lowest-numbered USB port of a Linux
18 system, and want to read reports from it on TCP/IP port 2947, it will
19 normally suffice to do this:
20 gpsd /dev/ttyUSB0
22 For the lowest-numbered serial port:
24 gpsd /dev/ttyS0
26 Change the device number as appropriate if you need to use a different
28 port. Command-line flags enable verbose logging, a control port, and
29 other optional extras but should not be needed for basic operation; the
30 one exception, on very badly designed hardware, might be -b (which
31 see).
32 On Linux systems supporting udev, gpsd is normally started
34 automatically when a USB plugin event fires (if it is not already
35 running) and is handed the name of the newly active device. In that
36 case no invocation is required at all.
37 For your initial tests set your GPS hardware to speak NMEA, as gpsd is
39 guaranteed to be able to process that. If your GPS has a native or
40 binary mode with better performance that gpsd knows how to speak, gpsd
41 will autoconfigure that mode.
42 You can verify correct operation by first starting gpsd and then xgps,
44 the X windows test client.
45 If you have problems, the GPSD project maintains a FAQ to assist
47 troubleshooting.
48
50 gpsd is a monitor daemon that collects information from GPSes,
51 differential-GPS radios, or AIS receivers attached to the host machine.
52 Each GPS, DGPS radio, or AIS receiver is expected to be
53 direct-connected to the host via a USB or RS232C serial device. The
54 serial device may be specified to gpsd at startup, or it may be set via
55 a command shipped down a local control socket (e.g. by a USB hotplug
56 script). Given a GPS device by either means, gpsd discovers the correct
57 port speed and protocol for it.
58 gpsd should be able to query any GPS that speaks either the standard
60 textual NMEA 0183 protocol, or the (differing) extended NMEA dialects
61 used by MKT-3301, iTrax, Motorola OnCore, Sony CXD2951, and
62 Ashtech/Thales devices. It can also interpret the binary protocols used
63 by EverMore, Garmin, Navcom, Rockwell/Zodiac, SiRF, Trimble, and u-blox
64 ANTARIS devices. Under Linux it can read NMEA2000 packets through the
65 kernel CAN socket. It can read heading and attitude information from
66 the Oceanserver 5000 or TNT Revolution digital compasses.
67 The GPS reporting formats supported by your instance of gpsd may differ
69 depending on how it was compiled; general-purpose versions support
70 many, but it can be built with protocol subsets down to a singleton for
71 use in constrained environments. For a list of the GPS protocols
72 supported by your instance, see the output of gpsd -l
73 gpsd effectively hides the differences among the GPS types it supports.
75 It also knows about and uses commands that tune these GPSes for lower
76 latency. By using gpsd as an intermediary, applications avoid
77 contention for serial devices.
78 gpsd can use differential-GPS corrections from a DGPS radio or over the
80 net, from a ground station running a DGPSIP server or a Ntrip
81 broadcaster that reports RTCM-104 data; this will shrink position
82 errors by roughly a factor of four. When gpsd opens a serial device
83 emitting RTCM-104, it automatically recognizes this and uses the device
84 as a correction source for all connected GPSes that accept RTCM
85 corrections (this is dependent on the type of the GPS; not all GPSes
86 have the firmware capability to accept RTCM correction packets). See
87 the section called “ACCURACY” and the section called “FILES” for
88 discussion.
89 Client applications will communicate with gpsd via a TCP/IP port, port
91 2947 by default. Both IPv4 and IPv6 connections are supported and a
92 client may connect via either.
93 The program accepts the following options:
95 -?, -h, ---help
97 Display help message and terminate.
98 -b, --readonly
100 Broken-device-safety mode, otherwise known as read-only mode. A few
101 bluetooth and USB receivers lock up or become totally inaccessible
102 when probed or reconfigured; see the hardware compatibility list on
103 the GPSD project website for details. This switch prevents gpsd
104 from writing to a receiver. This means that gpsd cannot configure
105 the receiver for optimal performance, but it also means that gpsd
106 cannot break the receiver. A better solution would be for Bluetooth
107 to not be so fragile. A platform independent method to identify
108 serial-over-Bluetooth devices would also be nice.
109 -D LVL, --debug LVL
111 Set debug level. Default is 0. At debug levels 2 and above, gpsd
112 reports incoming sentence and actions to standard error if gpsd is
113 in the foreground (-N) or to syslog if in the background.
114 -F FILE, --sockfile FILE
116 Create a control socket for device addition and removal commands.
117 Default is None. You must specify a valid pathname on your local
118 filesystem; this will be created as a Unix-domain socket to which
119 you can write commands that edit the daemon's internal device list.
120 -f FRAME, --framing FRAME
122 Fix the framing to the GNSS device. The framing parameter is of the
123 form: [78][ENO][012]. Most GNSS are 8N1. Some Trimble default to
124 8O1. The default is to search for the correct framing.
125 -G, --listenany
127 This flag causes gpsd to listen on all addresses (INADDR_ANY)
128 rather than just the loop back (INADDR_LOOPBACK) address. For the
129 sake of privacy and security, TPV information is now private to the
130 local machine until the user makes an effort to expose this to the
131 world.
132 -l, --drivers
134 List all drivers compiled into this gpsd instance. The letters to
135 the left of each driver name are the gpsd control commands
136 supported by that driver. Then exit
137 n, --nowait
139 Don't wait for a client to connect before polling whatever GPS is
140 associated with it. Some RS232 GPSes wait in a standby mode
141 (drawing less power) when the host machine is not asserting DTR,
142 and some cellphone and handheld embedded GPSes have similar
143 behaviors. Accordingly, waiting for a watch request to open the
144 device may save battery power. (This capability is rare in
145 consumer-grade devices). You should use this option if you plan to
146 use gpsd to provide reference clock information to ntpd through a
147 memory-shared segment.
148 -N, --foreground
150 Don't daemonize; run in foreground. This switch is mainly useful
151 for debugging.
152 -p, --passive
154 Passive mode. Do not autoconfigure the receiver, but allow manual
155 configuration changes.
156 -P FILE, --pidfile FILE
158 Specify the name and path to record the daemon's process ID.
159 -r, --badtime
161 Use GPS time even with no current fix. Some GPSs have battery
162 powered Real Time Clocks (RTC's) built in, making them a valid time
163 source even before a fix is acquired. This can be useful on a
164 Raspberry Pi, or other device that has no battery powered RTC, and
165 thus has no valid time at startup.
166 --port PORT, -S PORT
168 Set TCP/IP port on which to listen for GPSD clients (default is
169 2947).
170 -s SPEED, --speed SPEED
172 Fix the serial port speed to the GNSS device. Allowed speeds are:
173 4800, 9600, 19200, 38400, 57600, 115200, 230400, and 460800. The
174 default is to autobaud. Note that some devices with integrated USB
175 ignore port speed.
176 -V, --version
178 Dump version and exit.
179 Arguments are interpreted as the names of data sources. Normally, a
181 data source is the device pathname of a local device from which the
182 daemon may expect GPS data. But there are three other special source
183 types recognized, for a total of four:
184 Local serial or USB device
186 A normal Unix device name of a serial or USB device to which a
187 sensor is attached. Example: /dev/ttyUSB0.
188 Local PPS device
190 A normal Unix device name of a PPS device to which a PPS source is
191 attached. The device name must start with "/dev/pps" and a local
192 serial or USB GPS device must also be available. Example:
193 /dev/pps0.
194 TCP feed
196 A URI with the prefix "tcp://", followed by a hostname, a colon,
197 and a port number. The daemon will open a socket to the indicated
198 address and port and read data packets from it, which will be
199 interpreted as though they had been issued by a serial device.
200 Example: tcp://data.aishub.net:4006.
201 UDP feed
203 A URI with the prefix "udp://", followed by a hostname, a colon,
204 and a port number. The daemon will open a socket listening for UDP
205 datagrams arriving in the indicated address and port, which will be
206 interpreted as though they had been issued by a serial device.
207 Example: udp://127.0.0.1:5000.
208 Ntrip caster
210 A URI with the prefix "ntrip://" followed by the name of an Ntrip
211 caster (Ntrip is a protocol for broadcasting differential-GPS fixes
212 over the net). For Ntrip services that require authentication, a
213 prefix of the form "username:password@" can be added before the
214 name of the Ntrip broadcaster. For Ntrip service, you must specify
215 which stream to use; the stream is given in the form "/streamname".
216 An example DGPSIP URI could be "dgpsip://dgpsip.example.com" and a
217 Ntrip URI could be
218 "ntrip://foo:bar@ntrip.example.com:80/example-stream". Corrections
219 from the caster will be sent to each attached GPS with the
220 capability to accept them.
221 DGPSIP server
223 A URI with the prefix "dgpsip://" followed by a hostname, a colon,
224 and an optional colon-separated port number (defaulting to 2101).
225 The daemon will handshake with the DGPSIP server and read RTCM2
226 correction data from it. Corrections from the server will be set to
227 each attached GPS with the capability to accept them. Example:
228 dgpsip://dgps.wsrcc.com:2101.
229 Remote gpsd feed
231 A URI with the prefix "gpsd://", followed by a hostname and
232 optionally a colon and a port number (if the port is absent the
233 default gpsd port will be used). Then followed optionally by a
234 second colon and the remote device name The daemon will open a
235 socket to the indicated address and port and emulate a gpsd client,
236 collecting JSON reports from the remote gpsd instance that will be
237 passed to local clients. Example: gpsd://gpsd.io:2947:/dev/ttyAMA0.
238 NMEA2000 CAN data
240 A URI with the prefix "nmea2000://", followed by a CAN devicename.
241 Only Linux socket CAN interfaces are supported. The interface must
242 be configured to receive CAN messages before gpsd can be started.
243 If there is more than one unit on the CAN bus that provides GPS
244 data, gpsd chooses the unit from which a GPS message is first seen.
245 Example: nmea2000://can0.
246 (The "ais:://" source type supported in some older versions of the
248 daemon has been retired in favor of the more general "tcp://".)
249 Additionally, two serial device names have a side effect:
251 /dev/ttyAMA0
253 The UART device on a Raspberry Pi. Has the side effect of opening
254 /dev/pps0 for RFC2783 1PPS data.
255 /dev/gpsd0
257 Generic GPS device 0. Has the side effect of opening /dev/pps0 for
258 RFC2783 1PPS data.
259 Note, however, that if /dev/pps0 is the fake "ktimer" PPS, then
261 /dev/pps1 will be used instead.
262 Internally, the daemon maintains a device pool holding the pathnames of
264 devices and remote servers known to the daemon. Initially, this list is
265 the list of device-name arguments specified on the command line. That
266 list may be empty, in which case the daemon will have no devices on its
267 search list until they are added by a control-socket command (see the
268 section called “GPS DEVICE MANAGEMENT” for details on this). Daemon
269 startup will abort with an error if neither any devices nor a control
270 socket are specified.
271 When a device is activated (i.e. a client requests data from it), gpsd
273 attempts to execute a hook from /etc/gpsd/device-hook with first
274 command line argument set to the pathname of the device and the second
275 to ACTIVATE. On deactivation, it does the same passing DEACTIVATE for
276 the second argument.
277 gpsd can export data to client applications in three ways: via a
279 sockets interface, via a shared-memory segment, and via D-Bus. The next
280 three major sections describe these interfaces.
281
283 Clients may communicate with the daemon via textual request and
284 responses over a socket. It is a bad idea for applications to speak the
285 protocol directly: rather, they should use the libgps client library
286 and take appropriate care to conditionalize their code on the major and
287 minor protocol version symbols.
288 The request-response protocol for the socket interface is fully
290 documented in gpsd_json(5).
291
293 gpsd has two other (read-only) interfaces.
294 Whenever the daemon recognizes a packet from any attached device, it
296 writes the accumulated state from that device to a shared memory
297 segment. The C and C++ client libraries shipped with GPSD can read this
298 segment. Client methods, and various restrictions associated with the
299 read-only nature of this interface, are documented at libgps(3). The
300 shared-memory interface is intended primarily for embedded deployments
301 in which gpsd monitors a single device, and its principal advantage is
302 that a daemon instance configured with shared memory but without the
303 sockets interface loses a significant amount of runtime weight.
304 The daemon may be configured to emit a D-Bus signal each time an
306 attached device delivers a fix. The signal path is path /org/gpsd, the
307 signal interface is "org.gpsd", and the signal name is "fix". The
308 signal payload layout is as follows:
309 Table 1. Satellite object
311 ┌─────────────────┬────────────────────────────┐
312 │Type │ │
313 │ │ Description │
314 ├─────────────────┼────────────────────────────┤
315 │DBUS_TYPE_DOUBLE │ │
316 │ │ Time (seconds since │
317 │ │ Unix epoch) │
318 ├─────────────────┼────────────────────────────┤
319 │DBUS_TYPE_INT32 │ │
320 │ │ mode │
321 ├─────────────────┼────────────────────────────┤
322 │DBUS_TYPE_DOUBLE │ │
323 │ │ Time uncertainty │
324 │ │ (seconds). │
325 ├─────────────────┼────────────────────────────┤
326 │DBUS_TYPE_DOUBLE │ │
327 │ │ Latitude in │
328 │ │ degrees. │
329 ├─────────────────┼────────────────────────────┤
330 │DBUS_TYPE_DOUBLE │ │
331 │ │ Longitude in │
332 │ │ degrees. │
333 ├─────────────────┼────────────────────────────┤
334 │DBUS_TYPE_DOUBLE │ │
335 │ │ Horizontal │
336 │ │ uncertainty in │
337 │ │ meters, 95% │
338 │ │ confidence. │
339 ├─────────────────┼────────────────────────────┤
340 │DBUS_TYPE_DOUBLE │ │
341 │ │ Altitude MSL in │
342 │ │ meters. │
343 ├─────────────────┼────────────────────────────┤
344 │DBUS_TYPE_DOUBLE │ │
345 │ │ Altitude │
346 │ │ uncertainty in │
347 │ │ meters, 95% │
348 │ │ confidence. │
349 ├─────────────────┼────────────────────────────┤
350 │DBUS_TYPE_DOUBLE │ │
351 │ │ Course in degrees │
352 │ │ from true north. │
353 ├─────────────────┼────────────────────────────┤
354 │DBUS_TYPE_DOUBLE │ │
355 │ │ Course uncertainty │
356 │ │ in meters, 95% │
357 │ │ confidence. │
358 ├─────────────────┼────────────────────────────┤
359 │DBUS_TYPE_DOUBLE │ │
360 │ │ Speed, meters per │
361 │ │ second. │
362 ├─────────────────┼────────────────────────────┤
363 │DBUS_TYPE_DOUBLE │ │
364 │ │ Speed uncertainty │
365 │ │ in meters per │
366 │ │ second, 95% │
367 │ │ confidence. │
368 ├─────────────────┼────────────────────────────┤
369 │DBUS_TYPE_DOUBLE │ │
370 │ │ Climb, meters per │
371 │ │ second. │
372 ├─────────────────┼────────────────────────────┤
373 │DBUS_TYPE_DOUBLE │ │
374 │ │ Climb uncertainty │
375 │ │ in meters per │
376 │ │ second, 95% │
377 │ │ confidence. │
378 ├─────────────────┼────────────────────────────┤
379 │DBUS_TYPE_STRING │ │
380 │ │ Device name │
381 └─────────────────┴────────────────────────────┘
382
384 gpsd maintains an internal list of GPS devices (the "device pool"). If
385 you specify devices on the command line, the list is initialized with
386 those pathnames; otherwise the list starts empty. Commands to add and
387 remove GPS device paths from the daemon's device list must be written
388 to a local Unix-domain socket which will be accessible only to programs
389 running as root. This control socket will be located wherever the -F
390 option specifies it.
391 A device may will also be dropped from the pool if GPSD gets a zero
393 length read from it. This end-of-file condition indicates that the
394 device has been disconnected.
395 When gpsd is properly installed along with hotplug notifier scripts
397 feeding it device-add commands over the control socket, gpsd should
398 require no configuration or user action to find devices.
399 Sending SIGHUP to a running gpsd forces it to close all GPSes and all
401 client connections. It will then attempt to reconnect to any GPSes on
402 its device list and resume listening for client connections. This may
403 be useful if your GPS enters a wedged or confused state but can be
404 soft-reset by pulling down DTR.
405 When gpsd is called with no initial devices (thus, expecting devices to
407 be passed to it by notifications to the control socket), and reaches a
408 state where there are no devices connected and no subscribers after
409 after some devices have been seen, it shuts down gracefully. It is
410 expected that future device hotplug events will reactivate it.
411 To point gpsd at a device that may be a GPS, write to the control
413 socket a plus sign ('+') followed by the device name followed by LF or
414 CR-LF. Thus, to point the daemon at /dev/foo. send "+/dev/foo\n". To
415 tell the daemon that a device has been disconnected and is no longer
416 available, send a minus sign ('-') followed by the device name followed
417 by LF or CR-LF. Thus, to remove /dev/foo from the search list, send
418 "-/dev/foo\n".
419 To send a control string to a specified device, write to the control
421 socket a '!', followed by the device name, followed by '=', followed by
422 the control string.
423 To send a binary control string to a specified device, write to the
425 control socket a '&', followed by the device name, followed by '=',
426 followed by the control string in paired hex digits.
427 Your client may await a response, which will be a line beginning with
429 either "OK" or "ERROR". An ERROR response to an 'add' command means the
430 device did not emit data recognizable as GPS packets; an ERROR response
431 to a remove command means the specified device was not in gpsd's device
432 pool. An ERROR response to a '!' command means the daemon did not
433 recognize the devicename specified.
434 The control socket is intended for use by hotplug scripts and other
436 device-discovery services. This control channel is separate from the
437 public gpsd service port, and only locally accessible, in order to
438 prevent remote denial-of-service and spoofing attacks.
439
441 The base User Estimated Range Error (UERE) of GPSes is 8 meters or less
442 at 66% confidence, 15 meters or less at 95% confidence. Actual
443 horizontal error will be UERE times a dilution factor dependent on
444 current satellite position. Altitude determination is more sensitive to
445 variability in ionospheric signal lag than latitude/longitude is, and
446 is also subject to errors in the estimation of local mean sea level;
447 base error is 12 meters at 66% confidence, 23 meters at 95% confidence.
448 Again, this will be multiplied by a vertical dilution of precision
449 (VDOP) dependent on satellite geometry, and VDOP is typically larger
450 than HDOP. Users should not rely on GPS altitude for life-critical
451 tasks such as landing an airplane.
452 These errors are intrinsic to the design and physics of the GPS system.
454 gpsd does its internal computations at sufficient accuracy that it will
455 add no measurable position error of its own.
456 DGPS correction will reduce UERE by a factor of 4, provided you are
458 within about 100 miles (160 km) of a DGPS ground station from which you
459 are receiving corrections.
460 On a 4800bps connection, the time latency of fixes provided by gpsd
462 will be one second or less 95% of the time. Most of this lag is due to
463 the fact that GPSes normally emit fixes once per second, thus expected
464 latency is 0.5sec. On the personal-computer hardware available in 2005
465 and later, computation lag induced by gpsd will be negligible, on the
466 order of a millisecond. Nevertheless, latency can introduce significant
467 errors for vehicles in motion; at 50 km/h (31 mi/h) of speed over
468 ground, 1 second of lag corresponds to 13.8 meters change in position
469 between updates.
470 The time reporting of the GPS system itself has an intrinsic accuracy
472 limit of 14 nanoseconds, but this can only be approximated by
473 specialized receivers using that send the high-accuracy PPS
474 (Pulse-Per-Second) over RS232 to cue a clock crystal. Most GPS
475 receivers only report time to a precision of 0.01s or 0.001s, and with
476 no accuracy guarantees below 1sec.
477 If your GPS uses a SiRF chipset at firmware level 231, reported UTC
479 time may be off by the difference between whatever default leap-second
480 offset has been compiled in and whatever leap-second correction is
481 currently applicable, from startup until complete subframe information
482 is received. Firmware levels 232 and up don't have this problem. You
483 may run gpsd at debug level 4 to see the chipset type and firmware
484 revision level.
485 There are exactly two circumstances under which gpsd relies on the
487 host-system clock:
488 In the GPS broadcast signal, GPS time is represented using a week
490 number that rolls over after 2^10 or 2^13 weeks (about 19.6 years, or
491 157 years), depending on the spacecraft. Receivers are required to
492 disambiguate this to the correct date, but may have difficulty due to
493 not knowing time to within half this interval, or may have bugs. Users
494 have reported incorrect dates which appear to be due to this issue.
495 gpsd uses the startup time of the daemon detect and compensate for
496 rollovers while it is running, but otherwise reports the date as it is
497 reported by the receiver without attempting to correct it.
498 If you are using an NMEA-only GPS (that is, not using SiRF or Garmin or
500 Zodiac binary mode), gpsd relies on the system clock to tell it the
501 current century. If the system clock returns an invalid value near
502 zero, and the GPS does not emit GPZDA at the start of its update cycle
503 (which most consumer-grade NMEA GPSes do not) then the century part of
504 the dates gpsd delivers may be wrong. Additionally, near the century
505 turnover, a range of dates as wide in seconds as the accuracy of your
506 system clock may be referred to the wrong century.
507
509 gpsd can provide reference clock information to ntpd, to keep the
510 system clock synchronized to the time provided by the GPS receiver.
511 On Linux, gpsd includes support for interpreting the PPS pulses emitted
513 at the start of every clock second on the carrier-detect lines of some
514 serial GPSes; this pulse can be used to update NTP at much higher
515 accuracy than message time provides. You can determine whether your GPS
516 emits this pulse by running at -D 5 and watching for carrier-detect
517 state change messages in the logfile. In addition, if your kernel
518 provides the RFC 2783 kernel PPS API then gpsd will use that for extra
519 accuracy.
520 Detailed instructions for using GPSD to set up a high-quality time
522 service can be found among the documentation on the GPSD website.
523
525 On operating systems that support D-BUS, gpsd can be built to broadcast
526 GPS fixes to D-BUS-aware applications. As D-BUS is still at a pre-1.0
527 stage, we will not attempt to document this interface here. Read the
528 gpsd source code to learn more.
529
531 gpsd, if given the -G flag, will listen for connections from any
532 reachable host, and then disclose the current position. Before using
533 the -G flag, consider whether you consider your computer's location to
534 be sensitive data to be kept private or something that you wish to
535 publish.
536 gpsd must start up as root in order to open the NTPD shared-memory
538 segment, open its logfile, and create its local control socket. Before
539 doing any processing of GPS data, it tries to drop root privileges by
540 setting its UID to "nobody" (or another configured userid) and its
541 group ID to the group of the initial GPS passed on the command line —
542 or, if that device doesn't exist, to the group of /dev/ttyS0.
543 Privilege-dropping is a hedge against the possibility that carefully
545 crafted data, either presented from a client socket or from a subverted
546 serial device posing as a GPS, could be used to induce misbehavior in
547 the internals of gpsd. It ensures that any such compromises cannot be
548 used for privilege elevation to root.
549 The assumption behind gpsd's particular behavior is that all the tty
551 devices to which a GPS might be connected are owned by the same
552 non-root group and allow group read/write, though the group may vary
553 because of distribution-specific or local administrative practice. If
554 this assumption is false, gpsd may not be able to open GPS devices in
555 order to read them (such failures will be logged).
556 In order to fend off inadvertent denial-of-service attacks by port
558 scanners (not to mention deliberate ones), gpsd will time out inactive
559 client connections. Before the client has issued a command that
560 requests a channel assignment, a short timeout (60 seconds) applies.
561 There is no timeout for clients in watcher or raw modes; rather, gpsd
562 drops these clients if they fail to read data long enough for the
563 outbound socket write buffer to fill. Clients with an assigned device
564 in polling mode are subject to a longer timeout (15 minutes).
565
567 If multiple NMEA talkers are feeding RMC, GLL, and GGA sentences to the
568 same serial device (possible with an RS422 adapter hooked up to some
569 marine-navigation systems), a 'TPV' response may mix an altitude from
570 one device's GGA with latitude/longitude from another's RMC/GLL after
571 the second sentence has arrived.
572 gpsd may change control settings on your GPS (such as the emission
574 frequency of various sentences or packets) and not restore the original
575 settings on exit. This is a result of inadequacies in NMEA and the
576 vendor binary GPS protocols, which often do not give clients any way to
577 query the values of control settings in order to be able to restore
578 them later.
579 When using SiRF chips, the VDOP/TDOP/GDOP figures and associated error
581 estimates are computed by gpsd rather than reported by the chip. The
582 computation does not exactly match what SiRF chips do internally, which
583 includes some satellite weighting using parameters gpsd cannot see.
584 Autobauding on the Trimble GPSes can take as long as 5 seconds if the
586 device speed is not matched to the GPS speed.
587 Generation of position error estimates (eph, epv, epd, eps, epc) from
589 the incomplete data handed back by GPS reporting protocols involves
590 both a lot of mathematical black art and fragile device-dependent
591 assumptions. This code has been bug-prone in the past and problems may
592 still lurk there.
593 AIDVM decoding of types 16-17, 22-23, and 25-26 is unverified.
595 GPSD presently fully recognizes only the 2.1 level of RTCM2 (message
597 types 1, 3, 4, 5, 6, 7, 9, 16). The 2.3 message types 13, 14, and 31
598 are recognized and reported. Message types 8, 10-12, 15-27, 28-30
599 (undefined), 31-37, 38-58 (undefined), and 60-63 are not yet supported.
600 The ISGPS used for RTCM2 and subframes decoder logic is sufficiently
602 convoluted to confuse some compiler optimizers, notably in GCC 3.x at
603 -O2, into generating bad code.
604 Devices meant to use PPS for high-precision timekeeping may fail if
606 they are specified after startup by a control-socket command, as
607 opposed to on the daemon's original command line. Root privileges are
608 dropped early, and some Unix variants require them in order to set the
609 PPS line discipline. Under Linux the POSIX capability to set the line
610 discipline is retained, but other platforms cannot use this code.
611 USB GPS devices often do not identify themselves through the USB
613 subsystem; they typically present as the class 00h (undefined) or class
614 FFh (vendor-specific) of USB-to-serial adapters. Because of this, the
615 Linux hotplug scripts must tell gpsd to sniff data from every
616 USB-to-serial adapter that goes active and is known to be of a type
617 used in GPSes. No such device is sent configuration strings until after
618 it has been identified as a GPS, and gpsd never opens a device that is
619 opened by another process. But there is a tiny window for non-GPS
620 devices not opened; if the application that wants them loses a race
621 with GPSD its device open will fail and have to be retried after GPSD
622 sniffs the device (normally less than a second later).
623
625 /dev/ttyS0
626 Prototype TTY device. After startup, gpsd sets its group ID to the
627 owning group of this device if no GPS device was specified on the
628 command line does not exist.
629 /etc/gpsd/device-hook
631 Optional file containing the device activation/deactivation script.
632 Note that while /etc/gpsd is the default system configuration
633 directory, it is possible to build the GPSD source code with
634 different assumptions. See above for further details on the
635 device-hook mechanism.
636
638 By setting the environment variable GPSD_SHM_KEY, you can control the
639 key value used to create the shared-memory segment used for
640 communication with the client library. This will be useful mainly when
641 isolating test instances of gpsd from production ones.
642
644 The official NMEA protocol standards for NMEA0183 and NMEA2000 are
645 available from the National Marine Electronics Association, but are
646 proprietary and expensive; the maintainers of gpsd have made a point of
647 not looking at them. The GPSD project website links to several
648 documents that collect publicly disclosed information about the
649 protocol.
650 gpsd parses the following NMEA sentences: RMC, GGA, GLL, GSA, GSV, VTG,
652 ZDA, GBS, HDT, DBT, GST. It recognizes these with either the normal GP
653 talker-ID prefix, or with the GN prefix used by GLONASS, or with the II
654 prefix emitted by Seahawk Autohelm marine navigation systems, or with
655 the IN prefix emitted by some Garmin units, or with the EC prefix
656 emitted by ECDIS units, or with the SD prefix emitted by depth
657 sounders, or with the HC and TI prefix emitted by some Airmar
658 equipment. It recognizes some vendor extensions: the PGRME emitted by
659 some Garmin GPS models, the OHPR emitted by Oceanserver digital
660 compasses, the PTNTHTM emitted by True North digital compasses, the
661 PMTK omitted by some San Jose Navigation GPSes, and the PASHR sentences
662 emitted by some Ashtech GPSes.
663 Note that gpsd JSON returns pure decimal degrees, not the hybrid
665 degree/minute format described in the NMEA standard.
666 Differential-GPS corrections are conveyed by the RTCM protocols. The
668 applicable standard for RTCM-104 V2 is RTCM Recommended Standards for
669 Differential GNSS (Global Navigation Satellite) Service RTCM Paper
670 136-2001/SC 104-STD. The applicable standard for RTCM-104 V3 is RTCM
671 Standard 10403.1 for Differential GNSS Services - Version 3 RTCM Paper
672 177-2006-SC104-STD. Ordering instructions for the RTCM standards are
673 accessible from the website of the Radio Technical Commission for
674 Maritime Services under "Publications".
675 AIS is defined by ITU Recommendation M.1371, Technical Characteristics
677 for a Universal Shipborne Automatic Identification System Using Time
678 Division Multiple Access. The AIVDM/AIVDO format understood by this
679 program is defined by IEC-PAS 61162-100, Maritime navigation and
680 radiocommunication equipment and systems. A more accessible description
681 of both can be found at AIVDM/AIVDO Protocol Decoding, on the
682 references page of the GPSD project website.
683 Subframe data is defined by IS-GPS-200E, GLOBAL POSITIONING SYSTEM WING
685 (GPSW) SYSTEMS ENGINEERING & INTEGRATION, INTERFACE SPECIFICATION
686 IS-GPS-200 Revision E. The format understood by this program is defined
687 in Section 20 (Appendix II) of the IS-GPS-200E, GPS NAVIGATION DATA
688 STRUCTURE FOR DATA, D(t)
689 JSON is specified by RFC 7159, The JavaScript Object Notation (JSON)
691 Data Interchange Format.
692 The API for PPS time service is specified by RFC 2783, Pulse-Per-Second
694 API for UNIX-like Operating Systems, Version 1.0
695
697 gpsdctl(8), gps(1), libgps(3), gpsd_json(5), libgpsmm(3), gpsprof(1),
698 gpsfake(1), gpsctl(1), gpscat(1),
699
701 Authors: Eric S. Raymond, Chris Kuethe, Gary Miller. Former authors
702 whose bits have been plowed under by code turnover: Remco Treffcorn,
703 Derrick Brashear, Russ Nelson. This manual page by Eric S. Raymond
704 <esr@thyrsus.com>.
705The GPSD Project 6 December 2020 GPSD(8)