
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 0x7d: Receiver Internal State
Binary Exchange format for GPS/GLONASS/SBAS
Data/Metadata/Ephemerides/Orbits/Solutions
Index:
BINEX homepage
current BINEX Record 0x7d outline
current BINEX Record 0x7d Subrecord 0x00
Contact: UNAVCO data guru
Last modified: 23 Sept 2004
Record 0x7d Outline:
Record 0x7d = 125 serves as a test bed for working out the details of
ways of storing receiver internal state variables, including, for example, internal temperature.
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.
Record 0x7d Subrecord 0x00: 0x7d-00
This subrecord is being developed for receiver internal state variables, e.g. internal
temperature, power, and so on..
- the time resolution for each time tag is to the millisecond
- the types of valid observables present for the current epoch
- the observables themselves, stored in a variety of pre-specified resolutions
Note: All the multi-byte integer values used in 0x7d-00 (i.e.
uint2,
uint4,
mGFZI)
have an endian-ness specified by the sychronization/endian byte of the record.
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:
first uint1 for observable types:
- bit 0 = 1: receiver internal temperature
- bit 1 = 1: receiver primary external power supply voltage
- bit 2 = 1: receiver secondary external power supply voltage
- bit 3 = 1: receiver primary internal battery power supply voltage
- bit 4 = 1: receiver secondary internal battery power supply voltage
- bit 5 = 1: (reserved)
- bit 6 = 1: (reserved)
other uint1 for observable types:
Next follows the sequentially the data for this epoch, if the corresponding bit
above has been set = 1:
- 1 byte (sint1) value of receiver internal temperature °C (storing to nearest 1°C, range -128 to +127)
- 2 bytes (uint2) value of receiver primary external power voltage in millivolts (range 0 mV to 65535 mV))
- 2 bytes (uint2) value of receiver secondary external power voltage in millivolts (range 0 mV to 65535 mV))
- 2 bytes (uint2) value of receiver primary internal battery power voltage in millivolts (range 0 mV to 65535 mV))
- 2 bytes (uint2) value of receiver secondary internal battery power voltage in millivolts (range 0 mV to 65535 mV))
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 Friday, 21-Jul-2006 23:22:39 UTC
|