Data Help with Data GPS/GNSS Data Data Formats BINEX Record structure Synchronization Record ID bytes Record message length Record message Record checksum/CRC Reverse record length Time stamps Proposed records Current records Forward parsing Conventions Record ID 0x00 Record ID 0x01 Record ID 0x05 Record ID 0x7d Record ID 0x7e Record ID 0x7f Log


Binary Exchange format for GPS/GNSS

Last modified: 13 Jul 2018

2018 Jul 13: new 0x01-14 — an upgraded decoded Galileo navigation message — (to replace the original 0x01-04) in record 0x01

2018 Jul 13: expanded Observation Code IDs for 0x7f-05 for Beidou B1C and B2a signals (as outlined in the Aug 2017 Beidou ICD) in record 0x7f

2017 Feb 15: clarification of the week value, ToW, ToE, and ToC (where used) in record 0x01 for subrecords 0x01 (GPS) — 0x07 (IRNSS)

2016 Dec 2: record IDs 0xc0 to 0xc3 assigned to CU Boulder

2016 Aug 17: specification of the sign convention for the receiver clock bias and clock drift in record 0x05 for field IDs 6 and 7

2016 Aug 12: definition of several fields in 0x01-03 for the decoded SBAS ephemeris clarified:

  • ToW is respecified as an sint4 (rather than a uint4) with appropriate ±604800 second adjustment to refer to specified GPS week
  • the real4 after the real8 for aGf0 is now to be used for aGf1 (SV clock drift)
  • the uint4 after the real4 for aGf1 is clarified to be the time of ephemeris (ToE) equal to the time of clock (ToC)
  • the uint1 for health is clarified to be identical to the health value for SBAS in RINEX 2.11, using bits 0-5
  • the uint1 for the user accuracy is clarified to be the 4 bits of the user range accuracy index, using bits 0-3

2016 Jun 10: proposed 0x00 field IDs 0x23 (35) to 0x27 (39) for antenna velocity, receiver time system, and receiver clock bias and drift instead put into proposed Record 0x05 for processed results, along with corresponding antenna position solution field IDs 0x01 and 0x02; note that 0x05 allows time stamps to millisecond resolution and requires processed solution results, i.e. not user-specified parameters

2016 Jun 8: (proposed) addition of 0x00 field IDs 0x23 (35) to 0x27 (39) for antenna velocity, receiver time system, and receiver clock bias and drift

2016 May 4: (proposed) addition of 0x01-41 to 0x01-47 continues to evolve after discussions with UCAR/COSMIC

2016 Apr 22: clarification of the extraction and bit 6 of the two-bit Flags in the N SVs + Flags byte in 0x7f-05

2016 Apr 22: added Note 3 and Note 4 in ObsFlags description and various other minor wording changes for ObsFlags() in 0x7f-05

2016 Apr 20: description of bit 7 of the Observation Code uint1 in 0x7f-05 made more clear

2016 Apr 19: clarification in 0x7f-05 description of ObsFlags(0) that ObsFlags(0), like ObsFlags(1)ObsFlags(3), is optional

2016 Feb 29: (proposed) addition of 0x01-41 to 0x01-47 for navigation subframe/block/string/page bits for GPS, GLONASS, SBAS, Galileo, Beidou, QZSS, and IRNSS; see also general notes for all subrecords 0x41 - 0x47

2016 Feb 29: correction of subrecord ID field description for all 0x01 subrecords, i.e. these should all be ubnxi, although since all subrecord IDs to date are < 128, all write functions are ok using uint1, but all read functions should properly use ubnxi to detect possible subrecord IDs >= 128 in the future

2016 Feb 29: (proposed) addition of 0x7e-01 to hold ASCII strings from external devices, such as NMEA strings from a meteorological unit

2016 Jan 26: (proposed) addition of 0x01-07 for an IRNSS navigation message and (proposed) expansion of 0x7f-05 to include IRNSS observables with new system ID = 6 for IRNSS

2016 Jan 12: slight expansion of the "slot # - 1" field in 0x01-02 for a GLONASS navigation message so that it can cover the case of an SV in flight test mode and be represented with an "unknown" value of 255 (0xff)

2014 Jun 23: clarification of the enhanced CRC structure in the Generalized Record Structure

2013 Apr 12: 0x7e extended to include wind gust speed

2013 Apr 8: the provisional status of 0x01-05 (Beidou-2/Compass nav message) has been removed

2012 Aug 30: the provisional status of 0x01-04 (Galileo nav message) has been removed

2012 July 19: slight change to the definition of 2cNb so that -2^(N-1) is reseverd to indicate an invalid or unknown value; ranges of all values in various 0x7f subrecords using 2cNb have been updated to reflect this change

2012 May 23: definition of A0 in 0x01-02 clarified (note: no change in the original intent, which was to store the a0 = TauGPS value defined in RINEX 3.00 for TIME SYSTEM CORR for the GLGP = GPS time - GLONASS time, in seconds, i.e. the value to be added to GLONASS time to convert to GPS time)

2012 May 15: 0x7f-05 has been extended to include the QZSS L1-SAIF signal, though the proposal is to use the same PRN range as the other main signals of the SV, i.e. QZSS L1-SAIF PRN 183 observables are stored with the other observables with a PRN of 193

2012 May 15: the Galileo ToW field of 0x01-04 has been clarified (essentially to match that of the GPS ToW in 0x01-01) and Galileo SISA field of 0x01-04 has been extended to allow saving the SISA index of 0-255 as -(SISA index + 1) in the 'SISA' field

