Data Help with Data GPS/GNSS Data Data Formats 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 0x05 Record ID 0x7d Record ID 0x7e Record ID 0x7f Log

BINEX Record 0x05: Processed Results

Binary Exchange format for GPS/GNSS
Data/Metadata/Ephemerides/Orbits/Solutions


Index:
BINEX homepage
current BINEX Record 0x05 outline

Contact: GAGE BINEX contact


Record 0x05 Outline:

Basically, BINEX record 0x05 = 5 will encapsulate pertinent information processed results, such as the antenna position solution, antenna velocity solution, the receiver time system, the receiver clock bias and drift, various dilution of precision estimates, and so on.

Each record ID = 5 contains an initial date stamp: 4 bytes (uint4) = number of minutes since 6.0 Jan 1980, and 2 byte (uint2) = number of milliseconds (values of of 0x0000 - 0xea5f only, 0xea60 - 0xffff are excluded).

After the 6-byte time stamp follow the field ID byte(s), and if that particular field ID corresponds to a character string, the next 1-4 bytes represent the number of bytes in the character string. Both use the same algorithm as the record ID and the record length. Then the bytes for that particular field follow. The sequence of field ID bytes, length bytes if a character string field, and the actual field bytes are repeated until the record 0 is complete:

  • 4 bytes; uint4 = minutes since 6.0 Jan 1980
  • 2 byte; uint2 = additional miiliseconds (0 - 59999)
  • in general, repeat as needed (though the details may vary depending on the specific field ID):
    • 1-4 bytes; ubnxi = field ID bytes
    • [1-4 bytes; ubnxi = field length in bytes] (only included if the field ID is of a variable length, e.g. for an arbitrary length character string)
    • n bytes; field value(s)
Some of the field IDs proposed for record ID = 5:
  • field ID = 0x00 = 0: comment; multiple field ID = 0 in a single record are allowed; repeat as needed; field length bytes required for each
  • field ID = 0x7f = 127: notes/additional information; multiple field ID = 127 in a single record are allowed; repeat as needed; field length bytes required for each; a field ID = 127 can follow any of the remainder fields and should be interpreted as notes or additional information concerning the field that it follows, e.g. a field ID = 127 following a field ID = 4 would be interpreted as being additional information concerning the site description/identification
  • field ID = 0x01 = 1: antenna ECEF xyz position at this epoch:
    • first subfield is the number of bytes, as a ubnxi, in the ECEF/ellipsoid model description (ubnxi value can equal zero = 0x00)
    • next subfield is the ECEF/ellipsoid model description (if not present, i.e. first ubnxi subfield = 0, then WGS84 model is assumed)
    • next subfield 8 bytes as a double precision number (real8) for ECEF x position in meters
    • next subfield 8 bytes as a double precision number (real8) for ECEF y position in meters
    • next subfield 8 bytes as a double precision number (real8) for ECEF z position in meters
    field length bytes required for ECEF/ellipsoid model description
  • field ID = 0x02 = 2: antenna geodetic position at this epoch:
    • first subfield is the number of bytes, as a ubnxi, in the ECEF/ellipsoid model description (ubnxi value can equal zero = 0x00)
    • next subfield is the ECEF/ellipsoid model description (if not present, i.e. first ubnxi subfield = 0, then WGS84 model is assumed)
    • next subfield 8 bytes as a double precision number (real8) for longitude position in decimal degrees (> 0 denotes East longitude, < 0 denotes West longitude)
    • next subfield 8 bytes as a double precision number (real8) for latitude position in decimal degrees (> 0 denotes North latitude, < 0 denotes South latitude)
    • next subfield 8 bytes as a double precision number (real8) for elevation position in meters
    field length bytes required for ECEF/ellipsoid model description
  • field ID = 0x03 = 3: antenna ECEF xyz velocity at this epoch:
    • 1st 8 bytes as a double precision number (real8) for velocity in ECEF x-direction (meters/second)
    • 2nd 8 bytes as a double precision number (real8) for velocity in ECEF y-direction (meters/second)
    • 3rd 8 bytes as a double precision number (real8) for velocity in ECEF z-direction (meters/second)
    where the ECEF/ellipsoid model is assumed to be the same as in field ID 0x01 (1) or 0x02 (2) used in the current or an earlier 0x05 record
  • field ID = 0x04 = 4: antenna local geodetic velocity at this epoch:
    • 1st 8 bytes as a double precision number (real8) for velocity in North-direction (meters/second); > 0 denotes Northern velocity, < 0 denotes Southern velocity
    • 2nd 8 bytes as a double precision number (real8) for velocity in East-direction (meters/second); > 0 denotes Eastern velocity, < 0 denotes Western velocity
    • 3rd 8 bytes as a double precision number (real8) for velocity in vertical-direction (meters/second); > 0 denotes upwards velocity, < 0 denotes downwards velocity
    where the ECEF/ellipsoid model is assumed to be the same as in field ID 0x01 (1) or 0x02 (2) used in the current or an earlier 0x05 record
  • field ID = 0x05 = 5: receiver time system, a single uint1:
    • 0 = GPS time
    • 1 = Galileo time
    • 2 = GLONASS time
    • 3 = Beidou time
    • 4-255 are reserved
    if no field ID 0x05 is present, then GPS time system is assumed by default
  • field ID = 0x06 = 6: receiver clock bias (offset) relative to the system time (see field ID 0x05) at this epoch:
    • 8 bytes for receiver clock bias as real8 in seconds, receiver clock bias is positive when the receiver time is ahead of the system time
    use field ID 0x06 in place of field ID 0x07 if receiver clock drift is not known
  • field ID = 0x07 = 7: receiver clock bias (offset) and drift relative to the system time (see field ID 0x05) at this epoch:
    • first 8 bytes for receiver clock bias as real8 in seconds, receiver clock bias is positive when the receiver time is ahead of the system time
    • next 4 bytes for receiver clock drift as real4 in parts per million (ppm), receiver clock drift is positive when the receiver clock runs too fast compared to system time
    use field ID 0x07 in place of field ID 0x06 if receiver clock drift is known
  • etc. (to be defined, dilution of precision parameters, ...)

This BINEX record 0x05 outline should not be intepreted as complete and/or finalized in regard to field IDs not yet specified.

 

Last modified: 2023-05-12  13:21:20  America/Denver