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; extention 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 record 0x7f-03 has been corrected to include SBAS as a possible constellation, which had been accidentally left out

2009 Jul 16: record 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: record ID 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 the 0x00 metadata record 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; 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 record 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 record 0x00 and clarified use of field ID 0x01 when the source ID is 0x00 (i.e. when the 0x00 record 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 record 0x7d (receiver internal state)

2004 June 15: start of this BINEX specification log page

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

clarification of source ID > 0 in metadata record 0x00

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

link to Doug Hunt's library updated on BINEX homepage

Last modified Thursday, 10-Nov-2011 20:54:42 UTC