GPSD_JSON(5)

📦
version 3.27.5 · 6 versions
, in arch rolling, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0, ubuntu resolute, ubuntu stonking

hey bestie 💖 welcome to GPSD_JSON(5) from the GPSD Documentation. this is the gpsd request/response protocol, and we're about to get into it. no cap.

✨ NAME ✨

  • gpsd_json — gpsd request/response protocol. that's the whole name, periodt 💅

💖 OVERVIEW 💖

okay so gpsd is a service daemon — think of it like the main character of your location setup ✨ — and it monitors GPSes, DGPS receivers, Marine AIS broadcasts, and a whole bunch of other location-related and kinematic sensors. it's giving very observant, very aware 💅.

clients can talk to gpsd with textual requests and responses over a socket. but bestie, it is a bad idea for applications to speak the protocol directly 🙈. instead, they should use the libgps client library (for C; bindings also exist for other languages) and take appropriate care to check in their code for the expected major and minor protocol versions. no cap, do it that way.

the GPSD protocol is built on top of JSON, JavaScript Object Notation, as specified in [RFC-7159]: The JavaScript Object Notation (JSON) Data Interchange Format. similar to ECMA 404. it's giving standardized, iconic ✨.

GPSD’s use of JSON is restricted in some ways that make parsing it in fixed-extent languages (such as C) easier. lowkey thoughtful, highkey helpful 💖.

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. so keep it cute and short, bestie 💅.

responses are single JSON objects that have a class attribute, and the value of that attribute is the object type. object types include, but are not limited to: "TPV", "SKY", "DEVICE", and "ERROR". objects are sent both in response to commands, and periodically as gpsd sends reports. each object is terminated by a carriage return and a new line (CR-NL). periodt ✨.

the order of JSON attributes within a response object is never significant, and you may specify command attributes 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 currently 10240 characters, including the trailing CR-NL. longer responses will be truncated, so client code must be prepared for the possibility of invalid JSON fragments. so don't assume it's always clean, bestie 😭.

the default maximum message length is set by GPS_JSON_RESPONSE_MAX in include/gpsd_json.h at compile time. iykyk 🔧.

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. parent first, always, that's the rule 👑.

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. it's giving organized, we love that ✨.

the next subsection 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. so check your build, bestie 💅.

the protocol was designed and documented by Eric S. Raymond. iconic author behavior 👑.

🌈 CORE PROTOCOL RESPONSES 🌈

here are the core-protocol responses, bestie 💖.

🛰️ TPV 🛰️

a TPV object is a time-position-velocity report. the "class" and "mode" fields will reliably be present. when "mode" is 0 (Unknown) there is likely no usable data in the sentence. the remaining fields are optional, their presence depends on what data the GNSS receiver has sent, and what gpsd may calculate from that data. so don't come for the optional fields, they're just vibing 🌸.

a TPV object will usually be sent at least once for every measurement epoch as determined by the "time" field. unless the receiver has a solid fix, and knows the current leap second, the time may be random. so lowkey don't trust the time if the fix is mid 😭.

multiple TPV objects are often sent per epoch. when the receiver dribbles data to gpsd, then gpsd has no choice but to dribble it to the client in multiple TPV messages. it's giving relay race, no cap 🏃‍♀️.

the optional "status" field (aka fix type), is a modifier (adjective) to mode. it is not a replacement for, or superset of, the "mode" field. it is almost, but not quite, the same as the NMEA 4.x xxGGA GPS Quality Indicator Values. many GNSS receivers do not supply it. those that do interpret the specification in various incompatible ways. to save space in the output, and avoid confusion, the JSON never includes status values of 0 or 1. so if you see status, it's 2 or higher, bestie 💅.

all error estimates (epc, epd, epe, eph, ept, epv, epx, epy) are guessed to be 95% confidence, may also be 50%, one sigma, or two sigma confidence. many GNSS receivers do not specify a confidence level. none specify how the value is calculated. use error estimates with caution, and only as relative "goodness" indicators. if the GPS reports a value to gpsd, then gpsd will report that value. otherwise gpsd will try to compute the value from the skyview. so like, take them as vibes, not gospel 🙈.

see the file include/gps.h, especially struct gps_data_t, for expanded notes on the items and values in the TPV message. go read it, it's giving extra lore 📖✨.

✨ Table 1. TPV object ✨

