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 0x00: Site Metadata

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


Index:
BINEX homepage
current BINEX Record 0x00 outline
BINEX Record 0x00 metadata ordering

Contact: GAGE BINEX contact


Record 0x00 Outline:
Basically, BINEX record 0x00 = 0 will (eventually) encapsulate all pertinent information (i.e. metadata) about the site, monument, marker, reference point, and equipment setup for the collection of GPS, GLONASS, SBAS, and other GNSS type data and other possible site-related information like meteorological, geophysical, etc. equipment. For the most part, think of this as a superset of the header information in RINEX and the metadata in an IGS log.

Unlike the headers in RINEX, there are be no required field entries. If something is known, it should be included. If not known, it should be left out. Also, multiple records of ID = 0 would be allowed in a BINEX file. For example, there will be a field specifying the position of the reference point on the monument for which the GPS/GLONASS/SBAS data are being collected, corresponding (more or less) to the APPROX POSITION XYZ fields in a RINEX OBS file. If this is known, it should be included according to best available information. If a better position is found at a latter date after the file has been collected from the receiver, a new record ID = 0 using only the corrected fields is constructed and prepended to the beginning of the BINEX file. The information in the original record ID = 0 is not modified. See also BINEX record 0x00 metadata ordering.

Each record ID = 0 contains an initial date stamp: 4 bytes (uint4) = number of minutes since 6.0 Jan 1980, and 1 byte (uint1) = number of 0.25 seconds (values of 0x00 - 0xef only, 0xf0 - 0xff are excluded). (Note: This 5-byte time stamp takes the place of the 20-byte DATE field in RINEX.) Also, is a single byte (uint1) describing the source of the information. If metadata is from multiple sources, then distinct records with ID = 0 must be used for each source. For receiver-created source IDs (currently only 0x00 = 0), the receiver firmware can be specified using field ID 0x1b = 27 and there is no requirement to include a field ID 0x01 =1 unless there is added significance to a firmware name (if one exists) not implied by the firmware version; for software-created source IDs, the software can be specified using field ID 0x01 = 1.

  • source ID = 0x00 = 0: receiver firmware-created; from native receiver file or stream
  • source ID = 0x01 = 1: software-created from existing RINEX file(s)
  • source ID = 0x02 = 2: software-created from an IGS log file
  • source ID = 0x03 = 3: software-created from user-supplied information, e.g. via a configuration file
  • source ID = 0x04 = 4: software-created from existing non-BINEX and non-RINEX native receiver format file or stream
  • other values are currently reserved

