GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  GPSD_JSON (5)

.ds Aq ’

NAME

gpsd_json - gpsd request/response protocol

CONTENTS

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. GPSDs 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 theyre 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"
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 North/South. Present when mode is 2 or 3.
lon No numeric Longitude in degrees     +/- signifies East/West. 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.

Heres an example:

{"class":"TPV","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"
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.

Heres an example:

{"class":"SKY","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"
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.

Heres an example:

{"class":"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" and "mode" 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"
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.

Heres an example:

{"class":"ATT","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.

Heres 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.

Heres 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 subscribers policy. The response describes the subscribers 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.
split24 No boolean If true, aggregate AIS type24 sentence parts. If false, report each part as a separate JSON object, leaving the client to match MMSIs and aggregate. Default is false. Applies only to AIS reports.
pps No boolean If true, emit the TOFF JSON message on each cycle and a         PPS JSON message when the device issues 1PPS. Default is false.
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 arent 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.

Heres 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.

Heres an example of a POLL response:

{"class":"POLL","time":"2010-06-04T10:31:00.289Z","active":1,
    "tpv":[{"class":"TPV","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","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.

TOFF

This message is emitted on each cycle and reports the offset between the hosts clock time and the GPS time at top of second (actually, when the first data for the reporting cycle is received).

A TOFF object has the following elements:

Table 11. TOFF object

Name Always? Type Description
class Yes string Fixed    "TOFF"
device Yes string Name of originating device
real_sec Yes numeric seconds from the GPS clock
real_nsec Yes numeric nanoseconds from the GPS clock
clock_sec Yes numeric seconds from the system clock
clock_nsec Yes numeric nanoseconds from the system clock

This message is emitted once per second to watchers of a device and is intended to report the offset between the in-band report of the GPS and seconds as reported by the system clock (which may be NTP-corrected) when the first valid timestamp of the reporting cycle is seen.

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).

Heres an example:

{"class":"TOFF","device":"/dev/ttyUSB0",
     "real_sec":1330212592, "real_nsec":343182,
     "clock_sec":1330212592,"clock_nsec":343184}

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 12. 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_nsec Yes numeric nanoseconds from the realtime clock
clock_sec Yes numeric seconds from the system clock
clock_nsec Yes numeric nanoseconds from the system clock

This message is emitted once per second to watchers of a device emitting PPS, and is intended to report the offset between the start of the GPS second (when the 1PPS arrives) 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.)

Heres an example:

{"class":"PPS","device":"/dev/ttyUSB0",
     "real_sec":1330212592, "real_nsec":343182,
     "clock_sec":1330212592,"clock_nsec":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 devices 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 13. 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). Wont be reported if empty, e.g. before    gpsd has seen identifiable packets      from the device.
driver No string GPSDs name for the device driver type. Wont be reported before  gpsd has seen identifiable packets      from the device.
subtype When the daemon sees a delayed response to a probe for  subtype or firmware-version information. string Whatever version information the device returned.
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 14. 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.

Heres 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.

Heres 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 15. ERROR notification object

Name Always? Type Description
class Yes string Fixed    "ERROR"
message Yes string Textual error message

Heres 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 \m[blue]Radio Technical Commission for Maritime Services\m[][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 cant 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 16. 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 Observatorys \m[blue]table of leap second corrections\m[][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 17. 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 18. UDRE values

0 1-sigma error   <= 1m
1 1-sigma error   <= 4m
2 1-sigma error   <= 8m
3 1-sigma error   > 8m

Heres 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 19. 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.

Heres 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 20. 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 21. 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 doesnt match any of the known ones.

Here is the format:

Table 22. 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 23. 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.

Heres 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 24. 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 beacons 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 25. 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).

Heres 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 26. 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 27. 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.

Heres 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. 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 GPSes 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
Search for    or go to Top of page |  Section 5 |  Main Index


The GPSD Project GPSD_JSON (5) 28 Aug 2011

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.