current BINEX Record 0x7d outline
current BINEX Record 0x7d Subrecord 0x00
Contact: GAGE BINEX contact
Once the BINEX file or stream has been parsed and a record ID = 0x7d has been identified, the user should consult this page for decoding information of the record 0x7d message. For all 0x7d 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.
The first byte of the 0x7d-00 message will be the byte 0x00, denoting the subrecord 0x00.
Immediately following the subrecord 0x00 byte with be 6 bytes representing the time tag. The first 4 bytes (uint4) are the number of minutes since 6.0 Jan 1980. The next 2 bytes (uint2) are additional number of milliseconds needed to complete the time tag for the epoch.
Immediately following the 6 time tag bytes will be one or more single bytes (uint1) which specify the types of observables for the current epoch. The highest bit (bit 7) in each of these bytes is reserved, and, if set, indicates that another single byte of observable types is to follow. The last single byte of observable types must have bit 7 = 0. Currently, the defined observables are:
Next follows the sequentially the data for this epoch, if the corresponding bit above has been set = 1:
If the data type bit is not set for a specific observable, then all the associated sint1 or uint2 bytes are simply not present in the record at all. For example, if the uint1 byte is set to 0x03, then only data for the receiver internal temperature and primary external power supply voltage are present.
The BINEX record 0x7d 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: 2023-05-12 13:21:28 America/Denver