okay bestie, deep breath, because this is the whole TPV field menu and it is long. Every field gets a name, a "do I always show up?" flag, a type, and a lil description. Let's go 💅

  • class — always? yes 🫶 · type: string · it's fixed: "TPV". that's the whole personality.
  • device — always? nope · type: string · the name of the device this came from.
  • mode — always? yes ✨ · type: numeric · NMEA mode, and the numbers mean: 0=unknown, 1=no fix, 2=2D, 3=3D.
  • alt — always? nope · type: numeric · deprecated 💀 and undefined. do not use. use altHAE or altMSL instead, periodt.
  • altHAE — always? nope · type: numeric · altitude, aka height above ellipsoid, in meters. probably WGS84.
  • altMSL — always? nope · type: numeric · MSL altitude in meters. the geoid it's using is rarely specified and is often inaccurate, which is giving chaos ngl. see the comments below on geoidSep. and the math: altMSL is altHAE minus geoidSep.
  • ant — always? nope · type: numeric · antenna status: 2=Short, 3=Open.
  • antPwr — always? nope · type: numeric · antenna power status: 0=Unknwon (yes bestie, that's the original spelling, we don't touch it 💀), 1=Power off, 2=Power on.
  • climb — always? nope · type: numeric · climb rate when it's positive, sink rate when it's negative, in meters per second. main character energy either way.
  • clockbias — always? nope · type: numeric · offset of the local GNSS clock relative to UTC, in ns. AKA Clock Offset. sometimes it's given as Part Per Billion (ppb) which is the same as ns.
  • clockdrift — always? nope · type: numeric · the rate at which the local clock is drifting. in ns/s.
  • datum — always? nope · type: string · the current datum. hopefully WGS84 🙏
  • depth — always? nope · type: numeric · depth in meters. probably depth below the keel…
  • dgpsAge — always? nope · type: numeric · age of DGPS data. in seconds.
  • dgpsSta — always? nope · type: numeric · station of DGPS data.
  • ecefx — always? nope · type: numeric · ECEF X position in meters.
  • ecefy — always? nope · type: numeric · ECEF Y position in meters.
  • ecefz — always? nope · type: numeric · ECEF Z position in meters.
  • ecefpAcc — always? nope · type: numeric · ECEF position error in meters. certainty unknown, so like… vibe check inconclusive 🦋
  • ecefvx — always? nope · type: numeric · ECEF X velocity in meters per second.
  • ecefvy — always? nope · type: numeric · ECEF Y velocity in meters per second.
  • ecefvz — always? nope · type: numeric · ECEF Z velocity in meters per second.
  • ecefvAcc — No · numeric · ECEF velocity error in meters per second. Certainty unknown. 😭
  • epc — No · numeric · Estimated climb error in meters per second. Certainty unknown. 😭
  • epd — No · numeric · Estimated track (direction) error in degrees. Certainty unknown. 😭
  • eph — No · numeric · Estimated horizontal Position (2D) Error in meters. Also known as Estimated Position Error (epe). Certainty unknown. 😭
  • eps — No · numeric · Estimated speed error in meters per second. Certainty unknown. 😭
  • ept — No · numeric · Estimated time stamp error in seconds. Certainty unknown. 😭
  • epx — No · numeric · Longitude error estimate in meters. Certainty unknown. 😭
  • epy — No · numeric · Latitude error estimate in meters. Certainty unknown. 😭
  • epv — No · numeric · Estimated vertical error in meters. Certainty unknown. 😭
  • geoidSep — No · numeric · Geoid separation is the difference between the WGS84 reference ellipsoid and the geoid (Mean Sea Level) in meters. Almost no GNSS receiver specifies how they compute their geoid. gpsd interpolates the geoid from a 5x5 degree table of EGM2008 values when the receiver does not supply a geoid separation. The gpsd computed geoidSep is usually within one meter of the "true" value, but can be off as much as 12 meters. 🌍✨
  • jam — No · numeric · Jamming Indicator 0 (no jamming) to 255 (severe jamming). -1 means unset. 🚨
  • lat — No · numeric · Latitude in degrees: +/- signifies North/South. 🧭
  • leapseconds — No · integer · Current leap seconds. ⏳
  • lon — No · numeric · Longitude in degrees: +/- signifies East/West. 🗺️
  • magtrack — No · numeric · Course over ground, degrees magnetic. 🧲
  • magvar — No · numeric · Magnetic variation, degrees. Also known as the magnetic declination (the direction of the horizontal component of the magnetic field measured clockwise from north) in degrees, Positive is West

…and that last field wraps up with Negative is East variation. 💅 Okay bestie, continuing the field list, and reminder: every single one of these is Required: No, meaning the TPV might just... not have it. Ghost you. 🙈

  • relD — No. numeric. Down component of the relative position vector, in meters. ⬇️
  • relE — No. numeric. East component of the relative position vector, in meters. ➡️
  • relN — No. numeric. North component of the relative position vector, in meters. ⬆️
  • sep — No. numeric. Estimated Spherical (3D) Position Error, in meters. It's guessed to be 95% confidence, but so many GNSS receivers don't specify, so honestly the certainty is unknown. It's giving "trust me bro". 😭
  • speed — No. numeric. Speed over ground, meters per second. 🏃‍♀️
  • status — No. numeric. The GPS fix status, and here's the whole vibe check:
    • 0 = Unknown
    • 1 = Normal
    • 2 = DGPS
    • 3 = RTK Fixed
    • 4 = RTK Floating
    • 5 = DR
    • 6 = GNSSDR
    • 7 = Time (surveyed)
    • 8 = Simulated
    • 9 = P(Y)
  • temp — No. numeric. Receiver temperature, in degrees Celsius. 🌡️
  • time — No. string. The time/date stamp in ISO8601 format, UTC. It may have a fractional part with up to .001sec precision. It may be absent if the mode is not 2D or 3D. It may also be present but invalid if there is no fix. And like — before you believe it's actually UTC, verify 3 consecutive 3D fixes, bestie. Even then it can be off by several seconds until the current leap seconds is known. 🕰️ Not me trusting a timestamp before the leap seconds situation is settled 💀
  • track — No. numeric. Course over ground, degrees from true north. 🧭
  • velD — No. numeric. Down velocity component, in meters. ⬇️
  • velE — No. numeric. East velocity component, in meters. ➡️
  • velN — No. numeric. North velocity component, in meters. ⬆️
  • wanglem — No. numeric. Wind angle magnetic, in degrees. 🌬️
  • wangler — No. numeric. Wind angle relative, in degrees. 🌬️
  • wanglet — No. numeric. Wind angle true, in degrees. 🌬️
  • wspeedr — No. numeric. Wind speed relative, in meters per second. 💨
  • wspeedt — No. numeric. Wind speed true, in meters per second. 💨
  • wtemp — No. numeric. Water temperature, in degrees Celsius. 🌊

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 received — see gps.h for the bitmask names and values. 👑

🚨 Real talk, do not skip this: invalid or unknown floating-point values will be set to NAN. Always check floating point values with isfinite() before use. isnan() is not sufficient. Periodt. 🙅‍♀️

Here's an example TPV sentence:

...and here's the rest of that example, all laid out so you can see the whole vibe in one place 💖

