UNAVCO Home UNAVCO Home
   |    |   |  
UNAVCO Home UNAVCO Facility

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 0x7f: GNSS Observable Prototyping

Binary Exchange format for GPS/GLONASS/SBAS
Data/Metadata/Ephemerides/Orbits/Solutions


Index:
BINEX homepage
current BINEX Record 0x7f outline
current BINEX Record 0x7f Subrecord 0x00
current BINEX Record 0x7f Subrecord 0x01
current BINEX Record 0x7f Subrecord 0x02
current BINEX Record 0x7f Subrecord 0x03
current BINEX Record 0x7f Subrecord 0x04

Contact: UNAVCO data guru
Last modified: 15 Sept 2004

Record 0x7f Outline:
Record 0x7f = 127 serves as a test bed for working out the details of new ways of storing GNSS observables for new records. After extensive testing, successful candidates might be upgraded to become standard subrecords of record 0x02 = 2.

Once the BINEX file or stream has been parsed and a record ID = 0x7f has been identified, the user should consult this page for decoding information of the record 0x7f message. For all 0x7f 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 0x7f Subrecord 0x00: 0x7f-00
This subrecord has been developed in cooperation with JPL for fiducial site support of LEO (low-Earth orbit) missions, originally to augment the collection and transfer of Ashtech Z-12 receiver GPS data collected at 1 second intervals. It can be used for other receiver data, as long as the following requirements are met:

  • the time resolution for each time tag is to the millisecond, sufficient to store the time tags for receivers nominally collecting data at integer second values, and accommodate millisecond clock resets.
  • the number of satellites being tracked is 1-32
  • each GNSS satellite being tracked is either GPS or GLONASS currently (though 6 other possible constellation IDs could be accommodated)
  • the satellite number, i.e. the PRN # for GPS or the slot # for GLONASS, is 1-32
  • the observables desired to be stored are some combination of:
    • CA pseudorange to 0.001 meter resolution (= RINEX pseudorange resolution)
    • CA-P1 pseudorange to 0.001 meter resolution (= RINEX pseudorange resolution)
    • CA-P2 pseudorange to 0.001 meter resolution (= RINEX pseudorange resolution)
    • L1(CA) phase to 0.0001 L1-cycle resolution (= 10x RINEX phase resolution)
    • L1(CA) - L1(P1) phase to 0.0001 L1-cycle resolution (= 10x RINEX phase resolution)
    • L1(CA) - L2(P2)*77/60 phase to 0.0001 L1-cycle resolution (= 10x RINEX phase resolution)
    • 1-8 byte signal-to-noise value for L1, depending on source data
    • 1-8 byte signal-to-noise value for L2, depneding on source data
  • epoch-by-epoch data is needed (RINEX model)
  • data for each epoch is standalone, i.e. differences with previous epochs are not stored
  • the phase wavelength factors for identical for all epochs
In addition to the above, the following information can also be encoded at each epoch:
  • the receiver channel number for each satellite being tracked (up to 32 channels)
  • the A/S (anti-spoofing) status of each GPS satellite being tracked (on/off)
  • loss-of-lock indicators for the L1 and L2 frequencies
  • separate "possible error" indicators for each of the observables CA, P1, P2, L1(CA), L1(P1), and L2(P2).
Note: All the multi-byte integer values used in 0x7f-00 (e.g. uint2, uint4, mGFZI) have an endian-ness specified by the sychronization/endian byte of the record.

Field Type Size
(bytes)		 Description
Subrecord ID uint1 1 The first byte of the 0x7f-00 message will be the byte 0x00, denoting the subrecord 0x00.
Time tag uint4
uint2		 6 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.
N SVs and RxFmt uint1 1 Immediately following the 6 time tag bytes will be a single byte (uint1) which contains two pieces of information. The lowest 5 bits indicate the number of satellites with data listed in the record minus 1. The highest 3 bits indicate what the receiver/format of the original data in such a way that the exact meaning of the observables and SNR bytes can be interpreted correctly. Thus, using C/C++ syntax:
  • receiver/format designation = RxFmt = byte >> 5 & 0x07
  • # of satellites = N = (byte & 0x1f) + 0x01
Currently, for the receiver/format designation:
  • 0x00 = Ashtech (B/E/S, R-file, or U-file downloads or MBEN stream formats) with full wavelength phase tracking (RINEX wavelength factors would be "1 1")
  • 0x01 = AOA formats (ConanBinary or TurboBinary)
  • 0x02 = JPL Soc and IGS RTigs formats
  • 0x06 = RINEX OBS with no S1 or S2 observable
  • 0x07 = RINEX OBS with S1 and/or S2 observable(s)
  • other values are reserved
