UNAVCO Logo
 
 
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 0x7e: Ancillary Site Data Prototyping

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


Index:
BINEX homepage
current BINEX Record 0x7e outline
current BINEX Record 0x7e Subrecord 0x00
current BINEX Record 0x7e Subrecord 0x01

Contact: UNAVCO data guru


Record 0x7e Outline:
Record 0x7e = 126 serves as a test bed for working out the details of new ways of storing ancillary site data, including, for example, site meteorological (MET) data. After extensive testing, successful candidates might be upgraded to become standard subrecords of record 0x03 = 3.

Once the BINEX file or stream has been parsed and a record ID = 0x7e has been identified, the user should consult this page for decoding information of the record 0x7e message. For all 0x7e 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 0x7e Subrecord 0x00: 0x7e-00
This subrecord is being developed for holding ancillary site data, e.g. site meteorological data (pressure, temperature, humidity, etc.), local geophysical data (tilt, strain, etc.), and so on. The subrecord has:
  • 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 0x7e-00 (i.e. uint2, uint4, mGFZI) have an endian-ness specified by the sychronization/endian byte of the record.

The first byte of the 0x7e-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, representing the time of the data returned from the device. 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: atmospheric pressure
    • bit 1 = 1: atmospheric temperature
    • bit 2 = 1: atmospheric relative humidity
    • bit 3 = 1: wind speed
    • bit 4 = 1: wind direction
    • bit 5 = 1: rain increment
    • bit 6 = 1: hail increment
    • bit 7 = 1: read next uint1 for more observable types
    second uint1 for observable types:
    • bit 0 = 1: atmospheric integrated zenith dry delay
    • bit 1 = 1: atmospheric integrated zenith wet (water) delay
    • bit 2 = 1: atmospheric integrated zenith total delay
    • bit 3 = 1: site tilt in north direction
    • bit 4 = 1: site tilt in east direction
    • bit 5 = 1: site tilt sensor temperature
    • bit 6 = 1: wind gust speed
    • bit 7 = 1: read next uint1 for more observable types
    third uint1 for observable types:
    • (reserved)

Next follows the sequentially the data for this epoch, if the corresponding bit above has been set = 1:

  • 1-8 bytes (mGFZI) value of 1000xatmospheric pressure in millibars (storing to nearest 0.001 mbar)
  • 1-8 bytes (mGFZI) value of 100xatmospheric temperature in °C (storing to nearest 0.01 °C)
  • 1-8 bytes (mGFZI) value of 10xatmospheric relative humidity in % (storing to nearest 0.1 %)
  • 1-8 bytes (mGFZI) value of 100xwind speed in m/s (storing to nearest 0.01 m/s)
  • 1-8 bytes (mGFZI) value of 100xwind gust speed in m/s (storing to nearest 0.01 m/s)
  • 1-8 bytes (mGFZI) value of 10xwind direction in degrees (storing to nearest 0.1°)
  • direction from where the wind blows, and is measured clockwise from geographic north
  • 1-8 bytes (mGFZI) value of rain increment in 1/100 mm (storing to nearest 10 µm)
  • accumulation since last scheduled measurement
  • 1-8 bytes (mGFZI) value of hail increment in mm (storing to nearest mm)
  • accumulation since last scheduled measurement
  • 1-8 bytes (mGFZI) value of 10xatmospheric integrated zenith dry delay in mm (storing to nearest 0.1 mm)
  • 1-8 bytes (mGFZI) value of 10xatmospheric integrated zenith wet delay in mm (storing to nearest 0.1 mm)
  • 1-8 bytes (mGFZI) value of 10xatmospheric integrated zenith total delay in mm (storing to nearest 0.1 mm)
  • 1-8 bytes (mGFZI) value of 1000xsite tilt in north direction in degrees (storing to nearest 0.001 degree; tilt to north is positive, tilt to south is negative)
  • 1-8 bytes (mGFZI) value of 1000xsite tilt in east direction in degrees (storing to nearest 0.001 degree; tilt to east is positive, tilt to west is negative)
  • 1-8 bytes (mGFZI) value of 10xsite tilt sensor temperature in °C (storing to nearest 0.1° C)
where mGFZI refers to the "modified GFZ" method of storing integer values in 1 to 8 bytes (see mGFZI explanation).

If the data type bit is not set for a specific observable, then all the associated mGFZI bytes are simply not present in the record at all. For example, if the uint1 byte is set to 0x05, then only data for atmospheric pressure and relative humidity are present.



Record 0x7e Subrecord 0x01: 0x7e-01
This subrecord is being developed for holding raw ASCII strings returned from external devices, such as NMEA strings from meteorological unit. The string is the raw string returned from the device, minus any end-of-string or line-termination characters. The subrecord has:
  • the time resolution for each time tag is to the millisecond
  • the number of bytes in the string
  • the string itself

Note: All the multi-byte integer values used in 0x7e-01 (i.e. uint2, uint4, ubnxi) have an endian-ness specified by the sychronization/endian byte of the record.

The first byte of the 0x7e-01 message will be the byte 0x01, denoting the subrecord 0x01.

Immediately following the subrecord 0x01 byte with be 6 bytes representing the time tag, representing the time of the data returned from the device. 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 single ubnxi which specifies the length of the ASCII string in bytes.

Immediately following the bytes for the ubnxi are the ASCII string bytes. End-of-string or end-of-line characters such as null (0x00), carriage return (0x0d), and line feed (0x0a) can and should be eliminated to reduce payload size since these do not contain information. However, 0x00, 0x0d, and/or 0x0a might be part of a binary checksum at the end of the string returned from a device and in this context these characters are useful and should be stored.

The BINEX record 0x7e outline for each subrecord on this page should be interpreted 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: Monday, 29-Feb-2016 15:36:43 UTC