{"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 ✨ 🛰️

Okay so SKY is the one that gives you the whole sky view of where the GPS satellites are at 🦋 — like, the entire squad up there, mapped out.

But bestie, listen: if there's no GPS device available, or no skyview has been reported yet, then literally the only field you can count on being there is "class". That's it. That's the whole guaranteed guest list. Everything else is a maybe 🙈

So don't come for SKY's fields like they're promised, because they are not — the "class" field is the only one that reliably shows up. Periodt 💅

✨ Table 2. SKY object ✨

okay bestie, this is the big one — every single field that can show up in a SKY object 💖. For each one I'm telling you its name, whether it's Always? there or just maybe-there, what Type it is, and what it means. no skips, no shortcuts, we're doing all of them 🫶

  • class — Always? Yes · Type: string · Fixed, always literally "SKY". that's the whole job, she's just announcing herself 💅
  • device — Always? No · Type: string · Name of the originating device. like, whose tea is this 👀
  • nSat — Always? No · Type: numeric · Number of satellite objects sitting in the "satellites" array. it's giving headcount 🌸
  • gdop — Always? No · Type: numeric · Geometric (hyperspherical) dilution of precision, a combination of PDOP and TDOP. It's a dimensionless factor which should be multiplied by a base UERE to get an error estimate. two dop's in a trenchcoat fr fr 🧚
  • hdop — Always? No · Type: numeric · Horizontal dilution of precision, a dimensionless factor which should be multiplied by a base UERE to get a circular error estimate. horizontal bestie, side to side ✨
  • pdop — Always? No · Type: numeric · Position (spherical/3D) dilution of precision, a dimensionless factor which should be multiplied by a base UERE to get an error estimate. three-dimensional main character energy 🔥
  • pr — Always? No · Type: numeric · Pseudorange, in meters. 📏
  • prRate — Always? No · Type: numeric · Pseudorange Rate of Change, in meters / second. she's moving, she's thriving 🦋
  • prRes — Always? No · Type: numeric · Pseudorange residue, in meters. the leftovers, the crumbs 💀
  • qual — Always? No · Type: numeric · Quality Indicator. the vibe check in number form, and the scale is:
    • 0 = no signal
    • 1 = searching signal
    • 2 = signal acquired
    • 3 = signal detected but unusable
    • 4 = code locked and time synchronized
    • 5, 6, 7 = code and carrier locked and time synchronized

so 0 through 7, and anything past 4 means she's fully locked in 🔒👑

  • satellites — Always? No · Type: list · List of satellite objects in skyview. the whole group chat 🌈
  • tdop — Always? No · Type: numeric · Time dilution of precision, a dimensionless factor which should be multiplied by a base UERE to get an error estimate. clock edition ⏰
  • time — Always? No · Type: string · Time/date stamp in ISO8601 format, UTC. May have a fractional part of up to .001sec precision. UTC periodt, no timezone drama 🙈
  • uSat — Always? No · Type: numeric · Number of satellites used in navigation solution. used, not just seen — big difference bestie 👀
  • vdop — Always? No · Type: numeric · Vertical (altitude) dilution of precision, a dimensionless factor which should be multiplied by a base UERE to get an error estimate. up and down, altitude style 🎀
  • xdop — Always? No · Type: numeric · Longitudinal dilution of precision, a dimensionless factor which should be multiplied by a base UERE to get an error estimate. the long way round 💜
okay tiny heads-up: the Always? column is doing a lot of heavy lifting here. only class is a guaranteed yes — everything else in this table can ghost you, so check before you assume, no cap 💅

every field accounted for, every type named, nothing skipped ✨

  • ydop — No / numeric. Latitudinal dilution of precision, a dimensionless factor which should be multiplied by a base UERE to get an error estimate. A.k.a. Easting DOP. 💅

Okay bestie, real talk: so many devices compute dilution of precision factors but just… don't put them in their reports. Rude. 🙈 And a bunch of the ones that do report DOPs only give you HDOP, which is just the two-dimensional circular error. Not the whole story.

But here's the thing: gpsd is a girlboss. She always passes through whatever the device reports, and then she tries to fill in the other DOPs by calculating the appropriate determinants in a covariance matrix based on the satellite view. ✨

Heads up though — DOPs may be missing if some of these determinants are singular. And 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. So like, don't come for gpsd when the math just isn't mathing. 💀

🌸 The satellite list objects 🌸

The satellite list objects have these elements, periodt:

Table 3. Satellite object 🛰️

  • PRN — Always? Yes. Type: numeric. PRN ID of the satellite. See "PRN, GNSS ID, SV ID, AND SIG ID".
  • az — Always? No. Type: numeric. Azimuth, degrees from true north. 🧭
  • el — Always? No. Type: numeric. Elevation in degrees.
  • freqid — Always? No. Type: numeric. For GLONASS satellites only: the frequency ID of the signal. As defined by u-blox, range 0 to 13. The freqid is the frequency slot plus 7.
  • gnssid — Always? No. Type: numeric. The GNSS ID. See "PRN, GNSS ID, SV ID, AND SIG ID".
  • health — Always? No. Type: numeric. The health of this satellite. 0 is unknown, 1 is OK, and 2 is unhealthy. 🩺
  • ss — Always? No. Type: numeric. Signal to Noise ratio in dBHz. 📶
  • sigid — Always? No. Type: numeric. The signal ID of this signal. See "PRN, GNSS ID, SV ID, AND SIG ID" u-blox, not NMEA. See u-blox doc for details.
  • svid — Always? No. Type: numeric. The satellite ID (PRN) within its constellation. See "<<PRNs>".
  • used — Always? Yes. Type: 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.) 👑

Quick lil note, bestie: satellite objects do not have a "class" field, because they are never shipped outside of a SKY object. They're always the plus-one, never the main character. 🫶

Also — when the C client library parses a SKY response, it will assert the SATELLITE_SET bit in the top-level set member. Mark it down. ✍️

Here's an example, because a vibe check needs receipts:

