Provided by: libgps-dev_3.9-3_amd64 
NAME
gpsd_json - gpsd request/response protol
OVERVIEW
gpsd is a service daemon that can be used to monitor GPSes, DGPS receivers, Marine AIS broadcasts, and
various other location-related and kinematic sensors.
Clients may communicate with gpsd via textual requests and responses over a socket. It is a bad idea for
applications to speak the protocol directly: rather, they should use the libgps client library (for C;
bindings also exist for other languages) and take appropriate care to conditionalize their code on the
major and minor protocol version symbols.
The GPSD protocol is built on top of JSON, JavaScript Object Notation. GPSD's use of JSON is restricted
in some ways that make parsing it in fixed-extent languages (such as C) easier.
A request line is introduced by "?" and may include multiple commands. Commands begin with a command
identifier, followed either by a terminating ';' or by an equal sign "=" and a JSON object treated as an
argument. Any ';' or newline indication (either LF or CR-LF) after the end of a command is ignored. All
request lines must be composed of US-ASCII characters and may be no more than 80 characters in length,
exclusive of the trailing newline.
Responses are JSON objects all of which have a "class" attribute the value of which is either the name of
the invoking command. There are reports (including but not limited to as "TPV", "SKY", "DEVICE", and
"ERROR") which are not direct responses to commands.
The order of JSON attributes within a response object is never significant, and you may specify
attributes in commands in any order. Responses never contain the special JSON value null; instead,
attributes with empty or undefined values are omitted. The length limit for responses and reports is 1536
characters, including trailing newline; longer responses will be truncated, so client code must be
prepared for the possibility of invalid JSON fragments.
In JSON reports, if an attribute is present only if the parent attribute is present or has a particular
range, then the parent attribute is emitted first.
There is one constraint on the order in which attributes will be omitted. If an optional attribute is
present only when a parent attribute has a specified value or range of values, the parent attribute will
be emitted first to make parsing easier.
The next subsection section documents the core GPSD protocol. Extensions are documented in the following
subsections. The extensions may not be supported in your gpsd instance if it has been compiled with a
restricted feature set.
CORE SOCKET PROTOCOL
Here are the core-protocol responses:
TPV
A TPV object is a time-position-velocity report. The "class" and "mode" fields will reliably be
present. The "mode" field will be emitted before optional fields that may be absent when there is no
fix. Error estimates will be emitted after the fix components they're associated with. Others may be
reported or not depending on the fix quality.
Table 1. TPV object
┌───────┬─────────┬─────────┬────────────────────────┐
│Name │ Always? │ Type │ Description │
├───────┼─────────┼─────────┼────────────────────────┤
│class │ Yes │ string │ Fixed: "TPV" │
├───────┼─────────┼─────────┼────────────────────────┤
│tag │ No │ string │ Type tag associated │
│ │ │ │ with this GPS │
│ │ │ │ sentence; from an NMEA │
│ │ │ │ device this is │
│ │ │ │ just the NMEA sentence │
│ │ │ │ type. │
├───────┼─────────┼─────────┼────────────────────────┤
│device │ No │ string │ Name of originating │
│ │ │ │ device. │
├───────┼─────────┼─────────┼────────────────────────┤
│mode │ Yes │ numeric │ NMEA mode: %d, 0=no │
│ │ │ │ mode value yet seen, │
│ │ │ │ 1=no fix, 2=2D, 3=3D. │
├───────┼─────────┼─────────┼────────────────────────┤
│time │ No │ string │ Time/date stamp in │
│ │ │ │ ISO8601 format, UTC. │
│ │ │ │ May have a │
│ │ │ │ fractional part │
│ │ │ │ of up to .001sec │
│ │ │ │ precision. May be │
│ │ │ │ absent if mode │
│ │ │ │ is not 2 or 3. │
├───────┼─────────┼─────────┼────────────────────────┤
│ept │ No │ numeric │ Estimated timestamp │
│ │ │ │ error (%f, seconds, │
│ │ │ │ 95% confidence). │
│ │ │ │ Present if │
│ │ │ │ time is present. │
├───────┼─────────┼─────────┼────────────────────────┤
│lat │ No │ numeric │ Latitude in degrees: │
│ │ │ │ +/- signifies │
│ │ │ │ West/East. Present │
│ │ │ │ when mode is 2 │
│ │ │ │ or 3. │
├───────┼─────────┼─────────┼────────────────────────┤
│lon │ No │ numeric │ Longitude in degrees: │
│ │ │ │ +/- signifies │
│ │ │ │ North/South. Present │
│ │ │ │ when mode is 2 │
│ │ │ │ or 3. │
├───────┼─────────┼─────────┼────────────────────────┤
│alt │ No │ numeric │ Altitude in meters. │
│ │ │ │ Present if mode is 3. │
├───────┼─────────┼─────────┼────────────────────────┤
│epx │ No │ numeric │ Longitude error │
│ │ │ │ estimate in meters, │
│ │ │ │ 95% confidence. │
│ │ │ │ Present │
│ │ │ │ if mode is 2 │
│ │ │ │ or 3 and DOPs can be │
│ │ │ │ calculated from the │
│ │ │ │ satellite │
│ │ │ │ view. │
├───────┼─────────┼─────────┼────────────────────────┤
│epy │ No │ numeric │ Latitude error │
│ │ │ │ estimate in meters, │
│ │ │ │ 95% confidence. │
│ │ │ │ Present │
│ │ │ │ if mode is 2 │
│ │ │ │ or 3 and DOPs can be │
│ │ │ │ calculated from the │
│ │ │ │ satellite │
│ │ │ │ view. │
├───────┼─────────┼─────────┼────────────────────────┤
│epv │ No │ numeric │ Estimated vertical │
│ │ │ │ error in meters, 95% │
│ │ │ │ confidence. Present │
│ │ │ │ if mode is 3 │
│ │ │ │ and DOPs can be │
│ │ │ │ calculated from the │
│ │ │ │ satellite │
│ │ │ │ view. │
├───────┼─────────┼─────────┼────────────────────────┤
│track │ No │ numeric │ Course over ground, │
│ │ │ │ degrees from true │
│ │ │ │ north. │
├───────┼─────────┼─────────┼────────────────────────┤
│speed │ No │ numeric │ Speed over ground, │
│ │ │ │ meters per second. │
├───────┼─────────┼─────────┼────────────────────────┤
│climb │ No │ numeric │ Climb (positive) or │
│ │ │ │ sink (negative) rate, │
│ │ │ │ meters per │
│ │ │ │ second. │
├───────┼─────────┼─────────┼────────────────────────┤
│epd │ No │ numeric │ Direction error │
│ │ │ │ estimate in degrees, │
│ │ │ │ 95% confidence. │
├───────┼─────────┼─────────┼────────────────────────┤
│eps │ No │ numeric │ Speed error estinmate │
│ │ │ │ in meters/sec, 95% │
│ │ │ │ confidence. │
├───────┼─────────┼─────────┼────────────────────────┤
│epc │ No │ numeric │ Climb/sink error │
│ │ │ │ estimate in │
│ │ │ │ meters/sec, 95% │
│ │ │ │ confidence. │
└───────┴─────────┴─────────┴────────────────────────┘
When the C client library parses a response of this kind, it will assert validity bits in the
top-level set member for each field actually received; see gps.h for bitmask names and values.
Here's an example:
{"class":"TPV","tag":"MID2","device":"/dev/pts/1",
"time":"2005-06-08T10:34:48.283Z","ept":0.005,
"lat":46.498293369,"lon":7.567411672,"alt":1343.127,
"eph":36.000,"epv":32.321,
"track":10.3788,"speed":0.091,"climb":-0.085,"mode":3}
SKY
A SKY object reports a sky view of the GPS satellite positions. If there is no GPS device available,
or no skyview has been reported yet, only the "class" field will reliably be present.
Table 2. SKY object
┌───────────┬─────────┬─────────┬────────────────────────┐
│Name │ Always? │ Type │ Description │
├───────────┼─────────┼─────────┼────────────────────────┤
│class │ Yes │ string │ Fixed: "SKY" │
├───────────┼─────────┼─────────┼────────────────────────┤
│tag │ No │ string │ Type tag associated │
│ │ │ │ with this GPS │
│ │ │ │ sentence; from an NMEA │
│ │ │ │ device this is │
│ │ │ │ just the NMEA sentence │
│ │ │ │ type. │
├───────────┼─────────┼─────────┼────────────────────────┤
│device │ No │ string │ Name of originating │
│ │ │ │ device │
├───────────┼─────────┼─────────┼────────────────────────┤
│time │ No │ numeric │ Time/date stamp in │
│ │ │ │ ISO8601 format, UTC. │
│ │ │ │ May have a │
│ │ │ │ fractional part │
│ │ │ │ of up to .001sec │
│ │ │ │ precision. │
├───────────┼─────────┼─────────┼────────────────────────┤
│xdop │ No │ numeric │ Longitudinal dilution │
│ │ │ │ of precision, a │
│ │ │ │ dimensionless │
│ │ │ │ factor which │
│ │ │ │ should be multiplied │
│ │ │ │ by a base UERE to get │
│ │ │ │ an error │
│ │ │ │ estimate. │
├───────────┼─────────┼─────────┼────────────────────────┤
│ydop │ No │ numeric │ Latitudinal dilution │
│ │ │ │ of precision, a │
│ │ │ │ dimensionless │
│ │ │ │ factor which │
│ │ │ │ should be multiplied │
│ │ │ │ by a base UERE to get │
│ │ │ │ an error │
│ │ │ │ estimate. │
├───────────┼─────────┼─────────┼────────────────────────┤
│vdop │ No │ numeric │ Altitude dilution of │
│ │ │ │ precision, a │
│ │ │ │ dimensionless │
│ │ │ │ factor which │
│ │ │ │ should be multiplied │
│ │ │ │ by a base UERE to get │
│ │ │ │ an error │
│ │ │ │ estimate. │
├───────────┼─────────┼─────────┼────────────────────────┤
│tdop │ No │ numeric │ Time dilution of │
│ │ │ │ precision, a │
│ │ │ │ dimensionless │
│ │ │ │ factor which │
│ │ │ │ should be multiplied │
│ │ │ │ by a base UERE to get │
│ │ │ │ an error │
│ │ │ │ estimate. │
├───────────┼─────────┼─────────┼────────────────────────┤
│hdop │ No │ numeric │ Horizontal dilution of │
│ │ │ │ precision, a │
│ │ │ │ dimensionless │
│ │ │ │ factor which │
│ │ │ │ should be multiplied │
│ │ │ │ by a base UERE to get │
│ │ │ │ a circular error │
│ │ │ │ estimate. │
├───────────┼─────────┼─────────┼────────────────────────┤
│pdop │ No │ numeric │ Spherical dilution of │
│ │ │ │ precision, a │
│ │ │ │ dimensionless │
│ │ │ │ factor which │
│ │ │ │ should be multiplied │
│ │ │ │ by a base UERE to get │
│ │ │ │ an error │
│ │ │ │ estimate. │
├───────────┼─────────┼─────────┼────────────────────────┤
│gdop │ No │ numeric │ Hyperspherical │
│ │ │ │ dilution of precision, │
│ │ │ │ a dimensionless │
│ │ │ │ factor which │
│ │ │ │ should be multiplied │
│ │ │ │ by a base UERE to get │
│ │ │ │ an error │
│ │ │ │ estimate. │
├───────────┼─────────┼─────────┼────────────────────────┤
│satellites │ Yes │ list │ List of satellite │
│ │ │ │ objects in skyview │
└───────────┴─────────┴─────────┴────────────────────────┘
Many devices compute dilution of precision factors but do not include them in their reports. Many
that do report DOPs report only HDOP, two-dimensional circular error. gpsd always passes through
whatever the device actually reports, then attempts to fill in other DOPs by calculating the
appropriate determinants in a covariance matrix based on the satellite view. DOPs may be missing if
some of these determinants are singular. It can even happen that the device reports an error estimate
in meters when the corresponding DOP is unavailable; some devices use more sophisticated error
modeling than the covariance calculation.
The satellite list objects have the following elements:
Table 3. Satellite object
┌─────┬─────────┬─────────┬────────────────────────┐
│Name │ Always? │ Type │ Description │
├─────┼─────────┼─────────┼────────────────────────┤
│PRN │ Yes │ numeric │ PRN ID of the │
│ │ │ │ satellite. 1-63 are │
│ │ │ │ GNSS satellites, │
│ │ │ │ 64-96 are GLONASS │
│ │ │ │ satellites, 100-164 │
│ │ │ │ are SBAS satellites │
├─────┼─────────┼─────────┼────────────────────────┤
│az │ Yes │ numeric │ Azimuth, degrees from │
│ │ │ │ true north. │
├─────┼─────────┼─────────┼────────────────────────┤
│el │ Yes │ numeric │ Elevation in degrees. │
├─────┼─────────┼─────────┼────────────────────────┤
│ss │ Yes │ numeric │ Signal strength in dB. │
├─────┼─────────┼─────────┼────────────────────────┤
│used │ Yes │ boolean │ Used in current │
│ │ │ │ solution? │
│ │ │ │ (SBAS/WAAS/EGNOS │
│ │ │ │ satellites may be │
│ │ │ │ flagged used if the │
│ │ │ │ solution has │
│ │ │ │ corrections from them, │
│ │ │ │ but not all │
│ │ │ │ drivers make this │
│ │ │ │ information │
│ │ │ │ available.) │
└─────┴─────────┴─────────┴────────────────────────┘
Note that satellite objects do not have a "class" field, as they are never shipped outside of a SKY
object.
When the C client library parses a SKY response, it will assert the SATELLITE_SET bit in the
top-level set member.
Here's an example:
{"class":"SKY","tag":"MID2","device":"/dev/pts/1",
"time":"2005-07-08T11:28:07.114Z",
"xdop":1.55,"hdop":1.24,"pdop":1.99,
"satellites":[
{"PRN":23,"el":6,"az":84,"ss":0,"used":false},
{"PRN":28,"el":7,"az":160,"ss":0,"used":false},
{"PRN":8,"el":66,"az":189,"ss":44,"used":true},
{"PRN":29,"el":13,"az":273,"ss":0,"used":false},
{"PRN":10,"el":51,"az":304,"ss":29,"used":true},
{"PRN":4,"el":15,"az":199,"ss":36,"used":true},
{"PRN":2,"el":34,"az":241,"ss":43,"used":true},
{"PRN":27,"el":71,"az":76,"ss":43,"used":true}]}
GST
A GST object is a pseudorange noise report.
Table 4. GST object
┌───────┬─────────┬─────────┬────────────────────────┐
│Name │ Always? │ Type │ Description │
├───────┼─────────┼─────────┼────────────────────────┤
│class │ Yes │ string │ Fixed: "GST" │
├───────┼─────────┼─────────┼────────────────────────┤
│tag │ No │ string │ Type tag associated │
│ │ │ │ with this GPS │
│ │ │ │ sentence; from an NMEA │
│ │ │ │ device this is just │
│ │ │ │ the NMEA sentence │
│ │ │ │ type. │
├───────┼─────────┼─────────┼────────────────────────┤
│device │ No │ string │ Name of originating │
│ │ │ │ device │
├───────┼─────────┼─────────┼────────────────────────┤
│time │ No │ numeric │ Seconds since the Unix │
│ │ │ │ epoch, UTC. May have a │
│ │ │ │ fractional part of up │
│ │ │ │ to .001sec precision. │
├───────┼─────────┼─────────┼────────────────────────┤
│rms │ No │ numeric │ Value of the standard │
│ │ │ │ deviation of the range │
│ │ │ │ inputs to the │
│ │ │ │ navigation process │
│ │ │ │ (range inputs include │
│ │ │ │ pseudoranges and DGPS │
│ │ │ │ corrections). │
├───────┼─────────┼─────────┼────────────────────────┤
│major │ No │ numeric │ Standard deviation of │
│ │ │ │ semi-major axis of │
│ │ │ │ error ellipse, in │
│ │ │ │ meters. │
├───────┼─────────┼─────────┼────────────────────────┤
│minor │ No │ numeric │ Standard deviation of │
│ │ │ │ semi-minor axis of │
│ │ │ │ error ellipse, in │
│ │ │ │ meters. │
├───────┼─────────┼─────────┼────────────────────────┤
│orient │ No │ numeric │ Orientation of │
│ │ │ │ semi-major axis of │
│ │ │ │ error ellipse, in │
│ │ │ │ degrees from true │
│ │ │ │ north. │
├───────┼─────────┼─────────┼────────────────────────┤
│lat │ No │ numeric │ Standard deviation of │
│ │ │ │ latitude error, in │
│ │ │ │ meters. │
├───────┼─────────┼─────────┼────────────────────────┤
│lon │ No │ numeric │ Standard deviation of │
│ │ │ │ longitude error, in │
│ │ │ │ meters. │
├───────┼─────────┼─────────┼────────────────────────┤
│alt │ No │ numeric │ Standard deviation of │
│ │ │ │ altitude error, in │
│ │ │ │ meters. │
└───────┴─────────┴─────────┴────────────────────────┘
Here's an example:
{"class":"GST","tag":"GST","device":"/dev/ttyUSB0",
"time":"2010-12-07T10:23:07.096Z","rms":2.440,
"major":1.660,"minor":1.120,"orient":68.989,
"lat":1.600,"lon":1.200,"alt":2.520}
ATT
An ATT object is a vehicle-attitude report. It is returned by digital-compass and gyroscope sensors;
depending on device, it may include: heading, pitch, roll, yaw, gyroscope, and magnetic-field
readings. Because such sensors are often bundled as part of marine-navigation systems, the ATT
response may also include water depth.
The "class", "mode", and "tag" fields will reliably be present. Others may be reported or not
depending on the specific device type.
Table 5. ATT object
┌────────────┬─────────┬─────────┬────────────────────────┐
│Name │ Always? │ Type │ Description │
├────────────┼─────────┼─────────┼────────────────────────┤
│class │ Yes │ string │ Fixed: "ATT" │
├────────────┼─────────┼─────────┼────────────────────────┤
│tag │ Yes │ string │ Type tag associated │
│ │ │ │ with this GPS │
│ │ │ │ sentence; from an NMEA │
│ │ │ │ device this is │
│ │ │ │ just the NMEA sentence │
│ │ │ │ type. │
├────────────┼─────────┼─────────┼────────────────────────┤
│device │ Yes │ string │ Name of originating │
│ │ │ │ device │
├────────────┼─────────┼─────────┼────────────────────────┤
│time │ Yes │ numeric │ Seconds since the Unix │
│ │ │ │ epoch, UTC. May have a │
│ │ │ │ fractional part │
│ │ │ │ of up to .001sec │
│ │ │ │ precision. │
├────────────┼─────────┼─────────┼────────────────────────┤
│heading │ No │ numeric │ Heading, degrees from │
│ │ │ │ true north. │
├────────────┼─────────┼─────────┼────────────────────────┤
│mag_st │ No │ string │ Magnetometer status. │
├────────────┼─────────┼─────────┼────────────────────────┤
│pitch │ No │ numeric │ Pitch in degrees. │
├────────────┼─────────┼─────────┼────────────────────────┤
│pitch_st │ No │ string │ Pitch sensor status. │
├────────────┼─────────┼─────────┼────────────────────────┤
│yaw │ No │ numeric │ Yaw in degrees │
├────────────┼─────────┼─────────┼────────────────────────┤
│yaw_st │ No │ string │ Yaw sensor status. │
├────────────┼─────────┼─────────┼────────────────────────┤
│roll │ No │ numeric │ Roll in degrees. │
├────────────┼─────────┼─────────┼────────────────────────┤
│roll_st │ No │ string │ Roll sensor status. │
├────────────┼─────────┼─────────┼────────────────────────┤
│dip │ No │ numeric │ Local magnetic │
│ │ │ │ inclination, degrees, │
│ │ │ │ positive when the │
│ │ │ │ magnetic field points │
│ │ │ │ downward (into the │
│ │ │ │ Earth). │
├────────────┼─────────┼─────────┼────────────────────────┤
│mag_len │ No │ numeric │ Scalar magnetic field │
│ │ │ │ strength. │
├────────────┼─────────┼─────────┼────────────────────────┤
│mag_x │ No │ numeric │ X component of │
│ │ │ │ magnetic field │
│ │ │ │ strength. │
├────────────┼─────────┼─────────┼────────────────────────┤
│mag_y │ No │ numeric │ Y component of │
│ │ │ │ magnetic field │
│ │ │ │ strength. │
├────────────┼─────────┼─────────┼────────────────────────┤
│mag_z │ No │ numeric │ Z component of │
│ │ │ │ magnetic field │
│ │ │ │ strength. │
├────────────┼─────────┼─────────┼────────────────────────┤
│acc_len │ No │ numeric │ Scalar acceleration. │
├────────────┼─────────┼─────────┼────────────────────────┤
│acc_x │ No │ numeric │ X component of │
│ │ │ │ acceleration. │
├────────────┼─────────┼─────────┼────────────────────────┤
│acc_y │ No │ numeric │ Y component of │
│ │ │ │ acceleration. │
├────────────┼─────────┼─────────┼────────────────────────┤
│acc_z │ No │ numeric │ Z component of │
│ │ │ │ acceleration. │
├────────────┼─────────┼─────────┼────────────────────────┤
│gyro_x │ No │ numeric │ X component of │
│ │ │ │ acceleration. │
├────────────┼─────────┼─────────┼────────────────────────┤
│gyro_y │ No │ numeric │ Y component of │
│ │ │ │ acceleration. │
├────────────┼─────────┼─────────┼────────────────────────┤
│depth │ No │ numeric │ Water depth in meters. │
├────────────┼─────────┼─────────┼────────────────────────┤
│temperature │ No │ numeric │ Temperature at sensor, │
│ │ │ │ degrees centigrade. │
└────────────┴─────────┴─────────┴────────────────────────┘
The heading, pitch, and roll status codes (if present) vary by device. For the TNT Revolution digital
compasses, they are coded as follows:
Table 6. Device flags
┌─────┬──────────────────────────────────┐
│Code │ Description │
├─────┼──────────────────────────────────┤
│C │ magnetometer calibration alarm │
├─────┼──────────────────────────────────┤
│L │ low alarm │
├─────┼──────────────────────────────────┤
│M │ low warning │
├─────┼──────────────────────────────────┤
│N │ normal │
├─────┼──────────────────────────────────┤
│O │ high warning │
├─────┼──────────────────────────────────┤
│P │ high alarm │
├─────┼──────────────────────────────────┤
│V │ magnetometer voltage level alarm │
└─────┴──────────────────────────────────┘
When the C client library parses a response of this kind, it will assert ATT_IS.
Here's an example:
{"class":"ATT","tag":"PTNTHTM","time":1270938096.843,
"heading":14223.00,"mag_st":"N",
"pitch":169.00,"pitch_st":"N", "roll":-43.00,"roll_st":"N",
"dip":13641.000,"mag_x":2454.000}
And here are the commands:
?VERSION;
Returns an object with the following attributes:
Table 7. VERSION object
┌────────────┬─────────┬─────────┬────────────────────────┐
│Name │ Always? │ Type │ Description │
├────────────┼─────────┼─────────┼────────────────────────┤
│class │ Yes │ string │ Fixed: "VERSION" │
├────────────┼─────────┼─────────┼────────────────────────┤
│release │ Yes │ string │ Public release level │
├────────────┼─────────┼─────────┼────────────────────────┤
│rev │ Yes │ string │ Internal │
│ │ │ │ revision-control │
│ │ │ │ level. │
├────────────┼─────────┼─────────┼────────────────────────┤
│proto_major │ Yes │ numeric │ API major revision │
│ │ │ │ level. │
├────────────┼─────────┼─────────┼────────────────────────┤
│proto_minor │ Yes │ numeric │ API minor revision │
│ │ │ │ level. │
├────────────┼─────────┼─────────┼────────────────────────┤
│remote │ No │ string │ URL of the remote │
│ │ │ │ daemon reporting this │
│ │ │ │ version. If │
│ │ │ │ empty, this is │
│ │ │ │ the version of the │
│ │ │ │ local daemon. │
└────────────┴─────────┴─────────┴────────────────────────┘
The daemon ships a VERSION response to each client when the client first connects to it.
When the C client library parses a response of this kind, it will assert the VERSION_SET bit in the
top-level set member.
Here's an example:
{"class":"VERSION","version":"2.40dev",
"rev":"06f62e14eae9886cde907dae61c124c53eb1101f",
"proto_major":3,"proto_minor":1
}
?DEVICES;
Returns a device list object with the following elements:
Table 8. DEVICES object
┌────────┬─────────┬────────┬────────────────────────┐
│Name │ Always? │ Type │ Description │
├────────┼─────────┼────────┼────────────────────────┤
│class │ Yes │ string │ Fixed: "DEVICES" │
├────────┼─────────┼────────┼────────────────────────┤
│devices │ Yes │ list │ List of device │
│ │ │ │ descriptions │
├────────┼─────────┼────────┼────────────────────────┤
│remote │ No │ string │ URL of the remote │
│ │ │ │ daemon reporting the │
│ │ │ │ device set. If │
│ │ │ │ empty, this is │
│ │ │ │ a DEVICES response │
│ │ │ │ from the local daemon. │
└────────┴─────────┴────────┴────────────────────────┘
When the C client library parses a response of this kind, it will assert the DEVICELIST_SET bit in
the top-level set member.
Here's an example:
{"class"="DEVICES","devices":[
{"class":"DEVICE","path":"/dev/pts/1","flags":1,"driver":"SiRF binary"},
{"class":"DEVICE","path":"/dev/pts/3","flags":4,"driver":"AIVDM"}]}
The daemon occasionally ships a bare DEVICE object to the client (that is, one not inside a DEVICES
wrapper). The data content of these objects will be described later as a response to the ?DEVICE
command.
?WATCH;
This command sets watcher mode. It also sets or elicits a report of per-subscriber policy and the raw
bit. An argument WATCH object changes the subscriber's policy. The response describes the
subscriber's policy. The response will also include a DEVICES object.
A WATCH object has the following elements:
Table 9. WATCH object
┌───────┬─────────┬─────────┬────────────────────────┐
│Name │ Always? │ Type │ Description │
├───────┼─────────┼─────────┼────────────────────────┤
│class │ Yes │ string │ Fixed: "WATCH" │
├───────┼─────────┼─────────┼────────────────────────┤
│enable │ No │ boolean │ Enable (true) or │
│ │ │ │ disable (false) │
│ │ │ │ watcher mode. Default │
│ │ │ │ is true. │
├───────┼─────────┼─────────┼────────────────────────┤
│json │ No │ boolean │ Enable (true) or │
│ │ │ │ disable (false) │
│ │ │ │ dumping of JSON │
│ │ │ │ reports. Default │
│ │ │ │ is false. │
├───────┼─────────┼─────────┼────────────────────────┤
│nmea │ No │ boolean │ Enable (true) or │
│ │ │ │ disable (false) │
│ │ │ │ dumping of binary │
│ │ │ │ packets as │
│ │ │ │ pseudo-NMEA. Default │
│ │ │ │ is false. │
├───────┼─────────┼─────────┼────────────────────────┤
│raw │ No │ integer │ Controls 'raw' mode. │
│ │ │ │ When this attribute is │
│ │ │ │ set to 1 for a │
│ │ │ │ channel, gpsd reports │
│ │ │ │ the unprocessed │
│ │ │ │ NMEA or AIVDM data │
│ │ │ │ stream from whatever │
│ │ │ │ device is attached. │
│ │ │ │ Binary GPS │
│ │ │ │ packets are │
│ │ │ │ hex-dumped. RTCM2 and │
│ │ │ │ RTCM3 │
│ │ │ │ packets are │
│ │ │ │ not dumped in raw │
│ │ │ │ mode. When this │
│ │ │ │ attribute is set to │
│ │ │ │ 2 for a channel │
│ │ │ │ that processes binary │
│ │ │ │ data, gpsd │
│ │ │ │ reports the received │
│ │ │ │ data verbatim │
│ │ │ │ without │
│ │ │ │ hex-dumping. │
├───────┼─────────┼─────────┼────────────────────────┤
│scaled │ No │ boolean │ If true, apply scaling │
│ │ │ │ divisors to output │
│ │ │ │ before dumping; │
│ │ │ │ default is false. │
│ │ │ │ Applies only to AIS │
│ │ │ │ and Subframe │
│ │ │ │ reports. │
├───────┼─────────┼─────────┼────────────────────────┤
│device │ No │ string │ If present, enable │
│ │ │ │ watching only of the │
│ │ │ │ specified device │
│ │ │ │ rather than all │
│ │ │ │ devices. Useful with │
│ │ │ │ raw and NMEA modes │
│ │ │ │ in which device │
│ │ │ │ responses aren't │
│ │ │ │ tagged. Has no effect │
│ │ │ │ when used with │
│ │ │ │ enable:false. │
├───────┼─────────┼─────────┼────────────────────────┤
│remote │ No │ string │ URL of the remote │
│ │ │ │ daemon reporting the │
│ │ │ │ watch set. If │
│ │ │ │ empty, this is │
│ │ │ │ a WATCH response from │
│ │ │ │ the local daemon. │
└───────┴─────────┴─────────┴────────────────────────┘
There is an additional boolean "timing" attribute which is undocumented because that portion of the
interface is considered unstable and for developer use only.
In watcher mode, GPS reports are dumped as TPV and SKY responses. AIS, Subframe and RTCM reporting is
described in the next section.
When the C client library parses a response of this kind, it will assert the POLICY_SET bit in the
top-level set member.
Here's an example:
{"class":"WATCH", "raw":1,"scaled":true}
?POLL;
The POLL command requests data from the last-seen fixes on all active GPS devices. Devices must
previously have been activated by ?WATCH to be pollable.
Polling can lead to possibly surprising results when it is used on a device such as an NMEA GPS for
which a complete fix has to be accumulated from several sentences. If you poll while those sentences
are being emitted, the response will contain the last complete fix data and may be as much as one
cycle time (typically 1 second) stale.
The POLL response will contain a timestamped list of TPV objects describing cached data, and a
timestamped list of SKY objects describing satellite configuration. If a device has not seen fixes,
it will be reported with a mode field of zero.
Table 10. POLL object
┌─────────┬─────────┬────────────┬───────────────────────┐
│Name │ Always? │ Type │ Description │
├─────────┼─────────┼────────────┼───────────────────────┤
│class │ Yes │ string │ Fixed: "POLL" │
├─────────┼─────────┼────────────┼───────────────────────┤
│time │ Yes │ Numeric │ Timestamp in ISO 8601 │
│ │ │ │ format. May have a │
│ │ │ │ fractional part │
│ │ │ │ of up to .001sec │
│ │ │ │ precision. │
├─────────┼─────────┼────────────┼───────────────────────┤
│active │ Yes │ Numeric │ Count of active │
│ │ │ │ devices. │
├─────────┼─────────┼────────────┼───────────────────────┤
│fixes │ Yes │ JSON array │ Comma-separated list │
│ │ │ │ of TPV objects. │
├─────────┼─────────┼────────────┼───────────────────────┤
│skyviews │ Yes │ JSON array │ Comma-separated list │
│ │ │ │ of SKY objects. │
└─────────┴─────────┴────────────┴───────────────────────┘
Here's an example of a POLL response:
{"class":"POLL","time":"2010-06-04T10:31:00.289Z","active":1,
"tpv":[{"class":"TPV","tag":"MID41","device":"/dev/ttyUSB0",
"time":"2010-09-08T13:33:06.095Z",
"ept":0.005,"lat":40.035093060,
"lon":-75.519748733,"track":99.4319,"speed":0.123,"mode":2}],
"sky":[{"class":"SKY","tag":"MID41","device":"/dev/ttyUSB0",
"time":1270517264.240,"hdop":9.20,
"satellites":[{"PRN":16,"el":55,"az":42,"ss":36,"used":true},
{"PRN":19,"el":25,"az":177,"ss":0,"used":false},
{"PRN":7,"el":13,"az":295,"ss":0,"used":false},
{"PRN":6,"el":56,"az":135,"ss":32,"used":true},
{"PRN":13,"el":47,"az":304,"ss":0,"used":false},
{"PRN":23,"el":66,"az":259,"ss":0,"used":false},
{"PRN":20,"el":7,"az":226,"ss":0,"used":false},
{"PRN":3,"el":52,"az":163,"ss":32,"used":true},
{"PRN":31,"el":16,"az":102,"ss":0,"used":false}
]}]}
Note
Client software should not assume the field inventory of the POLL response is fixed for all time.
As gpsd collects and caches more data from more sensor types, those data are likely to find their
way into this response.
PPS
This message is emitted each time the daemon sees a PPS (Pulse Per Second) strobe from a device.
A PPS object has the following elements:
Table 11. PPS object
┌────────────┬─────────┬─────────┬───────────────────────┐
│Name │ Always? │ Type │ Description │
├────────────┼─────────┼─────────┼───────────────────────┤
│class │ Yes │ string │ Fixed: "PPS" │
├────────────┼─────────┼─────────┼───────────────────────┤
│device │ Yes │ string │ Name of originating │
│ │ │ │ device │
├────────────┼─────────┼─────────┼───────────────────────┤
│real_sec │ Yes │ numeric │ seconds from the │
│ │ │ │ realtime clock │
├────────────┼─────────┼─────────┼───────────────────────┤
│real_musec │ Yes │ numeric │ microseconds from the │
│ │ │ │ realtime clock │
├────────────┼─────────┼─────────┼───────────────────────┤
│clock_sec │ Yes │ numeric │ seconds from the │
│ │ │ │ system clock │
├────────────┼─────────┼─────────┼───────────────────────┤
│clock_musec │ Yes │ numeric │ microseconds from the │
│ │ │ │ system clock │
└────────────┴─────────┴─────────┴───────────────────────┘
This message is emitted once per second to watchers of a device emitting PPS, and is intended to
report the drift between the start of the GPS second and seconds as reported by the system clock
(which may be NTP-corrected).
The message contains second/microsecond pairs for two clocks; the realtime clock without NTP
correction (the result of clock_gettime(CLOCK_REALTIME), but only to microsecond precision) and the
ordinary system clock (which may be NTP corrected).
There are various sources of error in the reported clock times. For PPS delivered via a real
serial-line strobe, serial-interrupt latency plus processing time to the timer call should be bounded
above by about 10 microseconds; USB-to-serial control-line emulation is known to add jitter of about
50 microseconds. (Both figures are for GPSD running in non-realtime mode on an x86 with a gigahertz
clock and are estimates based on measured latency in other applications)
Here's an example:
{"class":"PPS","device":"/dev/ttyUSB0",
"real_sec":1330212592, "real_musec":343182,
"clock_sec":1330212592,"clock_musec":343184}
?DEVICE
This command reports (when followed by ';') the state of a device, or sets (when followed by '=' and
a DEVICE object) device-specific control bits, notably the device's speed and serial mode and the
native-mode bit. The parameter-setting form will be rejected if more than one client is attached to
the channel.
Pay attention to the response, because it is possible for this command to fail if the GPS does not
support a speed-switching command or only supports some combinations of serial modes. In case of
failure, the daemon and GPS will continue to communicate at the old speed.
Use the parameter-setting form with caution. On USB and Bluetooth GPSes it is also possible for
serial mode setting to fail either because the serial adaptor chip does not support non-8N1 modes or
because the device firmware does not properly synchronize the serial adaptor chip with the UART on
the GPS chipset when the speed changes. These failures can hang your device, possibly requiring a GPS
power cycle or (in extreme cases) physically disconnecting the NVRAM backup battery.
A DEVICE object has the following elements:
Table 12. CONFIGCHAN object
┌──────────┬────────────────────────┬─────────┬────────────────────────┐
│Name │ Always? │ Type │ Description │
├──────────┼────────────────────────┼─────────┼────────────────────────┤
│class │ Yes │ string │ Fixed: "DEVICE" │
├──────────┼────────────────────────┼─────────┼────────────────────────┤
│path │ No │ string │ Name the device for │
│ │ │ │ which the control bits │
│ │ │ │ are being │
│ │ │ │ reported, or for which │
│ │ │ │ they are to be │
│ │ │ │ applied. This │
│ │ │ │ attribute may │
│ │ │ │ be omitted only when │
│ │ │ │ there is exactly one │
│ │ │ │ subscribed │
│ │ │ │ channel. │
├──────────┼────────────────────────┼─────────┼────────────────────────┤
│activated │ No │ string │ Time the device was │
│ │ │ │ activated as an │
│ │ │ │ ISO8601 │
│ │ │ │ timestamp. If │
│ │ │ │ the device is inactive │
│ │ │ │ this attribute is │
│ │ │ │ absent. │
├──────────┼────────────────────────┼─────────┼────────────────────────┤
│flags │ No │ integer │ Bit vector of property │
│ │ │ │ flags. Currently │
│ │ │ │ defined flags are: │
│ │ │ │ describe │
│ │ │ │ packet types seen so │
│ │ │ │ far (GPS, RTCM2, │
│ │ │ │ RTCM3, AIS). │
│ │ │ │ Won't be reported if │
│ │ │ │ empty, e.g. before │
│ │ │ │ gpsd has seen │
│ │ │ │ identifiable packets │
│ │ │ │ from the device. │
├──────────┼────────────────────────┼─────────┼────────────────────────┤
│driver │ No │ string │ GPSD's name for the │
│ │ │ │ device driver type. │
│ │ │ │ Won't be reported │
│ │ │ │ before gpsd has │
│ │ │ │ seen identifiable │
│ │ │ │ packets from the │
│ │ │ │ device. │
├──────────┼────────────────────────┼─────────┼────────────────────────┤
│subtype │ When the daemon sees a │ string │ Whatever version │
│ │ delayed response to a │ │ information the device │
│ │ probe for subtype │ │ returned. │
│ │ or firmware-version │ │ │
│ │ information. │ │ │
├──────────┼────────────────────────┼─────────┼────────────────────────┤
│bps │ No │ integer │ Device speed in bits │
│ │ │ │ per second. │
├──────────┼────────────────────────┼─────────┼────────────────────────┤
│parity │ Yes │ string │ N, O or E for no │
│ │ │ │ parity, odd, or even. │
├──────────┼────────────────────────┼─────────┼────────────────────────┤
│stopbits │ Yes │ string │ Stop bits (1 or 2). │
├──────────┼────────────────────────┼─────────┼────────────────────────┤
│native │ No │ integer │ 0 means NMEA mode and │
│ │ │ │ 1 means alternate │
│ │ │ │ mode (binary if it has │
│ │ │ │ one, for SiRF and │
│ │ │ │ Evermore chipsets │
│ │ │ │ in particular). │
│ │ │ │ Attempting to set this │
│ │ │ │ mode on a non-GPS │
│ │ │ │ device will yield │
│ │ │ │ an error. │
├──────────┼────────────────────────┼─────────┼────────────────────────┤
│cycle │ No │ real │ Device cycle time in │
│ │ │ │ seconds. │
├──────────┼────────────────────────┼─────────┼────────────────────────┤
│mincycle │ No │ real │ Device minimum cycle │
│ │ │ │ time in seconds. │
│ │ │ │ Reported from │
│ │ │ │ ?CONFIGDEV when │
│ │ │ │ (and only when) the │
│ │ │ │ rate is switchable. It │
│ │ │ │ is read-only and │
│ │ │ │ not settable. │
└──────────┴────────────────────────┴─────────┴────────────────────────┘
The serial parameters will be omitted in a response describing a TCP/IP source such as an Ntrip,
DGPSIP, or AIS feed.
The contents of the flags field should be interpreted as follows:
Table 13. Device flags
┌───────────┬───────┬─────────────────────────────┐
│C #define │ Value │ Description │
├───────────┼───────┼─────────────────────────────┤
│SEEN_GPS │ 0x01 │ GPS data has been seen on │
│ │ │ this device │
├───────────┼───────┼─────────────────────────────┤
│SEEN_RTCM2 │ 0x02 │ RTCM2 data has been seen on │
│ │ │ this device │
├───────────┼───────┼─────────────────────────────┤
│SEEN_RTCM3 │ 0x04 │ RTCM3 data has been seen on │
│ │ │ this device │
├───────────┼───────┼─────────────────────────────┤
│SEEN_AIS │ 0x08 │ AIS data has been seen on │
│ │ │ this device │
└───────────┴───────┴─────────────────────────────┘
When the C client library parses a response of this kind, it will assert the DEVICE_SET bit in the
top-level set member.
Here's an example:
{"class":"DEVICE","bps":4800,"parity":"N","stopbits":1,"native":0}
When a client is in watcher mode, the daemon will ship it DEVICE notifications when a device is added to
the pool or deactivated.
When the C client library parses a response of this kind, it will assert the DEVICE_SET bit in the
top-level set member.
Here's an example:
{"class":"DEVICE","path":"/dev/pts1","activated":0}
The daemon may ship an error object in response to a syntactically invalid command line or unknown
command. It has the following elements:
Table 14. ERROR notification object
┌────────┬─────────┬────────┬───────────────────────┐
│Name │ Always? │ Type │ Description │
├────────┼─────────┼────────┼───────────────────────┤
│class │ Yes │ string │ Fixed: "ERROR" │
├────────┼─────────┼────────┼───────────────────────┤
│message │ Yes │ string │ Textual error message │
└────────┴─────────┴────────┴───────────────────────┘
Here's an example:
{"class":"ERROR","message":"Unrecognized request '?FOO'"}
When the C client library parses a response of this kind, it will assert the ERR_SET bit in the top-level
set member.
RTCM2
RTCM-104 is a family of serial protocols used for broadcasting pseudorange corrections from
differential-GPS reference stations. Many GPS receivers can accept these corrections to improve their
reporting accuracy.
RTCM-104 comes in two major and incompatible flavors, 2.x and 3.x. Each major flavor has minor
(compatible) revisions.
The applicable standard for RTCM Version 2.x is RTCM Recommended Standards for Differential NAVSTAR GPS
Service RTCM Paper 194-93/SC 104-STD. For RTCM 3.1 it is RTCM Paper 177-2006-SC104-STD. Ordering
instructions for both standards are accessible from the website of the Radio Technical Commission for
Maritime Services[1] under "Publications".
RTCM WIRE TRANSMISSIONS
Differential-GPS correction stations consist of a GPS reference receiver coupled to a low frequency (LF)
transmitter. The GPS reference receiver is a survey-grade GPS that does GPS carrier tracking and can work
out its own position to a few millimeters. It generates range and range-rate corrections and encodes them
into RTCM104. It ships the RTCM104 to the LF transmitter over serial rs-232 signal at 100 baud or 200
baud depending on the requirements of the transmitter.
The LF transmitter broadcasts the approximately 300khz radio signal that differential-GPS radio receivers
pick up. Transmitters that are meant to have a higher range will need to transmit at the slower rate. The
higher the data rate the harder it will be for the remote radio receiver to receive with a good
signal-to-noise ration. (Higher data rate signals can't be averaged over as long a time frame, hence they
appear noisier.)
RTCM WIRE FORMATS
An RTCM 2.x message consists of a sequence of up to 33 30-bit words. The 24 most significant bits of each
word are data and the six least significant bits are parity. The parity algorithm used is the same
ISGPS-2000 as that used on GPS satellite downlinks. Each RTCM 2.x message consists of two header words
followed by zero or more data words, depending upon message type.
An RTCM 3.x message begins with a fixed leader byte 0xD3. That is followed by six bits of version
information and 10 bits of payload length information. Following that is the payload; following the
payload is a 3-byte checksum of the payload using the Qualcomm CRC-24Q algorithm.
RTCM2 JSON FORMAT
Each RTCM2 message is dumped as a single JSON object per message, with the message fields as attributes
of that object. Arrays of satellite, station, and constellation statistics become arrays of JSON
sub-objects. Each sentence will normally also have a "device" field containing the pathname of the
originating device.
All attributes other than the device field are mandatory. Header attributes are emitted before others.
Header portion
Table 15. SKY object
┌───────────────┬─────────┬──────────────────────────────┐
│Name │ Type │ │
│ │ │ Description │
├───────────────┼─────────┼──────────────────────────────┤
│class │ string │ │
│ │ │ Fixed: "RTCM2". │
├───────────────┼─────────┼──────────────────────────────┤
│type │ integer │ │
│ │ │ Message type │
│ │ │ (1-9). │
├───────────────┼─────────┼──────────────────────────────┤
│station_id │ integer │ │
│ │ │ The id of the GPS │
│ │ │ reference │
│ │ │ receiver. The LF │
│ │ │ transmitters also │
│ │ │ have (different) │
│ │ │ id numbers. │
├───────────────┼─────────┼──────────────────────────────┤
│zcount │ real │ │
│ │ │ The reference │
│ │ │ time of the │
│ │ │ corrections in │
│ │ │ the message in │
│ │ │ seconds within │
│ │ │ the current hour. │
│ │ │ Note that it is │
│ │ │ in GPS time, │
│ │ │ which is some │
│ │ │ seconds ahead of │
│ │ │ UTC (see the U.S. │
│ │ │ Naval │
│ │ │ Observatory's │
│ │ │ table of leap │
│ │ │ second │
│ │ │ corrections[2]). │
├───────────────┼─────────┼──────────────────────────────┤
│seqnum │ integer │ │
│ │ │ Sequence number. │
│ │ │ Only 3 bits wide, │
│ │ │ wraps after 7. │
├───────────────┼─────────┼──────────────────────────────┤
│length │ integer │ │
│ │ │ The number of │
│ │ │ words after the │
│ │ │ header that │
│ │ │ comprise the │
│ │ │ message. │
├───────────────┼─────────┼──────────────────────────────┤
│station_health │ integer │ │
│ │ │ Station │
│ │ │ transmission │
│ │ │ status. Indicates │
│ │ │ the health of the │
│ │ │ beacon as a │
│ │ │ reference source. │
│ │ │ Any nonzero value │
│ │ │ means the │
│ │ │ satellite is │
│ │ │ probably │
│ │ │ transmitting bad │
│ │ │ data and should │
│ │ │ not be used in a │
│ │ │ fix. 6 means the │
│ │ │ transmission is │
│ │ │ unmonitored. 7 │
│ │ │ means the station │
│ │ │ is not working │
│ │ │ properly. Other │
│ │ │ values are │
│ │ │ defined by the │
│ │ │ beacon operator. │
└───────────────┴─────────┴──────────────────────────────┘
<message type> is one of
1
full corrections - one message containing corrections for all GPS satellites in view. This is not
common.
3
reference station parameters - the position of the reference station GPS antenna.
4
datum — the datum to which the DGPS data is referred.
5
constellation health — information about the satellites the beacon can see.
6
null message — just a filler.
7
radio beacon almanac — information about this or other beacons.
9
subset corrections — a message containing corrections for only a subset of the GPS satellites in
view.
16
special message — a text message from the beacon operator.
31
GLONASS subset corrections — a message containing corrections for a set of the GLONASS satellites
in view.
Type 1 and 9: Correction data
One or more satellite objects follow the header for type 1 or type 9 messages. Here is the format:
Table 16. Satellite object
┌──────┬─────────┬──────────────────────────────┐
│Name │ Type │ │
│ │ │ Description │
├──────┼─────────┼──────────────────────────────┤
│ident │ integer │ │
│ │ │ The PRN number of │
│ │ │ the satellite for │
│ │ │ which this is │
│ │ │ correction data. │
├──────┼─────────┼──────────────────────────────┤
│udre │ integer │ │
│ │ │ User Differential │
│ │ │ Range Error │
│ │ │ (0-3). See the │
│ │ │ table following │
│ │ │ for values. │
├──────┼─────────┼──────────────────────────────┤
│iod │ integer │ │
│ │ │ Issue Of Data, │
│ │ │ matching the IOD │
│ │ │ for the current │
│ │ │ ephemeris of this │
│ │ │ satellite, as │
│ │ │ transmitted by │
│ │ │ the satellite. │
│ │ │ The IOD is a │
│ │ │ unique tag that │
│ │ │ identifies the │
│ │ │ ephemeris; the │
│ │ │ GPS using the │
│ │ │ DGPS correction │
│ │ │ and the DGPS │
│ │ │ generating the │
│ │ │ data must use the │
│ │ │ same orbital │
│ │ │ positions for the │
│ │ │ satellite. │
├──────┼─────────┼──────────────────────────────┤
│prc │ real │ │
│ │ │ The pseudorange │
│ │ │ error in meters │
│ │ │ for this │
│ │ │ satellite as │
│ │ │ measured by the │
│ │ │ beacon reference │
│ │ │ receiver at the │
│ │ │ epoch indicated │
│ │ │ by the z_count in │
│ │ │ the parent │
│ │ │ record. │
├──────┼─────────┼──────────────────────────────┤
│rrc │ real │ │
│ │ │ The rate of │
│ │ │ change of │
│ │ │ pseudorange error │
│ │ │ in meters/sec for │
│ │ │ this satellite as │
│ │ │ measured by the │
│ │ │ beacon reference │
│ │ │ receiver at the │
│ │ │ epoch indicated │
│ │ │ by the z_count │
│ │ │ field in the │
│ │ │ parent record. │
│ │ │ This is used to │
│ │ │ calculate │
│ │ │ pseudorange │
│ │ │ errors at other │
│ │ │ epochs, if │
│ │ │ required by the │
│ │ │ GPS receiver. │
└──────┴─────────┴──────────────────────────────┘
User Differential Range Error values are as follows:
Table 17. UDRE values
┌──┬──────────────────────┐
│0 │ 1-sigma error <= 1m │
├──┼──────────────────────┤
│1 │ 1-sigma error <= 4m │
├──┼──────────────────────┤
│2 │ 1-sigma error <= 8m │
├──┼──────────────────────┤
│3 │ 1-sigma error > 8m │
└──┴──────────────────────┘
Here's an example:
{"class":"RTCM2","type":1,
"station_id":688,"zcount":843.0,"seqnum":5,"length":19,"station_health":6,
"satellites":[
{"ident":10,"udre":0,"iod":46,"prc":-2.400,"rrc":0.000},
{"ident":13,"udre":0,"iod":94,"prc":-4.420,"rrc":0.000},
{"ident":7,"udre":0,"iod":22,"prc":-5.160,"rrc":0.002},
{"ident":2,"udre":0,"iod":34,"prc":-6.480,"rrc":0.000},
{"ident":4,"udre":0,"iod":47,"prc":-8.860,"rrc":0.000},
{"ident":8,"udre":0,"iod":76,"prc":-7.980,"rrc":0.002},
{"ident":5,"udre":0,"iod":99,"prc":-8.260,"rrc":0.002},
{"ident":23,"udre":0,"iod":81,"prc":-8.060,"rrc":0.000},
{"ident":16,"udre":0,"iod":70,"prc":-11.740,"rrc":0.000},
{"ident":30,"udre":0,"iod":4,"prc":-18.960,"rrc":-0.006},
{"ident":29,"udre":0,"iod":101,"prc":-24.960,"rrc":-0.002}
]}
Type 3: Reference Station Parameters
Here are the payload members of a type 3 (Reference Station Parameters) message:
Table 18. Reference Station Parameters
┌─────┬──────┬────────────────────────┐
│Name │ Type │ │
│ │ │ Description │
├─────┼──────┼────────────────────────┤
│x │ real │ │
│ │ │ ECEF X │
│ │ │ coordinate. │
├─────┼──────┼────────────────────────┤
│y │ real │ │
│ │ │ ECEF Y │
│ │ │ coordinate. │
├─────┼──────┼────────────────────────┤
│z │ real │ │
│ │ │ ECEF Z │
│ │ │ coordinate. │
└─────┴──────┴────────────────────────┘
The coordinates are the position of the station, in meters to two decimal places, in Earth Centred
Earth Fixed coordinates. These are usually referred to the WGS84 reference frame, but may be referred
to NAD83 in the US (essentially identical to WGS84 for all except geodesists), or to some other
reference frame in other parts of the world.
An invalid reference message is represented by a type 3 header without payload fields.
Here's an example:
{"class":"RTCM2","type":3,
"station_id":652,"zcount":1657.2,"seqnum":2,"length":4,"station_health":6,
"x":3878620.92,"y":670281.40,"z":5002093.59
}
Type 4: Datum
Here are the payload members of a type 4 (Datum) message:
Table 19. Datum
┌───────────┬─────────┬──────────────────────────────┐
│Name │ Type │ │
│ │ │ Description │
├───────────┼─────────┼──────────────────────────────┤
│dgnss_type │ string │ │
│ │ │ Either "GPS", │
│ │ │ "GLONASS", │
│ │ │ "GALILEO", or │
│ │ │ "UNKNOWN". │
├───────────┼─────────┼──────────────────────────────┤
│dat │ integer │ │
│ │ │ 0 or 1 and │
│ │ │ indicates the │
│ │ │ sense of the │
│ │ │ offset shift │
│ │ │ given by dx, dy, │
│ │ │ dz. dat = 0 means │
│ │ │ that the station │
│ │ │ coordinates (in │
│ │ │ the reference │
│ │ │ message) are │
│ │ │ referred to a │
│ │ │ local datum and │
│ │ │ that adding dx, │
│ │ │ dy, dz to that │
│ │ │ position will │
│ │ │ render it in GNSS │
│ │ │ coordinates │
│ │ │ (WGS84 for GPS). │
│ │ │ If dat = 1 then │
│ │ │ the ref station │
│ │ │ position is in │
│ │ │ GNSS coordinates │
│ │ │ and adding dx, │
│ │ │ dy, dz will give │
│ │ │ it referred to │
│ │ │ the local datum. │
├───────────┼─────────┼──────────────────────────────┤
│datum_name │ string │ │
│ │ │ A standard name │
│ │ │ for the datum. │
├───────────┼─────────┼──────────────────────────────┤
│dx │ real │ │
│ │ │ X offset. │
├───────────┼─────────┼──────────────────────────────┤
│dy │ real │ │
│ │ │ Y offset. │
├───────────┼─────────┼──────────────────────────────┤
│dz │ real │ │
│ │ │ Z offset. │
└───────────┴─────────┴──────────────────────────────┘
<dx> <dy> <dz> are offsets to convert from local datum to GNSS datum or vice versa. These fields are
optional.
An invalid datum message is represented by a type 4 header without payload fields.
Type 5: Constellation Health
One or more of these follow the header for type 5 messages — one for each satellite.
Here is the format:
Table 20. Constellation health
┌────────────┬─────────┬──────────────────────────────┐
│Name │ Type │ │
│ │ │ Description │
├────────────┼─────────┼──────────────────────────────┤
│ident │ integer │ │
│ │ │ The PRN number of │
│ │ │ the satellite. │
├────────────┼─────────┼──────────────────────────────┤
│iodl │ bool │ │
│ │ │ True indicates │
│ │ │ that this │
│ │ │ information │
│ │ │ relates to the │
│ │ │ satellite │
│ │ │ information in an │
│ │ │ accompanying type │
│ │ │ 1 or type 9 │
│ │ │ message. │
├────────────┼─────────┼──────────────────────────────┤
│health │ integer │ 0 indicates that the │
│ │ │ satellite is healthy. Any │
│ │ │ other value indicates a │
│ │ │ problem (coding is not │
│ │ │ known)..PP │
├────────────┼─────────┼──────────────────────────────┤
│snr │ integer │ │
│ │ │ The carrier/noise │
│ │ │ ratio of the │
│ │ │ received signal │
│ │ │ in the range 25 │
│ │ │ to 55 dB(Hz). │
├────────────┼─────────┼──────────────────────────────┤
│health_en │ bool │ │
│ │ │ If set to True it │
│ │ │ indicates that │
│ │ │ the satellite is │
│ │ │ healthy even if │
│ │ │ the satellite │
│ │ │ navigation data │
│ │ │ says it is │
│ │ │ unhealthy. │
├────────────┼─────────┼──────────────────────────────┤
│new_data │ bool │ True indicates that the IOD │
│ │ │ for this satellite will │
│ │ │ soon be updated in │
│ │ │ type 1 or 9 messages..PP │
├────────────┼─────────┼──────────────────────────────┤
│los_warning │ bool │ │
│ │ │ Line-of-sight │
│ │ │ warning. True │
│ │ │ indicates that │
│ │ │ the satellite │
│ │ │ will shortly go │
│ │ │ unhealthy. │
├────────────┼─────────┼──────────────────────────────┤
│tou │ integer │ │
│ │ │ Healthy time │
│ │ │ remaining in │
│ │ │ seconds. │
└────────────┴─────────┴──────────────────────────────┘
Type 6: Null
This just indicates a null message. There are no payload fields.
Unknown message
This format is used to dump message words in hexadecimal when the message type field doesn't match
any of the known ones.
Here is the format:
Table 21. Unknown Message
┌─────┬──────┬────────────────────────┐
│Name │ Type │ │
│ │ │ Description │
├─────┼──────┼────────────────────────┤
│data │ list │ │
│ │ │ A list of │
│ │ │ strings. │
└─────┴──────┴────────────────────────┘
Each string in the array is a hex literal representing 30 bits of information, after parity checks
and inversion. The high two bits should be ignored.
Type 7: Radio Beacon Almanac
Here is the format:
Table 22. Contellation health
┌───────────┬─────────┬──────────────────────────────┐
│Name │ Type │ │
│ │ │ Description │
├───────────┼─────────┼──────────────────────────────┤
│lat │ real │ │
│ │ │ Latitude in │
│ │ │ degrees, of the │
│ │ │ LF transmitter │
│ │ │ antenna for the │
│ │ │ station for which │
│ │ │ this is an │
│ │ │ almanac. North is │
│ │ │ positive. │
├───────────┼─────────┼──────────────────────────────┤
│lon │ real │ │
│ │ │ Longitude in │
│ │ │ degrees, of the │
│ │ │ LF transmitter │
│ │ │ antenna for the │
│ │ │ station for which │
│ │ │ this is an │
│ │ │ almanac. East is │
│ │ │ positive. │
├───────────┼─────────┼──────────────────────────────┤
│range │ integer │ Published range of the │
│ │ │ station in km..PP │
├───────────┼─────────┼──────────────────────────────┤
│frequency │ real │ │
│ │ │ Station broadcast │
│ │ │ frequency in kHz. │
├───────────┼─────────┼──────────────────────────────┤
│health │ integer │ │
│ │ │ <health> is the │
│ │ │ health of the │
│ │ │ station for which │
│ │ │ this is an │
│ │ │ almanac. If it is │
│ │ │ non-zero, the │
│ │ │ station is │
│ │ │ issuing suspect │
│ │ │ data and should │
│ │ │ not be used for │
│ │ │ fixes. The ITU │
│ │ │ and RTCM104 │
│ │ │ standards differ │
│ │ │ about the mode │
│ │ │ detailed │
│ │ │ interpretation of │
│ │ │ the <health> │
│ │ │ field and even │
│ │ │ about its bit │
│ │ │ width. │
├───────────┼─────────┼──────────────────────────────┤
│station_id │ integer │ │
│ │ │ The id of the │
│ │ │ transmitter. This │
│ │ │ is not the same │
│ │ │ as the reference │
│ │ │ id in the header, │
│ │ │ the latter being │
│ │ │ the id of the │
│ │ │ reference │
│ │ │ receiver. │
├───────────┼─────────┼──────────────────────────────┤
│bitrate │ integer │ │
│ │ │ The transmitted │
│ │ │ bitrate. │
└───────────┴─────────┴──────────────────────────────┘
Here's an example:
{"class":"RTCM2","type":9,"station_id":268,"zcount":252.6,
"seqnum":4,"length":5,"station_health":0,
"satellites":[
{"ident":13,"udre":0,"iod":3,"prc":-25.940,"rrc":0.066},
{"ident":2,"udre":0,"iod":73,"prc":0.920,"rrc":-0.080},
{"ident":8,"udre":0,"iod":22,"prc":23.820,"rrc":0.014}
]}
Type 13: GPS Time of Week
Here are the payload members of a type 13 (Groumf Tramitter Parameters) message:
Table 23. Grund Transmitter Parameters
┌──────────┬─────────┬──────────────────────────────┐
│Name │ Type │ │
│ │ │ Description │
├──────────┼─────────┼──────────────────────────────┤
│status │ bool │ │
│ │ │ If True, signals │
│ │ │ user to expect a │
│ │ │ type 16 │
│ │ │ explanatory │
│ │ │ message │
│ │ │ associated with │
│ │ │ this station. │
│ │ │ Probably │
│ │ │ indicates some │
│ │ │ sort of unusual │
│ │ │ event. │
├──────────┼─────────┼──────────────────────────────┤
│rangeflag │ bool │ │
│ │ │ If True, │
│ │ │ indicates that │
│ │ │ the estimated │
│ │ │ range is │
│ │ │ different from │
│ │ │ that found in the │
│ │ │ Type 7 message │
│ │ │ (which contains │
│ │ │ the beacon's │
│ │ │ listed range). │
│ │ │ Generally │
│ │ │ indicates a range │
│ │ │ reduction due to │
│ │ │ causes such as │
│ │ │ poor ionospheric │
│ │ │ conditions or │
│ │ │ reduced │
│ │ │ transmission │
│ │ │ power. │
├──────────┼─────────┼──────────────────────────────┤
│lat │ real │ │
│ │ │ Degrees latitude, │
│ │ │ signed. Positive │
│ │ │ is N, negative is │
│ │ │ S. │
├──────────┼─────────┼──────────────────────────────┤
│lon │ real │ │
│ │ │ Degrees │
│ │ │ longitude, │
│ │ │ signed. Positive │
│ │ │ is E, negative is │
│ │ │ W. │
├──────────┼─────────┼──────────────────────────────┤
│range │ integer │ │
│ │ │ Transmission │
│ │ │ range in km │
│ │ │ (1-1024). │
└──────────┴─────────┴──────────────────────────────┘
This message type replaces message type 3 (Reference Station Parameters) in RTCM 2.3.
Type 14: GPS Time of Week
Here are the payload members of a type 14 (GPS Time of Week) message:
Table 24. Reference Station Parameters
┌─────────┬─────────┬──────────────────────────────┐
│Name │ Type │ │
│ │ │ Description │
├─────────┼─────────┼──────────────────────────────┤
│week │ integer │ │
│ │ │ GPS week (0-123). │
├─────────┼─────────┼──────────────────────────────┤
│hour │ integer │ │
│ │ │ Hour of week │
│ │ │ (0-167). │
├─────────┼─────────┼──────────────────────────────┤
│leapsecs │ integer │ │
│ │ │ Leap Seconds │
│ │ │ (0-63). │
└─────────┴─────────┴──────────────────────────────┘
Here's an example:
{"class":"RTCM2","type":14,"station_id":652,"zcount":1657.2,
"seqnum":3,"length":1,"station_health":6,"week":601,"hour":109,
"leapsecs":15}
Type 16: Special Message
Table 25. Special Message
┌────────┬────────┬─────────────────────────────┐
│Name │ Type │ │
│ │ │ Description │
├────────┼────────┼─────────────────────────────┤
│message │ string │ │
│ │ │ A text message │
│ │ │ sent by the │
│ │ │ beacon operator. │
└────────┴────────┴─────────────────────────────┘
Type 31: Correction data
One or more GLONASS satellite objects follow the header for type 1 or type 9 messages. Here is the
format:
Table 26. Satellite object
┌───────┬──────────┬────────────────────────────────┐
│Name │ Type │ │
│ │ │ Description │
├───────┼──────────┼────────────────────────────────┤
│ident │ integer │ │
│ │ │ The PRN number of │
│ │ │ the satellite for │
│ │ │ which this is │
│ │ │ correction data. │
├───────┼──────────┼────────────────────────────────┤
│udre │ integer │ │
│ │ │ User Differential │
│ │ │ Range Error │
│ │ │ (0-3). See the │
│ │ │ table following │
│ │ │ for values. │
├───────┼──────────┼────────────────────────────────┤
│change │ boolean │ │
│ │ │ Change-of-ephemeris │
│ │ │ bit. │
├───────┼──────────┼────────────────────────────────┤
│tod │ uinteger │ │
│ │ │ Count of 30-second │
│ │ │ periods since the │
│ │ │ top of the hour. │
├───────┼──────────┼────────────────────────────────┤
│prc │ real │ │
│ │ │ The pseudorange │
│ │ │ error in meters for │
│ │ │ this satellite as │
│ │ │ measured by the │
│ │ │ beacon reference │
│ │ │ receiver at the │
│ │ │ epoch indicated by │
│ │ │ the z_count in the │
│ │ │ parent record. │
├───────┼──────────┼────────────────────────────────┤
│rrc │ real │ │
│ │ │ The rate of change │
│ │ │ of pseudorange │
│ │ │ error in meters/sec │
│ │ │ for this satellite │
│ │ │ as measured by the │
│ │ │ beacon reference │
│ │ │ receiver at the │
│ │ │ epoch indicated by │
│ │ │ the z_count field │
│ │ │ in the parent │
│ │ │ record. This is │
│ │ │ used to calculate │
│ │ │ pseudorange errors │
│ │ │ at other epochs, if │
│ │ │ required by the GPS │
│ │ │ receiver. │
└───────┴──────────┴────────────────────────────────┘
Here's an example:
{"class":"RTCM2","type":31,"station_id":652,"zcount":1642.2,
"seqnum":0,"length":14,"station_health":6,
"satellites":[
{"ident":5,"udre":0,"change":false,"tod":0,"prc":132.360,"rrc":0.000},
{"ident":15,"udre":0,"change":false,"tod":0,"prc":134.840,"rrc":0.002},
{"ident":14,"udre":0,"change":false,"tod":0,"prc":141.520,"rrc":0.000},
{"ident":6,"udre":0,"change":false,"tod":0,"prc":127.000,"rrc":0.000},
{"ident":21,"udre":0,"change":false,"tod":0,"prc":128.780,"rrc":0.000},
{"ident":22,"udre":0,"change":false,"tod":0,"prc":125.260,"rrc":0.002},
{"ident":20,"udre":0,"change":false,"tod":0,"prc":117.280,"rrc":-0.004},
{"ident":16,"udre":0,"change":false,"tod":17,"prc":113.460,"rrc":0.018}
]}
RTCM3 DUMP FORMAT
The support for RTCM104v3 dumping is incomplete and buggy. Do not attempt to use it for production!
Anyone interested in it should read the source code.
AIS DUMP FORMATS
AIS support is an extension. It may not be present if your instance of gpsd has been built with a
restricted feature set.
AIS packets are dumped as JSON objects with class "AIS". Each AIS report object contains a "type" field
giving the AIS message type and a "scaled" field telling whether the remainder of the fields are dumped
in scaled or unscaled form. (These will be emitted before any type-specific fields.) It will also contain
a "device" field naming the data source. Other fields have names and types as specified in the
AIVDM/AIVDO Protocol Decoding document on the GPSD project website; each message field table may be
directly interpreted as a specification for the members of the corresponding JSON object type.
By default, certain scaling and conversion operations are performed for JSON output. Latitudes and
longitudes are scaled to decimal degrees rather than the native AIS unit of 1/10000th of a minute of arc.
Ship (but not air) speeds are scaled to knots rather than tenth-of-knot units. Navigation status and
positioning-system type are dumped as text strings rather than AIS numeric codes. Rate of turn may appear
as "nan" if is unavailable, or as one of the strings "fastright" or "fastleft" if it is out of the AIS
encoding range; otherwise it is quadratically mapped back to the turn sensor number in degrees per
minute. Vessel draughts are converted to decimal meters rather than native AIS decimeters. Various other
scaling conversions are described in "AIVDM/AIVDO Protocol Decoding".
SUBFRAME DUMP FORMATS
Subframe support is always compiled into gpsd but many GPS do not output Subframe data or the gpsd driver
may not support Subframes.
Subframe packets are dumped as JSON objects with class "SUBFRAME". Each Subframe report object contains a
"frame" field giving the subframe number, a "tSV" field for the transmitting satellite number, a "TOW17"
field containing the 17 MSBs of the start of the next 12-second message and a "scaled" field telling
whether the remainder of the fields are dumped in scaled or unscaled form. It will also contain a
"device" field naming the data source. Each SUBFRAME object will have a sub-object specific to that
subframe page type. Those sub-object fields have names and types similar to those specified in the
IS-GPS-200E document; each message field table may be directly interpreted as a specification for the
members of the corresponding JSON object type.
SEE ALSO
gpsd(8), libgps(3),
AUTHOR
The protocol was designed and documented by Eric S. Raymond.
NOTES
1. Radio Technical Commission for Maritime Services
http://www.rtcm.org/
2. table of leap second corrections
ftp://maia.usno.navy.mil/ser7/tai-utc.dat