Observed SVs list uint1 N N (uint1) bytes where N = # of satellites. Each of these bytes contains the satellite ID. (See details on decoding.)
For each SV sequentially
(i.e. repeat the remainder for each SV)

Immediately following will be the "Possible Errors" byte, channel-A/S-LLI byte, and the data bytes for the first listed satellite will be the same general structure for each other listed satellite--with the possible exception of the "Possible Error" byte. This byte is only present for all satellites if bit 0 of the first Possible Errors byte is set equal to 1.
Possible Errors
(manitory for first SV)		 uint1 0 or 1 A single (uint1) byte:
  • bit 0 = 1: separate "Possible Errors" byte present for each satellite, and this byte represents the status for only the first satellite; = 0: all "Possible Errors" bytes for all satellites in this record are identical to the "Possible Errors" byte for the first SV, for which this byte is manditory
  • bit 1: reserved (should be = 0)
  • bit 2 = 1: possible questionable data for L1(CA) phase value; = 0: L1(CA) value OK
  • bit 3 = 1: possible questionable data for CA pseudorange value; = 0: CA value OK
  • bit 4 = 1: possible questionable data for L1(P1) phase value; = 0: L1(P1) value OK
  • bit 5 = 1: possible questionable data for P1 pseudorange value; = 0: P1 value OK
  • bit 6 = 1: possible questionable data for L2(P2) phase value; = 0: L2(P2) value OK
  • bit 7 = 1: possible questionable data for P2 pseudorange value; = 0: P2 value OK
For the Ashtech formats, these bits store the following values of the Ashtech "warning flag" byte:
  • bit 2 = carrier phase questionable (mapped into appropriate f7-00 "possible error" bit 2, 4, or 6)
  • bit 3 = code phase questionable (mapped into appropriate f7-00 "possible error" bit 3, 5, or 7)
RxChan, A/S, LLI uint1 1 The receiver channel, A/S status, and loss-of-lock (uint1) byte for the first satellite sytem/number:
  • receiver channel number = (byte & 0x1f) + 0x01 for internal receiver channel indexing that starts at 1 OR receiver channel number = byte & 0x1f for internal receiver channel indexing that starts at 0 OR store 0 for all SVs if there is no internal receiver channel number
  • bit 5 = 1: A/S enabled for this SV; = 0: A/S off
  • bit 6 = 1: loss-of-lock for either L1(CA) or L1(P1); = 0: no loss-of-lock for any L1 phase
  • bit 7 = 1: loss-of-lock for L2(P2); = 0: no loss-of-lock for L2(P2)