{"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. That's it, that's the whole vibe. 🔥

✨ Table 4. GST object ✨

Okay bestie, meet the GST object — it's the little statistical hype squad that rides along with your position, telling you how sure the fix actually is. Every field except class is optional (they show up "No" on the always-here list), so don't panic if you don't see them all. 💖

  • class — Always? Yes · Type: string — Fixed: "GST". This one's non-negotiable, it's the name tag.
  • device — Always? No · Type: string — Name of originating device.
  • time — Always? No · Type: string — Time/date stamp in ISO8601 format, UTC. May have a fractional part of up to .001sec precision.
  • rms — Always? No · Type: numeric — Value of the standard deviation of the range inputs to the navigation process (range inputs include pseudoranges and DGPS corrections).
  • major — Always? No · Type: numeric — Standard deviation of semi-major axis of error ellipse, in meters.
  • minor — Always? No · Type: numeric — Standard deviation of semi-minor axis of error ellipse, in meters.
  • orient — Always? No · Type: numeric — Orientation of semi-major axis of error ellipse, in degrees from true north.
  • alt — Always? No · Type: numeric — Standard deviation of altitude error, in meters.
  • lat — Always? No · Type: numeric — Standard deviation of latitude error, in meters.
  • lon — Always? No · Type: numeric — Standard deviation of longitude error, in meters.
  • ve — Always? No · Type: numeric — Standard deviation of East velocity error, in meters / second.
  • vn — Always? No · Type: numeric — Standard deviation of North velocity error, in meters / second.
  • vu — Always? No · Type: numeric — Standard deviation of Up velocity error, in meters / second.

Here's an example, so you can see the vibe in the wild:

{"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 gets returned by digital-compass and gyroscope sensors 🧚, and depending on the device it may include: heading, pitch, roll, yaw, gyroscope, and magnetic-field readings. And because those 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. Everything else? It may be reported or not depending on the specific device type — so like, vibe check each device individually, no cap.

The ATT object is synchronous to the GNSS epoch. But some devices report attitude information with arbitrary, even out of order, time scales. When that happens, gpsd reports those in an IMU object instead. The ATT and IMU objects have the same fields, but IMU objects are output as soon as possible. Some devices output both types with arbitrary interleaving. 😭 iconic chaos, honestly.

Table 5. ATT object 🧭✨

Okay bestie, this is the ATT object — attitude, heading, that whole vibe. It's giving "I know which way is up and I'm not afraid to say it." Every field below is on a Name / Always? / Type / Description basis, so let's get into it 🫶

  • class — Always? Yes 💅 · type: string · Fixed value: "ATT". It never changes, it's iconic like that.
  • device — Always? Yes 🌸 · type: string · the name of the device this reading came from.
  • time — Always? No 🕐 · type: string · time/date stamp in ISO8601 format, UTC. It may have a fractional part with up to .001sec precision.
  • timeTag — Always? No 🏷️ · type: string · an arbitrary time tag for the measurement.
  • heading — Always? No 🧭 · type: numeric · heading, in degrees from true north.
  • mag_st — Always? No 🧲 · type: string · magnetometer status.
  • mheading — Always? No 🧭💜 · type: numeric · heading, in degrees from magnetic north.
  • pitch — Always? No 📐 · type: numeric · pitch, in degrees.
  • pitch_st — Always? No 📐✨ · type: string · pitch sensor status.
  • rot — Always? No 🔄 · type: numeric · rate of turn, in degrees per minute.
  • yaw — Always? No 🌀 · type: numeric · yaw, in degrees.
  • yaw_st — Always? No 🌀✨ · type: string · yaw sensor status.
  • roll — Always? No 🎢 · type: numeric · roll, in degrees.
  • roll_st — Always? No 🎢✨ · type: string · roll sensor status.
  • dip — Always? No 🌍 · type: numeric · local magnetic inclination, in degrees. It's positive when the magnetic field points downward, i.e. into the Earth. Not me getting deep about the planet's magnetic vibes 😭
  • mag_len — Always? No 🧲 · type: numeric · scalar magnetic field strength.
  • mag_x — Always? No 🧲 · type: numeric · X component of magnetic field strength.
  • mag_y — Always? No 🧲 · type: numeric · Y component of magnetic field strength.
  • mag_z — Always? No 🧲 · type: numeric · Z component of magnetic field strength.
  • acc_len — Always? No 🏃 · type: numeric · scalar acceleration.
  • acc_x — Always? No 🏃 · type: numeric · X component of acceleration (m/s^2).
  • acc_y — Always? No 🏃 · type: numeric · Y component of acceleration (m/s^2).
  • acc_z — Always? No 🏃 · type: numeric · Z component of acceleration (m/s^2).
  • gyro_x — Always? No 💫 · type: numeric · X component of angular rate (deg/s).
  • gyro_y — Always? No 💫 · type: numeric · Y component of angular rate (deg/s).
  • gyro_z — Always? No 💫 · type: numeric · Z component of angular rate (deg/s).
  • depth — Always? No 🌊 · type: numeric · water depth, in meters.
  • temp — No — numeric — the temperature right at the sensor, in degrees centigrade 🌡️ (and that's a wrap on the ATT object fields, bestie, you made it 💖)

okay so the heading, pitch, and roll status codes (if present) are not one-size-fits-all — they vary by device. for the TNT Revolution digital compasses specifically, they're coded like this 👇

Table 6. Device flags

  • 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. periodt. 🫶

and here's a lil example, no cap:

    {"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}

🌈 IMU 🌈

the IMU object is asynchronous to the GNSS epoch. it gets reported with arbitrary time scales — like, even out of order. it's giving chaos but make it timing data 😭

the ATT and IMU objects have the same fields, but IMU objects are output as soon as possible. no waiting around, main character energy ⚡

for the field deets, go check the ATT object description — it's all there, iykyk ✨

⏰ TOFF ⏰

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

this message exactly mirrors the PPS message.

the TOFF message reports the GPS time as derived from the GPS serial data stream. the PPS message reports the GPS time as derived from the GPS PPS pulse. two different sources, same vibe check 💅

a TOFF object has these elements:

Table 7. TOFF object

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

this message is emitted once per second to watchers of a device, and it's intended to report the timestamps of the in-band report of the GPS and seconds as reported by the system clock (which may be NTP-corrected) when the first valid time stamp of the reporting cycle was seen.

the message contains two second/nanosecond pairs: real_sec and real_nsec contain the time the GPS thinks it was at the start of the current cycle; clock_sec and clock_nsec contain the time the system clock thinks it was on receipt of the first timing message of the cycle. real_nsec is always to nanosecond precision. clock_nsec is nanosecond precision on most systems.

here's an example, so you can see the whole fit 👑

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

💅 PPS 💅

this message is emitted each time the daemon sees a valid PPS (Pulse Per Second) strobe from a device.

this message exactly mirrors the TOFF message.

the TOFF message reports the GPS time as derived from the GPS serial data stream. the PPS message reports the GPS time as derived from the GPS PPS pulse.

okay so real talk — there are various sources of error in the reported clock times, and we're not gonna pretend otherwise 😭 the speed of the serial connection between the GPS and the system adds a delay to the start of cycle detection. an even bigger error is added by the variable computation time inside the GPS. taken together, the time derived from the start of the GPS cycle can have offsets of 10 milliseconds to 700 milliseconds and combined jitter and wander of 100 to 300 milliseconds. that's a lot of wiggle, bestie 💀

see the NTP documentation for their definition of precision 👀

a PPS object has the following elements:

Table 8. PPS object 🕐

  • class — string — always present, bestie. Fixed value: "PPS".
  • device — string — always present. The name of the originating device.
  • real_sec — numeric — always present. Seconds from the PPS source.
  • real_nsec — numeric — always present. Nanoseconds from the PPS source.
  • clock_sec — numeric — always present. Seconds from the system clock.
  • clock_nsec — numeric — always present. Nanoseconds from the system clock.
  • precision — numeric — always present. An NTP style estimate of the PPS precision.
  • shm — string — always present. The shm key of this PPS.
  • qErr — numeric — not always there, so check before you use it 🙈. Quantization error of the PPS, in picoseconds. Sometimes called the "sawtooth" error.

This message is emitted once per second to watchers of a device emitting PPS, and it reports the time of the start of the GPS second (that's when the 1PPS arrives) plus the seconds as reported by the system clock (which may be NTP-corrected) at that exact moment. Like, it's the receipts of "what time did GPS think it was vs. what did your computer think it was" 📸

The message contains two second/nanosecond pairs: real_sec and real_nsec contain the time the GPS thinks it was at the PPS edge; clock_sec and clock_nsec contain the time the system clock thinks it was at the PPS edge. real_nsec is always to nanosecond precision. clock_nsec is nanosecond precision on most systems. <em>most</em>. iykyk 😭

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; that can be reduced to less than 1 microsecond if your kernel supports [RFC-2783]. USB1.1-to-serial control-line emulation is limited to about 1 millisecond. seconds.

Here's an example:

    {"class":"PPS","device":"/dev/ttyUSB0",
         "real_sec":1330212592, "real_nsec":343182,
         "clock_sec":1330212592,"clock_nsec":343184,
         "precision":-3}

🛰️ OSC 🛰️

This message reports the status of a GPS-disciplined oscillator (GPSDO). The GPS PPS output (which has excellent long-term stability) is typically used to discipline a local oscillator with much better short-term stability (such as a rubidium atomic clock). it's giving "the wise old one teaches the hyperactive one to chill" ✨

An OSC object has the following elements:

Table 9. OSC object 🎀

  • class — string — always present. Fixed value: "OSC".
  • device — string — always present. Name of the originating device.
  • running — boolean — always present. If true, the oscillator is currently running. Oscillators may require warm-up time at the start of the day. give it a minute, it's waking up 🥱
  • reference — boolean — always present. If true, the oscillator is receiving a GPS PPS signal.
  • disciplined — boolean — always present. If true, the GPS PPS signal is sufficiently stable and is being used to discipline the local oscillator.
  • delta — numeric — always present. The time difference (in nanoseconds) between the GPS-disciplined oscillator PPS output pulse and the most recent GPS PPS input pulse.

Here's an example:

    {"class":"OSC","running":true,"device":"/dev/ttyUSB0",
        "reference":true,"disciplined":true,"delta":67}

💬 CORE PROTOCOL COMMANDS 💬

And here are the commands you can send to gpsd. your turn to talk back, bestie 🫶

?VERSION;

Returns an object with the following attributes:

🩵 Table 10. VERSION object

okay so here's what lives inside a VERSION object, field by field bestie:

  • class — Always? Yes. Type: string. Fixed value: "VERSION". Like, that's just its whole name tag. 💅
  • release — Always? Yes. Type: string. The public release level.
  • rev — Always? Yes. Type: string. The internal revision-control level. (the git vibes, basically)
  • proto_major — Always? Yes. Type: numeric. The API major revision level.
  • proto_minor — Always? Yes. Type: numeric. The API minor revision level.
  • remote — Always? No. Type: string. URL of the remote daemon reporting this version. If it's empty, then this is the version of the local daemon. 🫶

The daemon ships a VERSION response to each client when the client first connects to it. Like, it's the little "hi, here's who I am" moment. 👑

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 11. DEVICES object

  • class — Always? Yes. Type: string. Fixed value: "DEVICES".
  • devices — Always? Yes. Type: list. A list of device descriptions. This is the main character of the whole object fr fr. ✨
  • remote — Always? No. Type: string. URL of the remote daemon reporting the device set. If it's 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. so don't panic if you see one floating around all by itself, it's valid, it's just unmasked. 🦋

💜 ?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 12. WATCH object 🌸

okay so this is the whole WATCH object, bestie — every field, whether it's always there, what type it is, and what it does. no skipping, we're doing all of them 💅

  • class — Always? Yes. Type: string. It's fixed: "WATCH". literally always that, no notes.
  • enable — Always? No. Type: boolean. Turns watcher mode on (true) or off (false). Default is true. ✨
  • json — Always? No. Type: boolean. Turns the dumping of JSON reports on (true) or off (false). Default is false.
  • nmea — Always? No. Type: boolean. Turns the dumping of binary packets as pseudo-NMEA on (true) or off (false). Default is false. 🛰️
  • raw — Always? No. Type: integer. This one controls raw mode and it has ✌️two✌️ whole behaviours, so pay attention:
    • 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 get 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. no cap.
  • scaled — Always? No. Type: boolean. If true, apply scaling divisors to output before dumping. Default is false.
  • split24 — Always? No. Type: boolean. If true, aggregate AIS type24 sentence parts. If false, report each part as a separate JSON object and leave the client to match MMSIs and aggregate. Default is false. This only applies to AIS reports, iykyk. 🚢
  • pps — Always? No. Type: boolean. If true, emit the TOFF JSON message on each cycle, plus a PPS JSON message when the device issues 1PPS. Default is false. ⏱️
  • device — Always? No. Type: string. If it's present, enable watching only of the specified device instead of all devices. Super useful with raw and NMEA modes, where device responses aren't tagged. Has no effect when used with enable:false.
  • remote — Always? No. Type: string. URL of the remote daemon reporting the watch set. If it's empty, this is a WATCH response from the local daemon. 🌈

okay and there's one more, an extra boolean "timing" attribute — it is undocumented because that portion of the interface is considered unstable and is for developer use only. so like… don't touch it unless you're that girl. 🙈

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, bestie:

{"class":"WATCH", "raw":1,"scaled":true}

📡 ?POLL; 📡

The POLL command requests data from the last-seen fixes on all active GPS devices. Heads up though — devices must previously have been activated by ?WATCH to be pollable. no watch, no poll, periodt. 💅

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 only the fix data collected so far in the current epoch. It may be as much as one cycle time (typically 1 second) stale.

so yeah, lowkey stale data is a real possibility there. 😭

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 13. POLL object 🌸

okay bestie here's the whole POLL glow-up, field by field 💅

  • class — Always? Yes. Type: string. Fixed value: "POLL". Like, it never changes, that's just its name tag 🎀
  • time — Always? Yes. Type: Numeric. A timestamp in ISO 8601 format. May have a fractional part of up to .001sec precision. ✨
  • active — Always? Yes. Type: Numeric. The count of active devices. 👑
  • tpv — Always? Yes. Type: JSON array. A comma-separated list of TPV objects. 🛰️
  • sky — Always? Yes. Type: JSON array. A comma-separated list of SKY objects. 🌌

Here's an example of a POLL response, so you can see the whole vibe:

{"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. So like… don't hardcode your parser, bestie, that's the vibe check 😭

?DEVICE; ?DEVICE=

So this one has two moods, and which one you get depends on the punctuation 💅

  • Followed by ; → it reports the state of a device.
  • Followed by = and a DEVICE object → it sets 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 and a device path is not specified. so like, no device path + a crowd = nope 🙈

Pay attention to the response, because it is possible for this command to fail if the GPS does not support a command or only supports some combinations of modes. In case of failure, the daemon and GPS will continue to communicate at the old speed. Nothing breaks, it just… didn't take, bestie 😭
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. 💀 like fr fr that's the scary part, be careful.

A DEVICE object has the following elements:

📋 Table 14. DEVICE object 🛰️

okay bestie, here's the whole DEVICE object lineup, every single field, no skips, no cap 💅 The "Always?" column is literally just is this field always there? and Type is the type. Let's get into it:

  • class — Always? Yes ✨ · Type string · Fixed, like forever: "DEVICE". That's its whole identity, its main character moment.
  • activated — Always? No · Type string · The time the device got activated, written as an ISO8601 time stamp. If the device is inactive, this attribute is just… absent. Ghosted you fr.
  • bps — Always? No · Type integer · Device speed, in bits per second. Slay.
  • cycle — Always? No · Type real · Device cycle time, in seconds. ⏱️
  • driver — Always? No · Type string · GPSD's name for the device driver type. Heads up: it won't be reported before gpsd has seen identifiable packets from the device. So no packets, no driver name, periodt.
  • flags — Always? No · Type integer · A bit vector of property flags. Currently the defined flags are: describe packet types seen so far (GPS, RTCM2, RTCM3, AIS). It won't be reported if it's empty — e.g. before gpsd has seen identifiable packets from the device.
  • hexdata — Always? No · Type string · Data, in bare hexadecimal, to send to the GNSS receiver. Bare hex, no decoration, no frills 🫶
  • mincycle — Always? No · Type real · Device minimum cycle time, in seconds. Reported from ?DEVICE when (and only when) the rate is switchable. It is read-only and not settable — look but don't touch, bestie 💅
  • native — Always? No · Type 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. Like, it WILL fight back.
  • parity — Always? No · Type string · N, O or E for no parity, odd, or even. Pick your vibe ✨
  • path — Always? No · Type string · Names 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. One channel only? Then it's optional. More than one? Bestie you gotta say which.
  • readonly — Always? No · Type boolean · True if the device is read-only. Don't even think about writing to it 🙈
  • sernum — Always? No · Type string · Hardware serial number (if the device driver returns that value). If the driver doesn't hand it over, it's simply not here.
  • stopbits — Always? Yes 🌟 · Type integer · Stop bits (1 or 2).
  • subtype — Always? No · Type string · Whatever version information the device driver returned.
  • subtype1 — Always? No · Type string · More version information the device driver returned. Yeah, there's a sequel 🎀

The serial parameters — that's bps, parity, stopbits — will be omitted in a response describing a TCP/IP source such as an Ntrip, DGPSIP, or AIS feed. But on a serial device? They will always be present. No exceptions, iykyk 💜

The contents of the flags field should be interpreted as follows:

🌸 DEVICE flags (Table 15) 🌸

Like, every device in the pool carries a lil flag bitmap, and here's the whole tea:

  • SEEN_GPS — value 0x01 — GPS data has been seen on this device
  • SEEN_RTCM2 — value 0x02 — RTCM2 data has been seen on this device
  • SEEN_RTCM3 — value 0x04 — RTCM3 data has been seen on this device
  • SEEN_AIS — value 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. fr fr.

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. (yes bestie it says it twice, that's just how much it means it 💅)

✨ Examples ✨

A notice of a deactivated device:

{"class":"DEVICE","path":"/dev/pts1","activated":0}

A send a u-blox receiver at /dev/ttyUSB2 a request for a UBX-MON-VER message:

?DEVICE={"path":"/dev/ttyUSB2","hexdata":"b5620a0400000e34"}

The gpsd daemon will respond with an ACK on success:

{"class":"ACK"}

🚨 ERROR 🚨

The daemon may ship an error object in response to a syntactically invalid command line or unknown command. It has the following elements:

Table 16. ERROR notification object

  • class — Always? Yes — Type: string — Fixed: "ERROR"
  • message — Always? Yes — Type: 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. noted. 📝

🛰️ 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. it's giving teamwork.

RTCM-104 comes in two major and incompatible flavors, 2.x and 3.x. Each major flavor has minor (compatible) revisions. so like, cousins not twins, okurrr.

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 https://www.rtcm.org/ 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 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 a 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.) lowkey physics being mean to us 😭

🧬 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 the 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. iconic honestly. 👑

🎀 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. no skips, no shortcuts, bestie. 💅

SKY object 🛰️✨

Wait, bestie, this table's literally called "SKY object" but it's the RTCM2 header portion, iykyk. Here's every field, no cap:

  • class — string. Fixed value, always "RTCM2". Periodt. 💅
  • type — integer. The message type, and it lives in the range 1-9.
  • station_id — integer. The id of the GPS reference receiver. Heads up though: the LF transmitters also have their own id numbers, and they're different ones. 👀
  • zcount — real. The reference time of the corrections in the message, measured in seconds within the current hour. And not me warning you — it's in GPS time, which runs some seconds ahead of UTC. (The U.S. Naval Observatory's [UTC-TAU] table of leap second corrections is where you go for that tea.) 🕐
  • seqnum — integer. Sequence number. It's only 3 bits wide, so it wraps after 7. Tiny. Iconic but tiny. 🎀
  • length — integer. How many words come after the header to make up the whole message.
  • station_health — integer. Station transmission status — it tells you how healthy the beacon is as a reference source. Any nonzero value means the satellite is probably transmitting bad data and should not be used in a fix. That's not a vibe, that's a warning. 💀 Specifically: 6 means the transmission is unmonitored, and 7 means the station is not working properly. Any other values are defined by the beacon operator.

And <message type> is one of these babies:

  1. full corrections — one message carrying corrections for all GPS satellites in view. Apparently this one isn't common.
  2. reference station parameters — the position of the reference station's GPS antenna.
  3. datum — the datum that the DGPS data is referred to.
  4. constellation health — info about the satellites the beacon can see.
  5. null message — just a filler. It's giving nothing and it knows it. 🙈
  6. radio beacon almanac — info about this beacon or other beacons.
  7. subset corrections — a message with corrections for only a subset of the GPS satellites in view.
  8. special message — a text message straight from the beacon operator.
  9. GLONASS subset corrections — a message with 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's the format, bestie:

Satellite object

  • ident — integer. The PRN number of the satellite this correction data is for. See "<<PRNs>". 🌈
  • udre — integer. User Differential Range Error, and it's in the range 0-3. Values are in the table right below this one. ⬇️
  • iod — integer. Issue Of Data, matching the IOD for the current ephemeris of this satellite, as transmitted by the satellite. So basically: the IOD is a unique tag that identifies the ephemeris, and the GPS using the DGPS correction plus the DGPS generating the data must use the same orbital positions for the satellite. No mixing, no matching wrong, fr fr. 🧚
  • 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 what gets used to calculate pseudorange errors at other epochs, if the GPS receiver needs that.

UDRE values ✨

User Differential Range Error values are as follows:

  • 0 — 1-sigma error ⇐ 1 m
  • 1 — 1-sigma error ⇐ 4 m
  • 2 — 1-sigma error ⇐ 8 m
  • 3 — 1-sigma error > 8 m

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 📍

OK bestie so when you get a type 3 (Reference Station Parameters) message, these are the payload members you're working with:

Table 20. Reference Station Parameters

  • x — type real. The ECEF X coordinate. 💫
  • y — type real. The ECEF Y coordinate. 💫
  • z — type real. The ECEF Z coordinate. 💫

So like, these coordinates are the position of the station, in meters to two decimal places, in Earth Centred Earth Fixed coordinates. And fr fr, these are usually referred to the WGS84 reference frame, but they might be referred to NAD83 in the US instead (which is essentially identical to WGS84 for literally everyone except geodesists 🧚), or some other reference frame in other parts of the world. So like, know your frame, bestie.

An invalid reference message is represented by a type 3 header without payload fields. No x, no y, no z. Just vibes and a header. 😭

Here's an example, slay:

           {"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 21. Datum

  • dgnss_type — type string. Either "GPS", "GLONASS", "GALILEO", or "UNKNOWN". ✨
  • dat — type integer. This one is 0 or 1 and it indicates the sense of the offset shift given by dx, dy, dz. And okay, listen, because this is the part everyone gets confused about: 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. So like... it flips the direction. Iconic, honestly. 💅
  • datum_name — type string. A standard name for the datum. 🎀
  • dx — type real. X offset. 🦋
  • dy — type real. Y offset. 🦋
  • dz — type real. Z offset. 🦋

<dx> <dy> <dz> are offsets to convert from local datum to GNSS datum or vice versa. And guess what — these fields are optional. So don't come for me if they're not there. 🙈

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. So like, if you've got a whole constellation out there, you're getting a whole pile of these. Not me counting them. 💀

Here's the format:

Table 22. Constellation health

  • ident — type integer. The PRN number of the satellite. See "<<PRNs>". 🌟
  • iodl — type bool. True indicates that this information relates to the satellite information in an accompanying type 1 or type 9 message. 🔗
  • health — type integer. 0 indicates that the satellite is healthy. Any other value indicates a problem (coding is not known). So like, not us knowing what 3 means. Periodt. 😭
  • snr — type integer. The carrier/noise ratio of the received signal in the range 25 to 55 dB(Hz). 📶
  • health_en — type bool. If set to True it indicates that the satellite is healthy even if the satellite navigation data says it is unhealthy. So it's the override button, bestie. 👑
  • new_data — type bool. True indicates that the IOD for this satellite will soon be updated in type 1 or 9 messages. 🔄
  • los_warning — type bool. Line-of-sight warning. True indicates that the satellite will shortly go unhealthy. Like a little heads-up text before things go sideways. ⚠️
  • tou — type integer. Healthy time remaining in seconds. ⏳

Type 6: Null 🫧

okay so this one is literally nothing. it just says "hey, here's a null message." there are no payload fields. that's it. that's the whole vibe. iconic minimalism ✨

Unknown message 💀

when the message type field doesn't match any of the known ones, this format shows up and just dumps the message words in hexadecimal. it's giving "mystery box, no context."

here's the format:

Table 23. Unknown Message

  • 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. ngl the high two bits should be ignored. periodt. 🙈

Type 7: Radio Beacon Almanac 📻

here's the format:

Table 24. Constellation health

  • 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.
  • 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. 😭 (the way they can't even agree on how WIDE it is…)
  • 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. don't mix them up bestie 💅
  • 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 25. Ground Transmitter Parameters

  • 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).
  • 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. 🌧️
  • status (bool) — If True, signals user to expect a type 16 explanatory message associated with this station. Probably indicates some sort of unusual event. 👀

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 26. Reference Station Parameters

  • hour (integer) — Hour of week (0-167).
  • leapsecs (integer) — Leap Seconds (0-63).
  • week (integer) — GPS week (0-123).

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 ✨

Okay so this one is short and sweet, bestie — literally one field. It's giving "postcard from the beacon operator" energy. 💌

  • message — string. A text message sent by the beacon operator. That's it. That's the whole vibe.

✨ Type 31: Correction data ✨

So here's the tea: one or more GLONASS satellite objects follow the header for type 1 or type 9 messages. Here's the format of each one, bestie — I'm laying it out field by field because there's a lot going on and we're not skipping any of it. 🛰️

Satellite object

  • ident — integer. The PRN number of the satellite for which this is correction data. Peep the section called "PRN, GNSS ID, SV ID, AND SIG ID" if you need the deets. 👀
  • udre — integer. User Differential Range Error, and it lives in the range 0-3. See the table that follows for the actual values.
  • change — boolean. The change-of-ephemeris bit. 🔄
  • tod — uinteger. Count of 30-second periods since the top of the hour. Clock math, no cap.
  • 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. Future-proofing, honestly. ✨

Here's an example, and yes I'm giving it to you in full because every single satellite object matters:

{"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 🔥

Bestie. Bestie, listen. 💀 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.

Like, I need you to hear me on this one: not production. Not even a little. If you're curious, go read the source — that's where the truth lives. 📖

🌊 AIS DUMP FORMATS 🌊

AIS support is an extension, which is fancy-speak for "it might not be there." It may not be present if your instance of gpsd has been built with a restricted feature set. So if it's ghosting you, that might be why. 🫥

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 two get emitted before any type-specific fields — they're the little intro, the opening act. 🎀) It will also contain a "device" field naming the data source. All the other fields have names and types as specified in the AIVDM/AIVDO Protocol Decoding document on the GPSD project website, and honestly? Each message field table there may be directly interpreted as a specification for the members of the corresponding JSON object type. So it's basically a spec you can just read straight off. Iconic.

By default, certain scaling and conversion operations are performed for JSON output, and here's the full rundown because we do not gatekeep: 🌸

  • 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 it 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. Yes, quadratically. She's doing math. 💅
  • 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 🛰️

okay bestie, real talk: subframe support is always compiled into gpsd, periodt. but — and this is the messy part 😭 — lots of GPSes straight up do not output subframe data, or the gpsd driver just doesn't support subframes. so like, don't come for gpsd if nothing shows up, it's giving "not my fault."

Subframe packets get dumped as JSON objects with class "SUBFRAME". every subframe report object is carrying:

  • a "frame" field — the subframe number
  • a "tSV" field — the transmitting satellite number
  • a "TOW17" field — the 17 MSBs of the start of the next 12-second message ✨
  • a "scaled" field — tells you whether the rest of the fields are dumped in scaled or unscaled form
  • and a "device" field — names the data source, obviously 💅

on top of all that, each SUBFRAME object will have a sub-object specific to that subframe page type. those sub-object fields have names and types similar to the ones specified in the IS-GPS-200 document — like, each message field table can be read directly as a spec for the members of the corresponding JSON object type. iconic, honestly 🎀

Table 29. SUBFRAME object

  • class — Always? Yes — Type: string — Fixed: "SUBFRAME"
  • device — Always? Yes — Type: string — Name of the originating device.
  • frame — Always? No — Type: integer — Frame number
  • gnssId — Always? Yes — Type: integer — Constellation of transmitting satellite
  • scaled — Always? Yes — Type: boolean — True is values scaled
  • tSV — Always? Yes — Type: integer — ID of transmitting satellite (Not PRN)
  • TOW17 — Always? No — Type: integer — Type 17 bits of the next GPS Time Of Week
ngl bestie, clock that tSV note: that's the ID of the transmitting satellite, and it is Not the PRN. don't mix them up, i'm begging 🙈

🛰️ PRN, GNSS ID, SV ID, AND SIG ID 🛰️

okay bestie, buckle up, this one's a whole saga. this JSON refers to individual satellites by PRN, and by the combo of GNSS id and SV id.

⚠️ Beware, fr. What most people think of as the PRN is not the PRN that each constellation (GPS, GLONASS, BeiDou, etc.) uses in its own documentation. 💀

Each constellation numbers its PRNs starting from 1. GPS reserves all PRNs up to 1023. What most users think of as the PRN is what NMEA calls a PRN, which is not the native, standardized, PRN. NMEA PRNs started out as the GPS PRNs, but when other constellations became available, GNSS receiver vendors overloaded that NMEA field. Without standardizing, or coordinating, between themselves. 😭 Some receivers use different PRN mappings depending on runtime configuration. Don't expect any specificity in an NMEA PRN — there is no consensus meaning. it's giving chaos, no cap.

To leave this mess behind, receiver vendors now refer to each satellite by its constellation (GPS, GLONASS, etc.), and its PRN (starting at 1) within that constellation.

gpsd refers to each constellation by its gnssid, and each satellite within that constellation by its native PRN (svid). Of course there is no standardization, or consensus, on these ids, so gpsd decided on its own. These are loosely based on the u-blox usage:

Table 30. gnssid and svid table ✨

  • BeiDou — Abr BD — gnssid 3 — svid (native PRN) 1-37
  • Galileo — Abr GA — gnssid 2 — svid (native PRN) 1-36
  • GLONASS — Abr GL — gnssid 6 — svid (native PRN) 1-32, 255
  • GPS — Abr GP — gnssid 0 — svid (native PRN) 1-32
  • IMES — Abr IM — gnssid 4 — svid (native PRN) 1-10
  • NavIC (IRNSS) — Abr IR — gnssid 7 — svid (native PRN) 1-11
  • QZSS — Abr QZ — gnssid 5 — svid (native PRN) 1-7
  • SBAS — Abr SB — gnssid 1 — svid (native PRN) 120-158

and of course the story does not end there, because when does it ever 🫠. Modern satellites transmit on more than one band (L1, L2, L5, etc.) and using more than one signal modulation (C/a, CM, CL. P, etc.). So a GPS satellite (gnssid = 0), with a native PRN of 3 (svid = 3) may be transmitting on L2 and L5 using several modulations. Each of those may be reported individually by your receiver, by Signal ID (sigid) with its own data on Health, SNR, Used, etc.

If you have a multi band receiver, and really want to understand its sigids, then prepare to spend a lot of quality time with their documentation. 📚 As new receivers appear, with new bands and modulations, it is impossible to keep up. Here is a table of some sigids known to gpsd:

Table 31. sigid table 💅

  • BeiDou
    • sigid 0 — B1I D1
    • sigid 1 — B1I D2
    • sigid 2 — B2I D1
    • sigid 3 — B2I D2
    • sigid 7 — B2a
  • Galileo
    • sigid 0 — E1 C
    • sigid 1 — E1 B
    • sigid 3 — E5 aI
    • sigid 4 — E5 aQ
    • sigid 5 — E5 bl
    • sigid 6 — E5 bQ
  • GLONASS
    • sigid 0 — L1 OF
    • sigid 2 — L2 OF
  • GPS
    • sigid 0 — L1C/A
    • sigid 3 — L2 CL
    • sigid 4 — L2 CM
    • sigid 6 — L5 I
    • sigid 7 — L5 Q
  • IRNSS
    • sigid ?? — (no signal name listed)
  • QZSS
    • sigid 0 — L1C/A
    • sigid 4 — L2 CM
    • sigid 5 — L2 CL
  • SBAS
    • sigid 0 — L1C/A
    • sigid ? — L5I

📖 READING 📖

Reading the raw JSON can be tedious, ngl. You can pretty print, and colorize, your JSON with [jq] to make reading easier. Using jq to pretty print a JSON file can be as simple as:

$ jq .  GPSD.json

To grab 10 seconds of live gpsd JSON, and pretty print it:

$ gpspipe -w -x 10 | jq .

If you only want to see the TPV messages:

$ gpspipe -w -x 10 | fgrep TPV | jq .

like… look at that. three lines. iconic. 🎀

👀 SEE ALSO 👀

gpsd(8), libgps(3), libgpsmm(3), jq(1)

🌈 RESOURCES 🌈

go read the RFCs bestie, they're literally free 💜

💖 COPYING 💖

okay bestie, legal moment, but make it cute ✨

  • This file is Copyright by the GPSD project 🫶
  • SPDX-License-Identifier: BSD-2-clause — yep, that's the license, fr fr, no cap 💅

👑 AUTHOR 👑

the icon, the legend, the main character who literally wrote this whole thing:

Eric S. Raymond 🌟

and that's a wrap on the whole page, bestie 😭💖 you made it all the way through all 23 parts, which is genuinely iconic behavior. this was GPSD, Version 3.27.5, dated 2025-11-08, from the GPSD_JSON(5) manual page — go forth and parse some JSON, you absolute legend 🦋✨👑

📦 where this page comes from