UNAVCO Home UNAVCO Home
   |    |   |  
UNAVCO Home UNAVCO Facility

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 0x7d Record ID 0x7e Record ID 0x7f Log
BINEX Record 0x01: GNSS Navigation Information

Binary Exchange format for GPS/GLONASS/SBAS
Data/Metadata/Ephemerides/Orbits/Solutions


Index:
BINEX homepage
current BINEX Record 0x01 outline

Contact: UNAVCO data guru
Last modified: 21 July 2004



Record 0x01 Outline:
Each record 0x01 = 1 holds GNSS navigation information for a specific satellite. The format depends on the specific subrecord value. Depending on the subrecord, the navigaition information may correspond to the binary broadcast messeage, a decoded version of the message analogous to what would appear in a RINEX NAV file, or other orbit formats such as SP3, and so on.

Once the BINEX file or stream has been parsed and a record ID = 0x01 has been identified, the user should consult this page for decoding information of the record 0x01 message. For all 0x01 record messages, the first 1-4 bytes of the message should be examined to determine the subrecord ID. The C/C++ function read_ubnxi() can be used to do this. Once the subrecord ID has been determined, consult the appropriate subrecord description.


Record 0x01 Subrecord 0x00: 0x01-00
The first byte of the 0x01-00 message will be the byte 0x00, denoting the subrecord 0x00. Subrecord 0x00 requires that the satellite number being stored is in the range of 1-32.

Immediately following the subrecord 0x01 byte will be a byte specifying the satellite ID. (See details on decoding.) The interpretation of the rest of the record message depends on which satellite system is specified in the satellite ID byte.

Following the SVid1 byte, the contents depend on the specific satellite system:

  • for GPS:
    • uint1, containing:
      • bit 0: information from subframe 4, page 25 available = uint1 & 0x01; if bit 0 = 1 and this indicates that bits 1-4 have the assigned meaning defined below; if the information is not available, bit 0 = 0 and the meaning of bits 1-4 are currently undefined
      • bits 1-3: 3-bit "SV configuration" (whether SV is Block I or II, from subframe 4, page 25) = uint1 >> 1 & 0x03
      • bit 4: 1-bit anti-spoof flag/y-code on (from subframe 4, page 25) = uint1 >> 4 & 0x01
      • bit 5: ToW in the next sint4 is valid = uint1 >> 5 & 0x01; if bit 5 = 1, the ToW is valid; if bit 5 = 0, the ToW is unknown
      • (upper 2 bits, 6-7, of this uint1 are reserved)
    • sint4 = ToW (time of week/time of message), in seconds, if it is known (also, bit 5 in the uint1 above should be set equal to 1); otherwise, set this sint4 equal to 0 (also, bit 5 in the uint1 above should be set equal to 0)
    • 72 bytes: The rest of the message for GPS will be the 72 bytes from GPS ephemeris subframes 1, 2, and 3, words 3-10, minus the 6 parity bits per each word, representing the encoded GPS navigation message, ordered in the same way as the subframes 1-3 and words 3-10. The MSB (bit 7) of the first byte of the rest of the message of subrecord 0x00 therefore corresponds to "Bit 61" of subframe 1 (the MSB of the 10-bit GPS week number), and so on. See the ICD-GPS-200 for details on decoding. No byte-swapping occurs in these 72 bytes of 0x01-00, regardless of the endian-ness of the synchronization/endian byte fo the record.
  • for GLONASS:
  • For the GLONASS system, the rest of the message will be the corresponding bytes from the GLONASS navigation message. Further details are unspecified at this time.


Record 0x01 Subrecord 0x01: 0x01-01
The first byte of the 0x01-01 message will be the byte 0x01, denoting the subrecord 0x01. Subrecord 0x01 requires that the satellite number being stored is in the range of 1-32. For the NAVSTAR GPS navigation message, the ToE value must be equal to the ToC value (which has been the case for all valid GPS navigation messages for years).

Immediately following the subrecord 0x01 byte will be a byte specifying the satellite ID. (See details on decoding.) The interpretation of the rest of the record message depends on which satellite system is specified in the satellite ID byte.

For the GPS system, the rest of the message will be sequentially:

  • uint2 = GPS week (or whole weeks completed since 6.0 Jan 1980, the same as specified in RINEX 2.10, e.g. week starting 22 Aug 1999 = GPS week 1024), i.e. the 10-bit "week number" in the broadcast subframe no.1 = GPS week (as defined here) modulus 1024
  • sint4 = ToW (time of week/time of message), in seconds
  • sint4 = ToC (time of clock) = ToE (time of ephemeris), in seconds
  • real4 = TGD, in seconds
  • sint4 = IODC (issue of data, clock)
  • real4 = af2, SV clock drift rate, in second/second^2
  • real4 = af1, SV clock drift, in second/second
  • real4 = af0, SV clock bias, in seconds
  • sint4 = IODE (issue of data, ephemeris)
  • real4 = delta n, in semicircles/second (multiply by 3.1415926535898 to obtain radians/second)
  • real8 = M0, mean anomaly at reference time, in radians
  • real8 = e, eccentricity
  • real8 = sqrt a, square root of semi-major axis, in meters^0.5
  • real4 = Cic pertubation harmonic, in radians
  • real4 = Crc pertubation harmonic, in meters
  • real4 = Cis pertubation harmonic, in radians
  • real4 = Crs pertubation harmonic, in meters
  • real4 = Cuc pertubation harmonic, in radians
  • real4 = Cus pertubation harmonic, in radians
  • real8 = OMEGA0, lon. of asc. node, in radians
  • real8 = omega, arg. of perigee, in radians
  • real8 = i0, inclination at reference time, in radians
  • real4 = OMEGA dot, rate of right asc., in semicirles/second (multiply by 3.1415926535898 to obtain radians/second)
  • real4 = i dot, rate of inclination, in semicirles/second (multiply by 3.1415926535898 to obtain radians/second)
  • real4 = nominal URA (user range accuracy) value, in decimeters (multiply by 0.1 to obtain meters), rounded to the nearest decimeter (see ICD-GPS-200 20.3.3.3.1.3); if the URA index X = 15, then a value of 327670 decimeters should be stored for the nominal URA value, consistent with the convention used in RINEX
  • uint2 to hold the SV health coded value:
    • 6-bit SV health (coded) = bits 0-5 = uint2 & 0x003f
    • (upper 10 bits, 6-15, of this uint2 are reserved)
  • uint2 to hold three remaining pieces derived from the GPS navigation message in subframes 1-3:
    • curve fit interval, hours = bits 0-7 = uint2 & 0x00ff (value to be derived from the 1-bit fit interval flag and the value of the IODC; see ICD-GPS-200 Table 20-XII for details)
    • 1-bit L2 P data flag = bit 8 = uint2 >> 8 & 0x01, if available (if not available, always set bit 8 = 0)
    • 2-bit codes on L2 channel = bits 9-10 = uint2 >> 9 & 0x03, if available (if not available, always set bits 9,10 = 0)
    • (upper 5 bits, 11-15, of this uint2 are reserved)

For the GLONASS system, the definition of rest of the message is under consideration at this time.

The BINEX record 0x01 outline for each subrecord on this page should be intepreted as complete and finalized. Since other subrecords may be specified in the future, all other subrecord IDs not explicitly specified on this page are currently reserved.

Last modified Friday, 21-Jul-2006 23:21:07 UTC

 

Home | About Us | Contact Us | Support | Search | Facility | PBO | Education & Outreach

Comments: webmasterATunavco.org
© 2008 UNAVCO, Inc.