CA mGFZI 1 to 8 1000xCA pseudorange in meters (storing to nearest 0.001 m)
P1 delta mGFZI 1 to 8 1000x(CA - P1) (storing to nearest 0.001 m)
P2 delta mGFZI 1 to 8 1000x(CA - P2) (storing to nearest 0.001 m)
L1 and L2 S/N depends on RxFmt 2 to 10 L1 and L2 signal-to-noise storage depends on receiver/format designation, 2-10 bytes:
  • 0x00 (Ashtech formats):
    • 1-byte (uint1) value for L1 signal-to-noise
    • 1-byte (uint1) value for L2 signal-to-noise
  • 0x01 (AOA formats):
    • 1-byte (uint1) upper 4 bits of both L1 and L2 signal-to-noise values (i.e.: 0x0f & S1 >> 8 | 0xf0 & S2 >> 8)
    • 1-byte (uint1) value for lower 8-bits of L1 signal-to-noise
    • 1-byte (uint1) value for lower 8-bits of L2 signal-to-noise

      • (note: range of TurboBinary each S1 or S2 is only 10 bits, though here we are allowing for each to use up to 12 bits, with the upper 4 bits stored separately from the lower 8 bits)
  • 0x02 (JPL Soc and IGS RTigs formats, SNR in dBHz is assumed):
    • 1-byte (uint1) value for L1 signal-to-noise in 0.25 dBHz, rounded to nearest 0.25 dBHz
    • 1-byte (uint1) value for L2 signal-to-noise in 0.25 dBHz, rounded to nearest 0.25 dBHz
  • 0x06 (RINEX format with no S1 or S2 observable):
    • 1-byte (uint1) value for L1 signal-to-noise = RINEX L1 SNR flag (0-9 value)
    • 1-byte (uint1) value for L2 signal-to-noise = RINEX L2 SNR flag (0-9 value)
  • 0x07 (RINEX format with S1 and/or S2 observable):
    • 1-8 bytes (mGFZI) value for 4*S1 value
    • 1-8 bytes (mGFZI) value for 4*S2 value
    • 1-byte (uint1) value for L1 signal-to-noise = RINEX L1 SNR flag (0-9 value)
    • 1-byte (uint1) value for L2 signal-to-noise = RINEX L2 SNR flag (0-9 value)

      • (note: granularity of all known RINEX S1 and S2 observables is either 1 or 0.25 dBHz)
    L1(CA) mGFZI 1 to 8 10000xL1(CA) phase in L1-cycles (storing to nearest 0.0001 L1-cycle)
    L1(P1) delta mGFZI 1 to 8 10000x(L1(CA) - L1(P1)) (storing to nearest 0.0001 L1-cycle)
    L2(P2) delta mGFZI 1 to 8 10000x(L1(CA) - L2(P2)*77/60) (storing to nearest 0.0001 L2-cycle)


    Record 0x7f Subrecord 0x01: 0x7f-01
    This subrecord has been developed in cooperation with COSMIC/UCAR for additional support of GPS/MET data, specifically to store high-rate "LC" phase data, as long as the following requirements are met:

    • the time resolution for each time tag is to the millisecond, sufficient to store the time tags for receivers nominally collecting data at integer second values, and accommodate millisecond clock resets.
    • the number of satellites being tracked is 1-32
    • each GNSS satellite being tracked is either GPS or GLONASS currently (though 6 other possible constellation IDs could be accommodated)
    • the satellite number, i.e. the PRN # for GPS or the slot # for GLONASS, is 1-32
    • the observables desired to be stored are only:
      • "LC" phase combination to 0.0001 cycle resolution (= 10x RINEX phase resolution)
    • epoch-by-epoch data is needed (RINEX model)
    • data for each epoch is standalone, i.e. differences with previous epochs are not stored
    • the phase wavelength factors for identical for all epochs
    In addition to the above, the following information can also be encoded at each epoch:
    • the receiver channel number for each satellite being tracked (up to 32 channels)
    • the A/S (anti-spoofing) status of each GPS satellite being tracked (on/off)
    • loss-of-lock indicators for the LC combination
    Note: All the multi-byte integer values used in 0x7f-01 (e.g. uint2, uint4, mGFZI) have an endian-ness specified by the sychronization/endian byte of the record.

    Field Type Size
    (bytes)    		 Description
    Subrecord ID uint1 1 The first byte of the 0x7f-01 message will be the byte 0x01, denoting the subrecord 0x01.
    Time tag uint4
    uint2    		 6 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.
    N SVs and RxFmt uint1 1 Immediately following the 6 time tag bytes will be a single byte (uint1) which contains two pieces of information. The lowest 5 bits indicate the number of satellites with data listed in the record minus 1. The highest 3 bits indicate what the receiver/format of the original data in such a way that the exact meaning of the observables and SNR bytes can be interpreted correctly. Thus, using C/C++ syntax:
    • receiver/format designation = RxFmt = byte >> 5 & 0x07
    • # of satellites = N = (byte & 0x1f) + 0x01
    Currently, for the receiver/format designation:
    • 0x00 = AOA source format (probably TurboBinary)
    • other values are reserved
    Observed SVs list uint1 N N (uint1) bytes where N = # of satellites. Each of these bytes contains the satellite ID. (See details on decoding.)
    For each SV sequentially
    (i.e. repeat the remainder for each SV)


    RxChan, A/S, LLI uint1 1 The receiver channel, A/S status, and loss-of-lock (uint1) byte for the first satellite sytem/number:
    • receiver channel number = (byte & 0x1f) + 0x01 for internal receiver channel indexing that starts at 1 OR receiver channel number = byte & 0x1f for internal receiver channel indexing that starts at 0 OR store 0 for all SVs if there is no internal receiver channel number
    • bit 5 = 1: A/S enabled for this SV; = 0: A/S off
    • bit 6 = 1: loss-of-lock for either L1(CA) or L1(P1); = 0: no loss-of-lock for any L1 phase
    • bit 7 = 1: loss-of-lock for L2(P2); = 0: no loss-of-lock for L2(P2)
    LC mGFZI 1 to 8 10000xLC, rounded to nearest 0.0001 LC-cycle


    Record 0x7f Subrecord 0x02: 0x7f-02
    This subrecord was developed in cooperation with Trimble for their 4700 receiver firmware for use in the UCAR/GST Suominet project. It can be used for other receiver data, as long as the following requirements are met:

    • the time resolution for each time tag is to the millisecond, sufficient to store the time tags for receivers nominally collecting data at integer second values, and accommodate millisecond clock resets.
    • the number of satellites being tracked is 1-32
    • each GNSS satellite being tracked is either GPS or GLONASS currently (though 6 other possible constellation IDs could be accommodated)
    • the satellite number, i.e. the PRN # for GPS or the slot # for GLONASS, is 1-32
    • raw 1-byte (uint1) signal-to-noise value for L1 in units of 0.25 dBHz
    • raw 1-byte (uint1) signal-to-noise value for L2 in units of 0.25 dBHz
    • other observables desired to be stored are some combination of:
      • CA pseudorange to 0.001 meter resolution (= RINEX pseudorange resolution)
      • CA-P1 pseudorange to 0.001 meter resolution (= RINEX pseudorange resolution)
      • CA-P2 pseudorange to 0.001 meter resolution (= RINEX pseudorange resolution)
      • L1(CA) or L1(P1) phase to 0.0001 L1-cycle resolution (= 10x RINEX phase resolution)
      • L1(CA) - L2(P2)*77/60 or L1(P1) -L2(P2)*77/60 phase to 0.0001 L1-cycle resolution (= 10x RINEX phase resolution)
      • L1 Doppler to 0.001 Hz resolution (= RINEX pseudorange resolution)
    • epoch-by-epoch data is needed (RINEX model)
    • data for each epoch is standalone, i.e. differences with previous epochs are not stored
    • the phase wavelength factors for identical for all epochs
    In addition to the above, the following information can also be encoded at each epoch:
    • the receiver channel number for each satellite being tracked (up to 32 channels)
    • the A/S (anti-spoofing) status of each GPS satellite being tracked (on/off)
    • loss-of-lock indicators for the L1 and L2 frequencies
    • receiver clock offset to nearest 1 ns
    Note: All the multi-byte integer values used in 0x7f-02 (e.g. uint2, uint4, mGFZI) have an endian-ness specified by the sychronization/endian byte of the record.

    Field Type Size
    (bytes)    		 Description
    Subrecord ID uint1 1 The first byte of the 0x7f-02 message will be the byte 0x02, denoting the subrecord 0x02.
    Time tag uint4
    uint2    		 6 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.
    N SVs and RxFmt uint1 1 Immediately following the 6 time tag bytes will be a single byte (uint1) which contains two pieces of information. The lowest 5 bits indicate the number of satellites with data listed in the record minus 1. The highest 3 bits indicate what the receiver/format of the original data in such a way that the exact meaning of the observables and SNR bytes can be interpreted correctly. Thus, using C/C++ syntax:
    • receiver/format designation = RxFmt = byte >> 5 & 0x07
    • # of satellites = N = (byte & 0x1f) + 0x01
    Currently, for the receiver/format designation:
    • 0x00 = full wavelength phase tracking (RINEX wavelength factors would be "1 1"), L1 and L2 SNR values in dBHz referenced to a 1 Hz bandwidth C to Nzero
    • other values are reserved
    Observed SVs list uint1 N N (uint1) bytes where N = # of satellites. Each of these bytes contains the satellite ID. (See details on decoding.)
    bit flags uint1 1 to q One or more (uint1) bytes indicating bit flags in bits 0-6; single uint1 bytes containing bit flags are read until a uint1 is reached with bit7 = 0:
    • 1st uint1, bit 0 = 1: 1-8 bytes (mGFZI) to follow bit flags storing the receiver clock offsett to the nearest nanosecond in nanoseconds. Use of this bit flag is equivalent to RINEX 2.10 with RCV CLOCK OFF APPL = 0 and all associated adjustments to time tags and observables (to maintain backwards compatibility with RINEX)
    • 1st uint1, bit 1 = 1: 1-8 bytes (mGFZI) to follow bit flags storing the receiver clock offsett to the nearest nanosecond in nanoseconds. Use of this bit flag is equivalent to RINEX 2.10 with RCV CLOCK OFF APPL = 1 and all associated adjustments to time tags and observables (to maintain backwards compatibility with RINEX)
    • 1st uint1, bit 2 = 1: 1-8 bytes (mGFZI) to follow bit flags storing the receiver clock offsett to the nearest nanosecond in nanoseconds. Use of this bit flag indicates that the time tag values and pseudorange values are not adjusted as per the RINEX specification or time tags and pseudoranges for millisecond clock resets, i.e. to convert to the RINEX standard for time tags and pseudoranges, the receiver clock offset must be monitored from epoch to epoch to detect millisecond resets which must then be applied in the usual way to the time tags and pseudoranges to be RINEX compliant
    • at most, only one bit of 1st uint1, bits 0-2 can be set for an epoch.
    • other bits: definition reserved, requiring that bits 3-7 of the first uint1 all be unset (= 0)
    Receiver clock offset
    (optional)    		 mGFZI 1 to 8 1-8 byte mGFZI is present if first uint1 bit flag, bit 0, 1, or 2 = 1: receiver clock offset in nanoseconds, rounded to the nearest nanosecond
    For each SV (except for possibly the Obs Present bytes)


    Obs Present uint1 1 to m First byte:
  • bit 0: 1 = a separate Obs Present byte sequence is present for each SV; 0 = the Obs Present byte sequence is present for only the first SV in the list and the sequence is identical for each other SV in the list for this epoch
  • bit 1: 1 = Obs1 is present; 0 = absent
  • bit 2: 1 = Obs2 is present; 0 = absent
  • bit 3: 1 = Obs3 is present; 0 = absent
  • bit 4: 1 = Obs4 is present; 0 = absent
  • bit 5: 1 = Obs5 is present; 0 = absent
  • bit 6: 1 = Obs6 is present; 0 = absent
  • bit 7: 1 = at least one more Obs Present byte follows this one; 0 = this is the last Obs Present byte


    • Subsequent bytes (if any, i=1, 2, 3, ...)
  • bit 0: 1 = Obs(0+7i) is present; 0 = absent
  • bit 1: 1 = Obs(1+7i) is present; 0 = absent
  • bit 2: 1 = Obs(2+7i) is present; 0 = absent
  • bit 3: 1 = Obs(3+7i) is present; 0 = absent
  • bit 4: 1 = Obs(4+7i) is present; 0 = absent
  • bit 5: 1 = Obs(5+7i) is present; 0 = absent
  • bit 6: 1 = Obs(6+7i) is present; 0 = absent
  • bit 7: 1 = at least one more Obs Present byte follows this one; 0 = this is the last Obs Present byte
    • See below for definition of types of observables.
    RxChan, A/S, LLI uint1 1 The receiver channel, A/S status, and loss-of-lock (uint1) byte for the first satellite sytem/number:
    • receiver channel number = (byte & 0x1f) + 0x01 for internal receiver channel indexing that starts at 1 OR receiver channel number = byte & 0x1f for internal receiver channel indexing that starts at 0 OR store 0 for all SVs if there is no internal receiver channel number
    • bit 5 = 1: A/S enabled for this SV; = 0: A/S off
    • bit 6 = 1: loss-of-lock for either L1(CA) or L1(P1); = 0: no loss-of-lock for any L1 phase
    • bit 7 = 1: loss-of-lock for L2(P2); = 0: no loss-of-lock for L2(P2)
    L1 and L2 S/N uint1 2 L1 and L2 signal-to-noise are always stored. A value of zero indicates that the data is not available (for example, if the receiver is only tracking L1 or L2 for this SV during the epoch).
  • RxFmt = 0x00:
    • 1-byte uint1 value for the L1 signal-to-noise in units of 0.25 dBHz, rounded to nearest 0.25 dBHz
    • 1-byte uint1 value for the L2 signal-to-noise in units of 0.25 dBHz, rounded to nearest 0.25 dBHz
    Other specifications reserved for other RxFmt values.
    for each Obsn below

    		field is present only when the Obs Present bit n is set; if Obsn is invalid, either Obs Present bit n is unset (=0), or bit n is set (=1) and the mGFZI value has an invalid/unknown value of "-0"
    Obs1
    (optional)    		 mGFZI 1 to 8 1000xCA, rounded to nearest 0.001 m
    Obs2
    (optional)    		 mGFZI 1 to 8 if CA (Obs1) is present 1000x(CA-P1), otherwise 1000xP1, rounded to nearest 0.001 m
    Obs3
    (optional)    		 mGFZI 1 to 8 if CA (Obs1) is present 1000x(CA-P2), otherwise 1000x(P1-P2), rounded to nearest 0.001 m
    Obs4
    (optional)    		 mGFZI 1 to 8 if CA (Obs1) is present 10000xL1(CA), otherwise 10000xL1(P1), rounded to nearest 0.0001 L1-cycle
    Obs5
    (optional)    		 mGFZI 1 to 8 if CA (Obs1) is present 10000x(L1(CA)-L2(P2)*77/60), otherwise 10000x(L1(P1)-L2(P2)*77/60), rounded to nearest 0.0001 L1-cycle
    Obs6
    (optional)    		 mGFZI 1 to 8 1000xL1 Doppler, rounded to nearest 0.001 Hz
    Obs7 and higher
    (optional)

    		definition reserved


    Record 0x7f Subrecord 0x03: 0x7f-03
    This subrecord is being developed in cooperation with Trimble for their NetRS receiver firmware for use in the EarthScope Plate Boundary Observatory project and is currently in development and under review (22 June 2004 until further notice). It can be used for other receiver data, as long as the following requirements are met:

    • the time resolution for each time tag is to the millisecond, sufficient to store the time tags for receivers nominally collecting data at integer second values.
    • the number of satellites being tracked is 1-16
    • each GNSS satellite being tracked is either GPS or GLONASS currently (though 6 other possible constellation IDs could be accommodated)
    • the satellite number, i.e. the PRN # for GPS or the slot # for GLONASS, is 1-32
    • raw 1-byte (uint1) signal-to-noise value for L1 or L2 in units of 0.1 dBHz
    • other observables desired to be stored are some combination of:
      • CA, P1, or P2 pseudorange to 0.001 meter resolution (= RINEX pseudorange resolution)
      • L1(CA), L1(P1), or L2(P2) phase to 0.02 mm resolution (~ 10x RINEX phase resolution)
      • L1 Doppler to 1/256 Hz resolution (~ 1/4 RINEX doppler resolution)
    • epoch-by-epoch data is needed (RINEX model)
    • data for each epoch is standalone, i.e. differences with previous epochs are not stored
    • the phase wavelength factors for identical for all epochs
    In addition to the above, the following information can also be encoded at each epoch:
    • the receiver channel number for each satellite being tracked (up to 16 channels)
    • the A/S (anti-spoofing) status of each GPS satellite being tracked (on/off)
    • SV health status of each satellite being tracked (on/off)
    • loss-of-lock indicators for the L1 and L2 frequencies
    • receiver clock offset to nearest 1 ns
    • receiver clock millisecond reset occurrance (±1 ms)
    Note: All the multi-byte integer values used in 0x7f-03 have an endian-ness specified by the sychronization/endian byte of the record.

    Field Type Size
    (bytes)    		 Description
    Subrecord ID uint1 1 The first byte of the 0x7f-03 message will be the byte 0x03, denoting the subrecord 0x03.
    Time tag uint4
    uint2    		 6 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.
    N SVs + Flags uint1 1 Immediately following the 6 time tag bytes will be a single byte (uint1) which contains two pieces of information. The lowest 5 bits indicate the number of satellites with data listed in the record minus 1. The highest 3 bits are used as flags as defined below. Using C/C++ syntax:
    • Flags = byte & 0xe0
    • # of satellites = N = (byte & 0x1f) + 0x01
    For the 3-bit Flags:
    • bit 5: (reserved; not used at this time)
    • bit 6: if 0, no RxClkOff field; if 1, then 3-byte RxClkOff field is present (note: There is no implied indication as to whether the receiver is performing clock steering. Receiver clock steering may be enabled in either case.)
    • bit 7: if 0, no BitFlags byte(s) follow the N SVs + Flags bytes; if 1, at least one BitFlags byte follows the N SVs + Flags byte
    [BitFlags] — 0 to n 0 to n bytes. Each byte, if present, contains up to 7 bit flags in bits 0-6. Bit 7 is used to indicate whether another BitFlags byte follows. (note: No BitFlags bytes are defined at this time.)
    [RxClkOff] — 0 or 3 The RxClkOff bytes, if present, store the receiver clock offset and reset information as follows. Bytes are stored in the endian order of all other numerics in the record with special interpretation of the top two MSBs:
    • Bits 0-21: the lower 22 bits of the RxClkOff bytes stores the clock offset as a s+21b with 1 nanosecond resolution, to the nearest 1 nanosecond, with a ±2.097 millisecond range
    • Bits 22-23: the higher 2 bits of the RxClkOff bytes convey whether a millisecond reset has occurred since the epoch immediately prior to the current epoch as follows:

      01 == +ms reset has occurred at this epoch
      00 == no ms reset has occurred at this epoch
      11 == -ms reset has occurred at this epoch
      10 == invalid value
    Observed SVs list uint1 N N (uint1) bytes where N = # of satellites. Each of these bytes contains the satellite ID. (See details on decoding.)
    For each SV (except for possibly the Obs Present bytes)


    Obs Present — 1 to m The ObsPresent flags will be as follows:

  • Bit 0: 1 = a separate ObsPresent byte sequence is present for each SV; 0 = the ObsPresent byte sequence is present for only the first SV in the list and the sequence is identical for each other SV in the list for this epoch
  • Bit 1: Obs1, which is a combined set of L1 observables: CNo, Range, and Phase
  • Bit 2: Obs2, which is a combined set of L2 observables: CNo, Range, and Phase
  • Bit 3: Obs3, L1 doppler
  • Bit 4: Obs4, Slip Counts
  • Bit 5: (reserved)
  • Bit 6: (reserved)
  • Bit 7: 0 = this is the last ObsPresent byte; 1 = at least one more ObsPresent byte follows this one
    • RxChan, A/S, ScalePhaseDelta, SV unhealthy — 1 This byte is present for each SV if any of the ObsPresent bits are set for the SV:

  • receiver channel number = (byte & 0x1f) + 0x01 for internal receiver channel indexing that starts at 1 OR receiver channel number = byte & 0x1f for internal receiver channel indexing that starts at 0 OR store 0 for all SVs if there is no internal receiver channel number
  • bit 4 = 1: (reserved — possibly to extend the channel number range at a later date)
  • bit 5 = 1: for GPS SV only: A/S enabled for this SV; = 0: A/S off (note: For non-GPS SVs, this bit should always be set to zero unless a use for this bit is defined at a later date for non-GPS SVs.)
  • bit 6 (ScalePhaseDelta) = 0: phase resolution is 0.02 mm (phase delta range ±167.772 m); = 1: phase resolution is 0.10 mm (phase delta range ±838.861 m)
  • bit 7 = 1: SV is logged as unhealthy; = 0 otherwise
    • each Obsn block is defined below

    		each Obsn block below is present only when the corresponding ObsPresent bit n is set
    Obs1 Block — 9 L1 data block: there are three byte-fields of contiguous bytes; big- or little-endianness applies separately to each of these byte-fields:

  • byte 1: uint1 representing the L1-CNo MSBs to 0.4 dBHz resolution, to nearest 0.4 dBHz; range 0 to 102.4 dBHz
  • bytes 2-6:
    • bits 0-35: L1 range as u36b to 1 mm resolution, to nearest 1 mm; range 0 to 68719.476735 km
    • bit 36: 0 = C/A; 1 = P
    • bit 37: LLI-1; 0 = no loss of lock on L1; 1 = loss of lock from previous epoch
    • bits 38-39: representing the L1-CNo LSBs to 0.1 dBHz resolution, to nearest 0.1 dBHz as a 2-bit two's complement integer; range -0.2 dBHz to +0.1 dBHz; add to L1-CNo MSBs to obtain full L1-CNo to 0.1 dBHz resolution
  • bytes 7-9: L1 phase - L1 range stored as s+23b to the resolution specified in corresponding ScalePhaseDelta (range ±167.772 m or ±838.86 m)
    		•
    Obs2 Block — 7 or 9 L2 data block: there are three byte-fields of contiguous bytes; big- or little-endianness applies separately to each of these byte-fields:

  • byte 1: uint1 representing the L2-CNo MSBs to 0.4 dBHz resolution, to nearest 0.4 dBHz; range 0 to 102.4 dBHz
  • if Obs1 is present, bytes 2-4:
    • bits 0-19: L2 range - L1 range as s+19b to 1 mm resolution, to nearest 1 mm; range ±524.287 m
    • bit 20: 0 = L2C; 1 = P
    • bit 21: LLI-1; 0 = no loss of lock on L2; 1 = loss of lock from previous epoch
    • bits 22-23: representing the L2-CNo LSBs to 0.1 dBHz resolution, to nearest 0.1 dBHz as a 2-bit two's complement integer; range -0.2 dBHz to +0.1 dBHz; add to L2-CNo MSBs to obtain full L2-CNo to 0.1 dBHz resolution
  • if Obs1 is present, bytes 5-7: L2 phase - L2 range stored as s+23b to the resolution specified in corresponding ScalePhaseDelta (range ±167.772 m or ±838.86 m)


  • if Obs1 is not present, bytes 2-6:
    • bits 0-35: L2 range as u36b to 1 mm resolution, to nearest 1 mm; range 0 to 68719.476735 km
    • bit 36: 0 = L2C; 1 = P
    • bit 37: LLI-1; 0 = no loss of lock on L2; 1 = loss of lock from previous epoch
    • bits 38-39: representing the L2-CNo LSBs to 0.1 dBHz resolution, to nearest 0.1 dBHz; range -0.2 dBHz to +0.1 dBHz; add to L2-CNo MSBs to obtain full L2-CNo to 0.1 dBHz resolution
  • if Obs1 is not present, bytes 7-9: L2 phase - L2 range stored as s+23b to the resolution specified in corresponding ScalePhaseDelta (range ±167.772 m or ±838.86 m)
    		•
    Obs3 Block s+23b 3 L1 doppler to 1/256 Hz resolution, to nearest 1/256 Hz; range ±32767.996 Hz
    Obs4 Block unit1 2 A single byte (range 0 to 255) slip count for each frequency, L1 and/or L2 for which a bit is set in the ObsPresent byte. Thus, if only L1 or only L2 data is present, there is only a one byte associated slip count in this field. Using a single unit1 for the L1 and L2 slip counts allows for an outage of up to 25.6 seconds at a 10-Hz measurement rate or 256 seconds at a 1-Hz measurement rate without slip ambiguity.
  • byte 1 (if Obs1 present): L1 slip count, range 0 to 255
  • byte 2 (if Obs1 and Obs2 present) or 1 (if only Obs2 present): L2 slip count, range 0 to 255

    • Supplementary notes for 0x7f-03:

  • Unlike the JPL Soc format, Phase - range are not adjusted using dual-frequency data to remove an estimated ionospheric bias.
  • The time tag and code/phase observations of this record are never adjusted according to the receiver clock offset. (This corresponds to a RINEX RCV CLOCK OFS APPL value of 0.)
  • The type of L1 or L2 range observable, i.e. "coarse" = L1(C/A) or L2C, or "precise" = P, is indicated by the bit 36 in the L1 block or bit 20 or 36 in the L2 block (depending on whether the L1 block is present or not). If someone wishes to have both "coarse" and "precise" for L1 and L2 (when GPS L2C becomes available), then additional observation block will be defined to allow this.
  • The LL1 flags are always stored and refer to the current epoch. The L1 and L2 slip count values are useful for real-time applications.
  • The L1 phase and L2 phase are provided as deltas from the L1 range as "L1 phase - L1 range" and "L2 phase - L1 range" when Obs1 is present, and L2 phase is provided as the delta from the L2 range as "L2 phase - L2 range" when Obs1 is not present. It is assumed that there will never be phase without the corresponding range.
  • The intent of the 0.1 mm ScalePhaseDelta (phase delta range of ±838.86 m) is to handle overflow under very high ionospheric activity, especially when tracking at low elevations. However, the 0.02 mm ScalePhaseDelta should be used whenever possible.
  • The full L1 and L2 CNo value is a 10-bit value with a 0.1 dBHz resolution. The two LSBs are stored separately from the eight MSBs. (Decomposing the 8-bit MSBs allows the user to get the CNo to the nearest 0.4 dBHz ± which is sufficient for some applications.) The values are obtained from the full CNo as follows:
      LSBs (2 bits): Mask the 10-bit value. (LSBs = CNo & 0x0003)
      MSBs (8 bits): Mask the MSBs of the 10-bt value, and then shift right 2 bits. If the MSB of the LSBs is 1 (LSBs & 0x0002), add 1.
    Reconstruct the full 10-bit value by left-shifting the MSBs, sign-extending the LSBs, and then adding the shifted MSBs to the extended LSBs, all in two's complement.
  • In a future version of this record, the L1 and L2 slip counts could be extended by increasing the storage for each. At 10-Hz or 1-Hz sampling intervals, using 12 bits for each provides a 409.6s or 4096 second interval with ambiguity, and using 16 bits for each provides a 6553.6 or 65536 second interval with ambiguity.



    • Record 0x7f Subrecord 0x04: 0x7f-04
    This subrecord is being developed in cooperation with Trimble for their NetRS receiver firmware for use in the EarthScope Plate Boundary Observatory project and is currently in development and under review (13 Sept 2004 until further notice). The use is to indicate an epoch where the receiver should be tracking, but is unable to track any SVs.

    • the time resolution for each time tag is to the millisecond, sufficient to store the time tags for receivers nominally collecting data at integer second values.
    • the number of satellites being tracked is assumed to be 0
    • with no SVs being tracked, the time tag is the receiver's best estimate of GPS time.


    Field Type Size
    (bytes)    		 Description
    Subrecord ID uint1 1 The first byte of the 0x7f-04 message will be the byte 0x04, denoting the subrecord 0x04.
    Time tag uint4
    uint2    		 6 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.
    BitFlags — 1 to n 1 to n bytes. Each byte, if present, contains up to 7 bit flags in bits 0-6. Bit 7 is used to indicate whether another BitFlags byte follows. (note: Only one BitFlags byte is defined at this time, and it should be set to 0x00. Use of the lower 7 bits may be defined at a future date.)


    The BINEX record 0x7f 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
     

    Home | About Us | Contact Us | Support | Search | Facility | PBO | Education & Outreach

    Comments: webmasterATunavco.org
    © 2008 UNAVCO, Inc.