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

NAME

6       gpsd - interface daemon for GPS receivers
7

SYNOPSIS

9       gpsd [-b] [-D debuglevel] [-F control-socket] [-f framing] [-G] [-h]
10            [-l] [-n] [-N] [-P pidfile] [-r] [-S listener-port] [-s speed]
11            [-V] [[source-name]...]
12

QUICK START

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

DESCRIPTION

47       gpsd is a monitor daemon that collects information from GPSes,
48       differential-GPS radios, or AIS receivers attached to the host machine.
49       Each GPS, DGPS radio, or AIS receiver is expected to be
50       direct-connected to the host via a USB or RS232C serial device. The
51       serial device may be specified to gpsd at startup, or it may be set via
52       a command shipped down a local control socket (e.g. by a USB hotplug
53       script). Given a GPS device by either means, gpsd discovers the correct
54       port speed and protocol for it.
55
56       gpsd should be able to query any GPS that speaks either the standard
57       textual NMEA 0183 protocol, or the (differing) extended NMEA dialects
58       used by MKT-3301, iTrax, Motorola OnCore, Sony CXD2951, and
59       Ashtech/Thales devices. It can also interpret the binary protocols used
60       by EverMore, Garmin, Navcom, Rockwell/Zodiac, SiRF, Trimble, and u-blox
61       ANTARIS devices. Under Linux it can read NMEA2000 packets through the
62       kernel CAN socket. It can read heading and attitude information from
63       the Oceanserver 5000 or TNT Revolution digital compasses.
64
65       The GPS reporting formats supported by your instance of gpsd may differ
66       depending on how it was compiled; general-purpose versions support
67       many, but it can be built with protocol subsets down to a singleton for
68       use in constrained environments. For a list of the GPS protocols
69       supported by your instance, see the output of gpsd -l
70
71       gpsd effectively hides the differences among the GPS types it supports.
72       It also knows about and uses commands that tune these GPSes for lower
73       latency. By using gpsd as an intermediary, applications avoid
74       contention for serial devices.
75
76       gpsd can use differential-GPS corrections from a DGPS radio or over the
77       net, from a ground station running a DGPSIP server or a Ntrip
78       broadcaster that reports RTCM-104 data; this will shrink position
79       errors by roughly a factor of four. When gpsd opens a serial device
80       emitting RTCM-104, it automatically recognizes this and uses the device
81       as a correction source for all connected GPSes that accept RTCM
82       corrections (this is dependent on the type of the GPS; not all GPSes
83       have the firmware capability to accept RTCM correction packets). See
84       the section called “ACCURACY” and the section called “FILES” for
85       discussion.
86
87       Client applications will communicate with gpsd via a TCP/IP port, 2947
88       by default). Both IPv4 and IPv6 connections are supported and a client
89       may connect via either.
90
91       The program accepts the following options:
92
93       -b
94           Broken-device-safety mode, otherwise known as read-only mode. A few
95           bluetooth and USB receivers lock up or become totally inaccessible
96           when probed or reconfigured; see the hardware compatibility list on
97           the GPSD project website for details. This switch prevents gpsd
98           from writing to a receiver. This means that gpsd cannot configure
99           the receiver for optimal performance, but it also means that gpsd
100           cannot break the receiver. A better solution would be for Bluetooth
101           to not be so fragile. A platform independent method to identify
102           serial-over-Bluetooth devices would also be nice.
103
104       -D
105           Set debug level. At debug levels 2 and above, gpsd reports incoming
106           sentence and actions to standard error if gpsd is in the foreground
107           (-N) or to syslog if in the background.
108
109       -F
110           Create a control socket for device addition and removal commands.
111           You must specify a valid pathname on your local filesystem; this
112           will be created as a Unix-domain socket to which you can write
113           commands that edit the daemon's internal device list.
114
115       -f
116           Fix the framing to the GNSS device. The framing parameter is of the
117           form: [78][ENO][012]. Most GNSS are 8N1. Some Trimble default to
118           8O1. The default is to search for the correct framing.
119
120       -G
121           This flag causes gpsd to listen on all addresses (INADDR_ANY)
122           rather than just the loop back (INADDR_LOOPBACK) address. For the
123           sake of privacy and security, TPV information is now private to the
124           local machine until the user makes an effort to expose this to the
125           world.
126
127       -h
128           Display help message and terminate.
129
130       -l
131           List all drivers compiled into this gpsd instance. The letters to
132           the left of each driver name are the gpsd control commands
133           supported by that driver.
134
135       -n
136           Don't wait for a client to connect before polling whatever GPS is
137           associated with it. Some RS232 GPSes wait in a standby mode
138           (drawing less power) when the host machine is not asserting DTR,
139           and some cellphone and handheld embedded GPSes have similar
140           behaviors. Accordingly, waiting for a watch request to open the
141           device may save battery power. (This capability is rare in
142           consumer-grade devices). You should use this option if you plan to
143           use gpsd to provide reference clock information to ntpd through a
144           memory-shared segment.
145
146       -N
147           Don't daemonize; run in foreground. This switch is mainly useful
148           for debugging.
149
150       -r
151           Use GPS time even with no current fix. Some GPS's have battery
152           powered Real Time Clocks (RTC's) built in, making them a valid time
153           source even before a fix is acquired. This can be useful on a
154           Raspberry Pi, or other device that has no battery powered RTC, and
155           thus has no valid time at startup.
156
157       -P
158           Specify the name and path to record the daemon's process ID.
159
160       -S
161           Set TCP/IP port on which to listen for GPSD clients (default is
162           2947).
163
164       -s
165           Fix the speed to the GNSS device. The default is to autobaud.
166
167       -V
168           Dump version and exit.
169
170       Arguments are interpreted as the names of data sources. Normally, a
171       data source is the device pathname of a local device from which the
172       daemon may expect GPS data. But there are three other special source
173       types recognized, for a total of four:
174
175       Local serial or USB device
176           A normal Unix device name of a serial or USB device to which a
177           sensor is attached. Example: /dev/ttyUSB0.
178
179       Local PPS device
180           A normal Unix device name of a PPS device to which a PPS source is
181           attached. The device name must start with "/dev/pps" and a local
182           serial or USB GPS device must also be available. Example:
183           /dev/pps0.
184
185       TCP feed
186           A URI with the prefix "tcp://", followed by a hostname, a colon,
187           and a port number. The daemon will open a socket to the indicated
188           address and port and read data packets from it, which will be
189           interpreted as though they had been issued by a serial device.
190           Example: tcp://data.aishub.net:4006.
191
192       UDP feed
193           A URI with the prefix "udp://", followed by a hostname, a colon,
194           and a port number. The daemon will open a socket listening for UDP
195           datagrams arriving on the indicated address and port, which will be
196           interpreted as though they had been issued by a serial device.
197           Example: udp://127.0.0.1:5000.
198
199       Ntrip caster
200           A URI with the prefix "ntrip://" followed by the name of an Ntrip
201           caster (Ntrip is a protocol for broadcasting differential-GPS fixes
202           over the net). For Ntrip services that require authentication, a
203           prefix of the form "username:password@" can be added before the
204           name of the Ntrip broadcaster. For Ntrip service, you must specify
205           which stream to use; the stream is given in the form "/streamname".
206           An example DGPSIP URI could be "dgpsip://dgpsip.example.com" and a
207           Ntrip URI could be
208           "ntrip://foo:bar@ntrip.example.com:80/example-stream". Corrections
209           from the caster will be send to each attached GPS with the
210           capability to accept them.
211
212       DGPSIP server
213           A URI with the prefix "dgpsip://" followed by a hostname, a colon,
214           and an optional colon-separated port number (defaulting to 2101).
215           The daemon will handshake with the DGPSIP server and read RTCM2
216           correction data from it. Corrections from the server will be set to
217           each attached GPS with the capability to accept them. Example:
218           dgpsip://dgps.wsrcc.com:2101.
219
220       Remote gpsd feed
221           A URI with the prefix "gpsd://", followed by a hostname and
222           optionally a colon and a port number (if the port is absent the
223           default gpsd port will be used). The daemon will open a socket to
224           the indicated address and port and emulate a gpsd client,
225           collecting JSON reports from the remote gpsd instance that will be
226           passed to local clients.
227
228       NMEA2000 CAN data
229           A URI with the prefix "nmea2000://", followed by a CAN devicename.
230           Only Linux socket CAN interfaces are supported. The interface must
231           be configured to receive CAN messages before gpsd can be started.
232           If there is more then one unit on the CAN bus that provides GPS
233           data, gpsd chooses the unit from which a GPS message is first seen.
234           Example: nmea2000://can0.
235
236       (The "ais:://" source type supported in some older versions of the
237       daemon has been retired in favor of the more general "tcp://".)
238
239       Additionally, two serial device names have a side effect:
240
241       /dev/ttyAMA0
242           The UART device on a Raspberry Pi. Has the side effect of opening
243           /dev/pps0 for RFC2783 1PPS data.
244
245       /dev/gpsd0
246           Generic GPS device 0. Has the side effect of opening /dev/pps0 for
247           RFC2783 1PPS data.
248
249       Note, however, that if /dev/pps0 is the fake "ktimer" PPS, then
250       /dev/pps1 will be used instead.
251
252       Internally, the daemon maintains a device pool holding the pathnames of
253       devices and remote servers known to the daemon. Initially, this list is
254       the list of device-name arguments specified on the command line. That
255       list may be empty, in which case the daemon will have no devices on its
256       search list until they are added by a control-socket command (see the
257       section called “GPS DEVICE MANAGEMENT” for details on this). Daemon
258       startup will abort with an error if neither any devices nor a control
259       socket are specified.
260
261       When a device is activated (i.e. a client requests data from it), gpsd
262       attempts to execute a hook from /etc/gpsd/device-hook with first
263       command line argument set to the pathname of the device and the second
264       to ACTIVATE. On deactivation it does the same passing DEACTIVATE for
265       the second argument.
266
267       gpsd can export data to client applications in three ways: via a
268       sockets interface, via a shared-memory segment, and via D-Bus. The next
269       three major sections describe these interfaces.
270

THE SOCKET INTERFACE

272       Clients may communicate with the daemon via textual request and
273       responses over a socket. It is a bad idea for applications to speak the
274       protocol directly: rather, they should use the libgps client library
275       and take appropriate care to conditionalize their code on the major and
276       minor protocol version symbols.
277
278       The request-response protocol for the socket interface is fully
279       documented in gpsd_json(5).
280

SHARED-MEMORY AND DBUS INTERFACES

282       gpsd has two other (read-only) interfaces.
283
284       Whenever the daemon recognizes a packet from any attached device, it
285       writes the accumulated state from that device to a shared memory
286       segment. The C and C++ client libraries shipped with GPSD can read this
287       segment. Client methods, and various restrictions associated with the
288       read-only nature of this interface, are documented at libgps(3). The
289       shared-memory interface is intended primarily for embedded deployments
290       in which gpsd monitors a single device, and its principal advantage is
291       that a daemon instance configured with shared memory but without the
292       sockets interface loses a significant amount of runtime weight.
293
294       The daemon may be configured to emit a D-Bus signal each time an
295       attached device delivers a fix. The signal path is path /org/gpsd, the
296       signal interface is "org.gpsd", and the signal name is "fix". The
297       signal payload layout is as follows:
298
299       Table 1. Satellite object
300       ┌─────────────────┬────────────────────────────┐
301Type             │                            │
302       │                 │        Description         │
303       ├─────────────────┼────────────────────────────┤
304       │DBUS_TYPE_DOUBLE │                            │
305       │                 │        Time (seconds since │
306       │                 │        Unix epoch)         │
307       ├─────────────────┼────────────────────────────┤
308       │DBUS_TYPE_INT32  │                            │
309       │                 │        mode                │
310       ├─────────────────┼────────────────────────────┤
311       │DBUS_TYPE_DOUBLE │                            │
312       │                 │        Time uncertainty    │
313       │                 │        (seconds).          │
314       ├─────────────────┼────────────────────────────┤
315       │DBUS_TYPE_DOUBLE │                            │
316       │                 │        Latitude in         │
317       │                 │        degrees.            │
318       ├─────────────────┼────────────────────────────┤
319       │DBUS_TYPE_DOUBLE │                            │
320       │                 │        Longitude in        │
321       │                 │        degrees.            │
322       ├─────────────────┼────────────────────────────┤
323       │DBUS_TYPE_DOUBLE │                            │
324       │                 │        Horizontal          │
325       │                 │        uncertainty in      │
326       │                 │        meters, 95%         │
327       │                 │        confidence.         │
328       ├─────────────────┼────────────────────────────┤
329       │DBUS_TYPE_DOUBLE │                            │
330       │                 │        Altitude in meters. │
331       ├─────────────────┼────────────────────────────┤
332       │DBUS_TYPE_DOUBLE │                            │
333       │                 │        Altitude            │
334       │                 │        uncertainty in      │
335       │                 │        meters, 95%         │
336       │                 │        confidence.         │
337       ├─────────────────┼────────────────────────────┤
338       │DBUS_TYPE_DOUBLE │                            │
339       │                 │        Course in degrees   │
340       │                 │        from true north.    │
341       ├─────────────────┼────────────────────────────┤
342       │DBUS_TYPE_DOUBLE │                            │
343       │                 │        Course uncertainty  │
344       │                 │        in meters, 95%      │
345       │                 │        confidence.         │
346       ├─────────────────┼────────────────────────────┤
347       │DBUS_TYPE_DOUBLE │                            │
348       │                 │        Speed, meters per   │
349       │                 │        second.             │
350       ├─────────────────┼────────────────────────────┤
351       │DBUS_TYPE_DOUBLE │                            │
352       │                 │        Speed uncertainty   │
353       │                 │        in meters per       │
354       │                 │        second, 95%         │
355       │                 │        confidence.         │
356       ├─────────────────┼────────────────────────────┤
357       │DBUS_TYPE_DOUBLE │                            │
358       │                 │        Climb, meters per   │
359       │                 │        second.             │
360       ├─────────────────┼────────────────────────────┤
361       │DBUS_TYPE_DOUBLE │                            │
362       │                 │        Climb uncertainty   │
363       │                 │        in meters per       │
364       │                 │        second, 95%         │
365       │                 │        confidence.         │
366       ├─────────────────┼────────────────────────────┤
367       │DBUS_TYPE_STRING │                            │
368       │                 │        Device name         │
369       └─────────────────┴────────────────────────────┘
370

GPS DEVICE MANAGEMENT

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

ACCURACY

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

USE WITH NTP

497       gpsd can provide reference clock information to ntpd, to keep the
498       system clock synchronized to the time provided by the GPS receiver.
499
500       On Linux, gpsd includes support for interpreting the PPS pulses emitted
501       at the start of every clock second on the carrier-detect lines of some
502       serial GPSes; this pulse can be used to update NTP at much higher
503       accuracy than message time provides. You can determine whether your GPS
504       emits this pulse by running at -D 5 and watching for carrier-detect
505       state change messages in the logfile. In addition, if your kernel
506       provides the RFC 2783 kernel PPS API then gpsd will use that for extra
507       accuracy.
508
509       Detailed instructions for using GPSD to set up a high-quality time
510       service can be found among the documentation on the GPSD website.
511

USE WITH D-BUS

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

SECURITY AND PERMISSIONS ISSUES

519       gpsd, if given the -G flag, will listen for connections from any
520       reachable host, and then disclose the current position. Before using
521       the -G flag, consider whether you consider your computer's location to
522       be sensitive data to be kept private or something that you wish to
523       publish.
524
525       gpsd must start up as root in order to open the NTPD shared-memory
526       segment, open its logfile, and create its local control socket. Before
527       doing any processing of GPS data, it tries to drop root privileges by
528       setting its UID to "nobody" (or another configured userid) and its
529       group ID to the group of the initial GPS passed on the command line —
530       or, if that device doesn't exist, to the group of /dev/ttyS0.
531
532       Privilege-dropping is a hedge against the possibility that carefully
533       crafted data, either presented from a client socket or from a subverted
534       serial device posing as a GPS, could be used to induce misbehavior in
535       the internals of gpsd. It ensures that any such compromises cannot be
536       used for privilege elevation to root.
537
538       The assumption behind gpsd's particular behavior is that all the tty
539       devices to which a GPS might be connected are owned by the same
540       non-root group and allow group read/write, though the group may vary
541       because of distribution-specific or local administrative practice. If
542       this assumption is false, gpsd may not be able to open GPS devices in
543       order to read them (such failures will be logged).
544
545       In order to fend off inadvertent denial-of-service attacks by port
546       scanners (not to mention deliberate ones), gpsd will time out inactive
547       client connections. Before the client has issued a command that
548       requests a channel assignment, a short timeout (60 seconds) applies.
549       There is no timeout for clients in watcher or raw modes; rather, gpsd
550       drops these clients if they fail to read data long enough for the
551       outbound socket write buffer to fill. Clients with an assigned device
552       in polling mode are subject to a longer timeout (15 minutes).
553

LIMITATIONS

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

FILES

613       /dev/ttyS0
614           Prototype TTY device. After startup, gpsd sets its group ID to the
615           owning group of this device if no GPS device was specified on the
616           command line does not exist.
617
618       /etc/gpsd/device-hook
619           Optional file containing the device activation/deactivation script.
620           Note that while /etc/gpsd is the default system configuration
621           directory, it is possible to build the GPSD source code with
622           different assumptions. See above for further details on the
623           device-hook mechanism.
624

ENVIRONMENT VARIABLES

626       By setting the environment variable GPSD_SHM_KEY, you can control the
627       key value used to create the shared-memory segment used for
628       communication with the client library. This will be useful mainly when
629       isolating test instances of gpsd from production ones.
630

APPLICABLE STANDARDS

632       The official NMEA protocol standards for NMEA0183 and NMEA2000 are
633       available from the National Marine Electronics Association, but are
634       proprietary and expensive; the maintainers of gpsd have made a point of
635       not looking at them. The GPSD project website links to several
636       documents that collect publicly disclosed information about the
637       protocol.
638
639       gpsd parses the following NMEA sentences: RMC, GGA, GLL, GSA, GSV, VTG,
640       ZDA, GBS, HDT, DBT, GST. It recognizes these with either the normal GP
641       talker-ID prefix, or with the GN prefix used by GLONASS, or with the II
642       prefix emitted by Seahawk Autohelm marine navigation systems, or with
643       the IN prefix emitted by some Garmin units, or with the EC prefix
644       emitted by ECDIS units, or with the SD prefix emitted by depth
645       sounders, or with the HC and TI prefix emitted by some Airmar
646       equipment. It recognizes some vendor extensions: the PGRME emitted by
647       some Garmin GPS models, the OHPR emitted by Oceanserver digital
648       compasses, the PTNTHTM emitted by True North digital compasses, the
649       PMTK omitted by some San Jose Navigation GPSes, and the PASHR sentences
650       emitted by some Ashtech GPSes.
651
652       Note that gpsd JSON returns pure decimal degrees, not the hybrid
653       degree/minute format described in the NMEA standard.
654
655       Differential-GPS corrections are conveyed by the RTCM protocols. The
656       applicable standard for RTCM-104 V2 is RTCM Recommended Standards for
657       Differential GNSS (Global Navigation Satellite) Service RTCM Paper
658       136-2001/SC 104-STD. The applicable standard for RTCM-104 V3 is RTCM
659       Standard 10403.1 for Differential GNSS Services - Version 3 RTCM Paper
660       177-2006-SC104-STD. Ordering instructions for the RTCM standards are
661       accessible from the website of the Radio Technical Commission for
662       Maritime Services under "Publications".
663
664       AIS is defined by ITU Recommendation M.1371, Technical Characteristics
665       for a Universal Shipborne Automatic Identification System Using Time
666       Division Multiple Access. The AIVDM/AIVDO format understood by this
667       program is defined by IEC-PAS 61162-100, Maritime navigation and
668       radiocommunication equipment and systems. A more accessible description
669       of both can be found at AIVDM/AIVDO Protocol Decoding, on the
670       references page of the GPSD project website.
671
672       Subframe data is defined by IS-GPS-200E, GLOBAL POSITIONING SYSTEM WING
673       (GPSW) SYSTEMS ENGINEERING & INTEGRATION, INTERFACE SPECIFICATION
674       IS-GPS-200 Revision E. The format understood by this program is defined
675       in Section 20 (Appendix II) of the IS-GPS-200E, GPS NAVIGATION DATA
676       STRUCTURE FOR DATA, D(t)
677
678       JSON is specified by RFC 7159, The JavaScript Object Notation (JSON)
679       Data Interchange Format.
680
681       The API for PPS time service is specified by RFC 2783, Pulse-Per-Second
682       API for UNIX-like Operating Systems, Version 1.0
683

SEE ALSO

685       gpsdctl(8), gps(1), libgps(3), gpsd_json(5), libgpsmm(3), gpsprof(1),
686       gpsfake(1), gpsctl(1), gpscat(1),
687

AUTHORS

689       Authors: Eric S. Raymond, Chris Kuethe, Gary Miller. Former authors
690       whose bits have been plowed under by code turnover: Remco Treffcorn,
691       Derrick Brashear, Russ Nelson. This manual page by Eric S. Raymond
692       <esr@thyrsus.com>.
693
694
695
696The GPSD Project                  9 Aug 2004                           GPSD(8)
Impressum