
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
|