After the 5-byte time stamp and the 1-byte source identifier 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
  • 1 byte; uint1 = additional 0.25 seconds
  • 1 byte; uint1 = source ID
  • 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 for record ID = 0:
  • 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: program or software package being used to create this BINEX record 0 (= PGM field in RINEX); only a single field ID = 1 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x02 = 2: program operator (= RUN BY field in RINEX); only a single field ID = 2 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x03 = 3: reserved for the geopolitical site location (country/state or province/city or town); only a single field ID = 3 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x04 = 4: site name/description (usually = MARKER NAME field in RINEX); only a single field ID = 4 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x05 = 5: site number; only a single field ID = 5 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x06 = 6: monument name/description/inscription; only a single field ID = 6 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x07 = 7: monument number (sometimes = MARKER NUMBER field in RINEX); only a single field ID = 7 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x08 = 8: marker name/description/inscription; only a single field ID = 8 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x09 = 9: marker number (sometimes = MARKER NUMBER field in RINEX); only a single field ID = 9 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x0a = 10: reference point name/description; only a single field ID = 10 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x0b = 11: reference point number (e.g. the IERS DOMES number) (sometimes = MARKER NUMBER field in RINEX); only a single field ID = 11 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x0c = 12: date established/installed for this particular site/monument/marker/reference point:
    • first subfield is the number of bytes in the ASCII date description
    • second subfield is the ASCII date description, where the preferred format is: "year-month-day hh:mm" in the Gregorian calendar and where the year should be a 4-digit year representation and the hour:minute entry is optional and, if used, should have a 24-hour entry; if the first field entry = 0, the second field is not present
    • third subfield is a sint2 representing the year in the normal 2's-complement signed integer representation, e.g. 1999 A.D. = 1999 = 0x07cf (negative values are reserved for monuments established B.C., e.g. 44 B.C. = -44 = 0xffd4, if needed); a value of 0 = 0x0000 is reserved to mean that the date is only available in the ASCII format of the second field
    • fourth subfield is a uint4 to represent the number of minutes into the year; if the third field has a value of 0, this field's value has no meaning
    only a single field ID = 12 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x0d = 13: reserved for the geologic and geophysical characteristics of the site, including the tectonic plate on which the site is located
  • field ID = 0x0e = 14: reserved for the climatic (gross meteorological) characteristics of the site
  • field ID = 0x0f = 15: 4-character ID that the operator is associating with this data and metadata; only a single field ID = 15 in each record 0x00 is allowed; field length bytes is required and is always = 0x04, so the 4 following ASCII characters must always include 4 printable characters (pad at end with 0x20 = ASCII space if length of string < 4 bytes)
  • field ID = 0x10 = 16: project name/description; only a single field ID = 16 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x11 = 17: principal investigator for this project (might = OBSERVER field in RINEX); multiple field ID = 17 in a single record are allowed, in case of multiple PIs; field length bytes required
  • field ID = 0x12 = 18: PI's agency/institution (might = observer AGENCY field in RINEX); multiple field ID = 18 in a single record are allowed, in case of multiple PIs, but must follow in the some order as the multiple PI fields; field length bytes required
  • field ID = 0x13 = 19: PI's contact information (address, telephone, FAX, email, etc. in any reasonable ASCII format); multiple field ID = 19 in a single record are allowed, in case of multiple PIs, but must follow in the some order as the multiple PI fields; field length bytes required
  • field ID = 0x14 = 20: site operator (probably = OBSERVER field in RINEX); only a single field ID = 20 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x15 = 21: site operator's agency/institution (probably = observer AGENCY field in RINEX); only a single field ID = 21 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x16 = 22: site operator's contact information (address, telephone, FAX, email, etc. in any reasonable ASCII format); only a single field ID = 22 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x17 = 23: antenna type (= antenna TYPE field in RINEX); designation should match that in the current IGS table for RINEX if possible; designation can either be the entire antenna type plus radome name, or, alternatively, the antenna type name deleting the radome designation, in which case the radome designation, if any, should be stored in field 0x20; only a single field ID = 23 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x18 = 24: antenna number (= antenna # field in RINEX); only a single field ID = 24 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x19 = 25: receiver type (= receiver TYPE field in RINEX); designation should match that in the current IGS table for RINEX if possible; only a single field ID = 25 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x1a = 26: receiver number (= receiver # field in RINEX); only a single field ID = 26 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x1b = 27: receiver firmware version (= receiver VERS field in RINEX); only a single field ID = 27 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x1c = 28: antenna mount description; only a single field ID = 28 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x1d = 29: antenna ECEF xyz position (partially = APPROX POSITION XYZ fields in RINEX):
    • first subfield is the number of bytes (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 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
    where the position is the best known for the reference point; only a single field ID = 29 in each record 0x00 is allowed; field length bytes required for ECEF/ellipsoid model description
  • field ID = 0x1e = 30: antenna geographic position:
    • first subfield is the number of bytes in the ECEF/ellipsoid model description (can be zero)
    • next subfield is the ECEF/ellipsoid model description (if not present, i.e. first field = 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
    where the position is the best known for the reference point; only a single field ID = 30 in each record 0x00 is allowed; field length bytes required for ECEF/ellipsoid model description
  • field ID = 0x1f = 31: antenna offset from reference point (= ANTENNA: DELTA H/E/N fields in RINEX); 3 8-byte fields are required:
    • 1st 8 bytes as a double precision number (real8) for offset of antenna ARP from reference point in height (meters)
    • 2nd 8 bytes as a double precision number (real8) for offset of antenna ARP from reference point in East-West direction (meters), (> 0 denotes East offset, < 0 denotes West offset)
    • 3rd 8 bytes as a double precision number (real8) for offset of antenna ARP from reference point in North-South direction (meters), (> 0 denotes North offset, < 0 denotes South offset)
    only a single field ID = 31 in each record 0x00 is allowed;
  • field ID = 0x20 = 32: antenna radome type (= antenna radome TYPE field in RINEX, deleting any antenna designation); designation should match that in the current IGS table for RINEX if possible; only a single field ID = 32 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x21 = 33: antenna radome number; only a single field ID = 33 in each record 0x00 is allowed; field length bytes required
  • field ID = 0x22 = 34: geocode; only a single field ID = 34 in each record 0x00 is allowed; field length bytes required (an even number of bytes should be used)
  • etc. (to be defined, probably starting with the other metadata in RINEX OBS and RINEX MET files, IGS logs, and so on)

RINEX header lines that have yet to be incorporated into BINEX record 0:

  • SENSOR MOD/TYPE/ACC
  • SENSOR POS XYZ/H
Values for the RINEX header lines that will not be part of BINEX record 0 (since these are not metadata for the site) and will be obtainable (either explicitly or implicitly) from other BINEX records:
  • RINEX VERSION / TYPE (no RINEX ID in BINEX, "type" implied by BINEX record ID)
  • WAVELENGTH FACT L1/2
  • # / TYPES OF OBSERV
  • INTERVAL
  • RCV CLOCK OFFS APPL
  • TIME OF FIRST OBS
  • TIME OF LAST OBS
  • LEAP SECONDS
  • # OF SATELLITES
  • PRN / # OF OBS
  • ION ALPHA (will probably be part of a BINEX 0x01 subrecord)
  • ION BETA (will probably be part of a BINEX 0x01 subrecord)
  • DELTA-UTC: A0,A1,T,W (will probably be part of a BINEX 0x01 subrecord)
  • CORR TO SYSTEM TIME (will probably be part of a BINEX 0x01 subrecord)

This BINEX record 0x00 outline should not be intepreted as complete and/or finalized, but rather to show how the general philosophy of BINEX would be applied in the implementation.

BINEX record 0x00 metadata ordering:
The metadata in BINEX records 0x00 should not be overwritten. Rather, additional records 0x00 should be written to correct metadata or update it.

As an example, consider a receiver that directly outputs BINEX records, including periodic 0x00 records at some interval. Each of these records 0x00 from the receiver has metadata for fields A, B, and C, and have been output at times time 1 < time 2 < time 3 etc.: 

       [0x00 ABC, time 1].......
       [0x00 ABC, time 2].......
       [0x00 ABC, time 3].......
(Imagine that one of the ABC fields, say, A, might be the antenna position, and that the receiver is moving and outputting its location at some periodic time interval.) The records are collected and a file saved starting with [0x00 ABC, time 1].

At a later time 4, an additional record 0x00 is created and prepended to the beginning of the file with the fields X, Y, Z, and B: 

       [0x00 XYZB, time 4]
       [0x00 ABC, time 1].......
       [0x00 ABC, time 2].......
       [0x00 ABC, time 3].......
and then at a later time still at time 5, an additional record 0x00 is created and prepended to the beginning of this file with the fields U, X, and C: 
       [0x00 UXC, time 5]
       [0x00 XYZB, time 4]
       [0x00 ABC, time 1].......
       [0x00 ABC, time 2].......
       [0x00 ABC, time 3].......
The order in which metadata should be interpreted to be applied to the rest of the BINEX file is:
  • fields UXC at time 5: for the entire file
  • fields YZB at time 4: from record [0x00, time 4] through the rest of the file
  • field A at time 1: from record [0x00, time 1] to record [0x00, time 2]
  • field A at time 2: from record [0x00, time 2] to record [0x00, time 3]
  • field A at time 3: from record [0x00, time 3] to ...

In this way, 0x00 metadata in a file (or data stream) is considered valid from the point at which it is encountered in the file/data stream until it is superceded by an equivalent metadata field later in the file/data stream in a record 0x00 with a later time value. But additionally, the file or data stream retains a history of all past attempts to establish various parts of the metadata. (The only exception of this rule is for comments, which are accepted as equally valid in a BINEX file or data stream from the point at which it occurs on.)

 

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