Devuan fork of gpsd
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

650 lines
32 KiB

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