2012 Mar 5: the carrier frequency of a possible (though still unobserved) Beidou-2/Compass B1-2 signal has been changed to be 1589.742 MHz (rather than 1589.74 MHz), and provisional I/Q components assigned based on information in Inside GNSS, News Update, Sept/Oct 2008.

2012 Mar 2: the observation code IDs in 0x7f-05 have been extended for GLONASS G3 and for Beidou-2/Compass signals

2012 Feb 15: in 0x01-06, a clarification of the uint1 storing the QZSS ID (full PRN, 193-202, is stored) and stating that bits 1-15 of the last uint2 are reserved

2012 Feb 10: in 0x01-02, the uint1 storing the GLONASS ID was corrected to be the slot # - 1 (rather than just the slot #)

2011 Nov 10: in 0x01-02, clarification of health from MSB of ephemeris Bn and expansion to include SV operability based on Cn of almanac (i.e. SV "operability" is MSB of Bn = 0 and Cn = 1)

2011 Aug 3: in 0x7f-05, clarification of value of bit flags 2-6 of any ObsFlags() byte that is not present (see note #2), and addition of GLONASS-FDMA frequency channel number to ObsFlags(2)

2011 Mar 18: clarification in 0x01-01 of GPS week, ToW, and ToC (== ToE) fields; the previous writeup did not make it clear that the GPS week was for the ToC — the same as for RINEX — and some implementations (e.g. Trimble firmware up to this point) were setting the GPS week to the ToW value, which would, generally speaking, result in an incorrect GPS week value for GPS nav messages transmitted in the last few (usually two) hours of the GPS week (and given that the documentation problem and the GPS week value from Trimble-produced 0x01-01 has gone undetected for 10 years implies this error has not seriously impacted users)

2011 Mar 1: at the request of Javad, 0x7f-03 was extended to allow recording of the most available signals from Galileo, QZSS, and Beidou/Compass; also clarified the signals for GLONASS and SBAS in 0x7f-03

2011 Feb 24: corrected QZSS L2 carrier frequency as 1227.60 MHz (not 1277.60 MHz)

2011 Feb 22: specification of 0x7f-05 on-line

approved extension of 0x01 and 0x7f-05 for QZSS

extension of 0x01 for GLONASS and SBAS

proposed extension of 0x01 for Galileo

reserved extension of 0x01 for Beidou/Compass

2010 Dec 22: definition of the 1-byte satellite ID extended to include Galileo (PRN #s 1-32 only), Beidou-2/Compass (up to 32 PRN values), and QZSS (PRN #s 193-202)

2010 Dec 14: documentation for 0x7f-03 has been corrected to include SBAS as a possible constellation, which had been accidentally left out

2009 Jul 16: 0x7e has been extended to include site tilt in the north and east directions and the temperature of the site tilt sensor

2008 Dec 3: the design of the "enhanced CRC" BINEX records has been defined, and includes an XOR of the 1-4 bytes of the message length immediatedly after the 1-4 bytes of the message length (Jim Johnson and Doug Hunt of UCAR are credited with this final part of the design)

2007 Oct 23: the definitions of 2cNb and uNb were altered slightly for clarification

2007 Jun 20: 0x7e modified for including met observables from Vaisala WXT510 met pack: wind speed and direction, increments of rain and hail accumulation

2006 Feb 6: record IDs 0xb4 – 0xb7 have been reserved for IGS GNSS development by NRCan

2005 Jun 1: clarification that field ID 0x0f of 0x00 includes a leading field length ubnxi = 0x04

2005 Jan 19: clarification of L1 and L2 byte-fields in 0x7f-03

2004 Sept 23: clarification of 0x7d-00 that observables for bits 1 and 2 are for external voltages; also added cases for internal battery voltages in 0x7d-00

2004 Sept 15: clarification of 0x7f-03 Obs2 meaning of "coarse" pseudorange is L2C on L2

2004 Sept 13: draft specification of 0x7f-03 and 0x7f-04 on-line

clarification of receiver channel number for 0x7f subrecords, i.e. BINEX receiver channel number indexing should always start at 0 whether the internal receiver channel number indexing starts at 1 or 0; use a BINEX receiver channel number of 0 for all SVs for any receiver that does not have an internal channel numbering scheme

2004 Aug 23: slight modification of field ID 0x17 to 0x00 to allow for antenna plus radome designation (if, for some reason, radome designation cannot be split off to separate field ID 0x20)

2004 Aug 19: added source ID 0x04 to 0x00 and clarified use of field ID 0x01 when the source ID is 0x00 (i.e. when 0x00 is receiver firmware created)

2004 July 26: allowing JPL Soc format and IGS RTigs formats to be converted to 0x7f-00 and 0x7f-02; SNR storage in both is assumed to be in dBHz, allowing resolution of 0.25 dBHz

2004 July 21: addition of 0x7d (receiver internal state)

2004 Jun 15: start of this BINEX specification log page

added field ID 0x22 = 34 in 0x00, defined to be the GHAM alphanumeric geocode

clarification of source ID > 0 in 0x00

clarification that the field ID and length (if needed) for each field in 0x00 is a 1-4 byte ubnxi

link to Doug Hunt's library updated on BINEX homepage


Last modified: 2021-02-09  11:04:56  America/Denver