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

Binary Exchange format for GPS/GNSS
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
current BINEX Record 0x7f Subrecord 0x05

Contact: GAGE BINEX contact


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, 0.25, or 0.1 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 the UCAR Cosmic project. 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 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 was being developed in cooperation with Trimble for their NetRS receiver firmware for use in the EarthScope Plate Boundary Observatory 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.
    • the number of satellites being tracked is 1-16
    • each GNSS satellite being tracked is either GPS, GLONASS, SBAS, Galileo, Beidou-1 / Beidou-2 (Phase II), QZSS
      • , or IRNSS
    • the satellite number can be represented with 5 bits (see details)
    • raw 1-byte (uint1) signal-to-noise value for primary and secondary phase carriers in units of 0.1 dBHz
    • other observables desired to be stored are some combination of:
      • pseudorange to 0.001 meter resolution (= RINEX pseudorange resolution)
      • phase to 0.02 mm resolution (~ 10x RINEX phase resolution)
      • primary 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 primary and secondary 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:
    • # of satellites = N = (byte & 0x1f) + 0x01
    • Flags = byte & 0xe0
    For the three Flags bits:
    • 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 primary (e.g. GPS L1) observables: CNo, Range, and Phase
    • Bit 2: Obs2, which is a combined set of secondary (e.g. GPS L2) observables: CNo, Range, and Phase
    • Bit 3: Obs3, doppler of Obs1 phase
    • 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 primary (e.g. GPS 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 CNo MSBs to 0.4 dBHz resolution, to nearest 0.4 dBHz; range 0 to 102.4 dBHz
    • bytes 2-6:
      • bits 0-35: range as u36b to 1 mm resolution, to nearest 1 mm; range 0 to 68719.476735 km
      • bit 36, dependent on satellite system:
          • GPS: 0 = L1C/A; 1 = L1P(Y)
          GLONASS: 0 = L1C/A (== L1 SA); 1 = L1P (== L1 HA)
          SBAS: 0 = L1C/A; 1 = undefined
          Galileo: 0 = E1(B+C); 1 = E1(A+B+C)
          Beidou: 0 = B1/E2(I); 1 = undefined
          QZSS: 0 = L1C/A; 1 = L1C(D+P)
      • bit 37: LLI-1; 0 = no loss of lock on phase; 1 = loss of lock from previous epoch
      • bits 38-39: representing the 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 CNo MSBs to obtain full CNo to 0.1 dBHz resolution
    • bytes 7-9: Obs1 phase - Obs1 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 secondary (e.g. GPS 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 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: Obs2 range - Obs1 range as s+19b to 1 mm resolution, to nearest 1 mm; range ±524.287 m
      • bit 20, dependent on satellite system:
          • GPS: 0 = L2C(I+Q= M+L); 1 = L2P(Y)
          GLONASS: 0 = L2C/A (== L2 SA); 1 = L2P (== L2 HA)
          SBAS: 0 = undefined; 1 = L5(I)
          Galileo: 0 = E5b(I+Q); 1 = E5a(I+Q)
          Beidou: 0 = undefined; 1 = B2/E5b(I)
          QZSS: 0 = L2C(I+Q); 1 = L5{I+Q)
      • bit 21: LLI-1; 0 = no loss of lock on phase; 1 = loss of lock from previous epoch
      • bits 22-23: representing the 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 CNo MSBs to obtain full CNo to 0.1 dBHz resolution
    • if Obs1 is present, bytes 5-7: Obs2 phase - Obs2 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: range as u36b to 1 mm resolution, to nearest 1 mm; range 0 to 68719.476735 km
      • bit 36: same definition as for bit 20 when Obs1 is present (above)
      • bit 37: LLI-1; 0 = no loss of lock; 1 = loss of lock from previous epoch
      • bits 38-39: representing the CNo LSBs to 0.1 dBHz resolution, to nearest 0.1 dBHz; range -0.2 dBHz to +0.1 dBHz; add to CNo MSBs to obtain full CNo to 0.1 dBHz resolution
    • if Obs1 is not present, bytes 7-9: Obs2 phase - Obs2 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 Obs1 doppler to 1/256 Hz resolution, to nearest 1/256 Hz; range ±32767.996 Hz
    Obs4 Block uint1 2 A single byte (range 0 to 255) slip count for each frequency, whether Obs1 and/or Obs2 for which a bit is set in the ObsPresent byte. Thus, if only Obs1 or only Obs2 data is present, there is only a one byte associated slip count in this field. Using a single uint1 for the Obs1 and Obs2 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): Obs1 slip count, range 0 to 255
    • byte 2 (if Obs1 and Obs2 present) or 1 (if only Obs2 present): Obs2 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 Obs1 or Obs2 range observable, e.g. GPS "coarse" = L1(C/A) or L2C, or GPS "precise" = P, is indicated by the bit 36 in the Obs1 block or bit 20 or 36 in the Obs2 block (depending on whether the Obs1 block is present or not). If, for example, someone wishes to have both GPS "coarse" and "precise" for L1 and L2, then additional observation block will be defined to allow this.
    • The LLI flags are always stored and refer to the current epoch. The Obs1 and Obs2 slip count values are useful for real-time applications.
    • The Obs1 phase and Obs2 phase are provided as deltas from the Obs1 range as "Obs1 phase - Obs1 range" and "Obs2 phase - Obs1 range" when Obs1 is present, and Obs2 phase is provided as the delta from the Obs2 range as "Obs2 phase - Obs2 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 Obs1 and Obs2 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 Obs1 and Obs2 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. 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.)


      Record 0x7f Subrecord 0x05: 0x7f-05
      This subrecord was originally developed by Trimble for their NetR8 receiver, and has been extended somewhat from the original design. 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.
      • epoch-by-epoch data is needed (RINEX model)
      • the number of satellites being tracked is 1-64 (note: if the need to log an epoch with zero SVs being tracked is needed, use 0x7f-04)
      • the GNSS satellite being tracked can be GPS, GLONASS (FDMA- and CDMA-broadcasting), SBAS, QZSS as a separate constellation, Galileo, Beidou/Compass, IRNSS and other possible constellations could be accommodated in the future up to a maximum of 16 systems.
      • the satellite number, i.e. the PRN # for all except GLONASS-FDMA and the slot # for GLONASS-FDMA, is 1-255
      • 10-bit signal-to-noise values in units of 0.1 dBHz with a range of 0 — 102.1 dBHz
      • other observables desired to be stored are some combination of:
        • pseudorange to 0.001 meter resolution (= RINEX pseudorange resolution)
        • phase to 0.02 mm resolution (~ 10x RINEX phase resolution)
        • Doppler to 1/256 Hz resolution (~ 1/4 RINEX doppler resolution)
      In addition:
      • no implicit ordering of frequency blocks is defined, each observable block is identified unambiguously
      • data for each epoch is standalone, i.e. differences with previous epochs are not stored
      • the phase wavelength factors for each frequency/tracking type are identical for all epochs
      • the following information can also be encoded at each epoch:
        • 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 all frequencies
        • receiver clock offset to nearest 1 ns
        • receiver clock millisecond reset occurrance (±1 ms)
        • time offsets for each satellite system, identified explicitly
      • information known only to the receiver should not be included in these records, it should be possible to take a receiver observation file and create BINEX records in a post-processed mode
      Note: All the multi-byte integer values used in 0x7f-05 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-05 message will be the byte 0x05, denoting the subrecord 0x05.
      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 6 bits indicate the number of satellites with data listed in the record minus 1. The highest 2 bits are used as flags as defined below. Using C/C++ syntax:
      • # of satellites = N = (byte & 0x3f) + 0x01
      • Flags = byte & 0xc0
      For the two Flags bits:
      • bit 6: if 0, no SysTimeHeader or SysTimeOffset information (see below); if 1, then SysTimeHeader is present which is read to determine the number of SysTimeOffset blocks that are present.
      • bit 7: if 0, no RxClkOff field; if 1, then 3-byte RxClkOff field (see below) 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.)
      [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 2c22b with 1 nanosecond resolution, to the nearest 1 nanosecond, range of -2.097151 to +2.097151 millisecond
      • 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
      [SysTimeHeader] — 0 or 1 The SysTimeHeader byte, if present, provides the system to which the time tag and clock offset are referenced, and optionally a count of the SysTimeOffset fields included in this record. If this header information is not present, the time tag and clock offset (if present) are assumed to be referenced to GPS.
      • bits 0-3 : Satellite system ID (max 16 systems, see Satellite Systems IDs table below) to which time is referenced
      • bits 4-7 : Number, n, of SysTimeOffset fields (0-15) to follow
      [SysTimeOffset] — 0 or 4n The SysTimeOffset fields, if present, store time offsets between the reference satellite system and a second, explicitly defined system. The number, n, of SysTimeOffset fields is extracted from the SysTimeHeader. The clock offset value stored is Sys2 - SysRef.
      • bits 0-3 : Satellite system ID (max 16 systems, see Satellite System IDs table below)
      • bits 4-7 : Reserved
      • bits 8-31: the lower 24 bits of the SysTimeOffset bytes stores the clock offset as a 2c24b with 1 nanosecond resolution, to the nearest 1 nanosecond, range of -8.388607 to +8.388607 millisecond
      Repeated for each SV:


      SV ID uint1 1 The satellite ID (1-255): PRN for CDMA systems, slot # for FDMA GLONASS
      Satellite system and number of obs blocks uint1 1
      • bits 0-3 : Satellite system ID (max 16 systems, see Satellite System IDs table below)
      • bits 4-6 : number of observation blocks (max 7 blocks)
      • bit 7: 1 = SV is logged as unhealthy; 0 = otherwise
      Repeated for each obs block identified above:

      		The following are repeated for each frequency/track-type combination, and constitute either (required) an initial reference obs block or (optionally) one or more delta obs blocks which follow the initial reference obs block. Delta obs blocks, if present, have ranges that are deltas from their reference obs block.
      Observation code uint1 1
      • bits 0-4 : An observation code ID, based on signal/tracking categories defined in the RINEX 3.xx specification, that uniquely identifies the frequency and tracking. A separate enumeration is used for each satellite system. (max 32 observable types, see Observation Code IDs table below).
      • bit 5: 1 = Cycle slip, 0 = otherwise (indicates probable cycle slip)
      • bit 6: may be set in existing data file, but has no current meaning (note: the original use of bit 6 was to distinguish between a reference obs block and a delta obs block, i.e. 1 = reference obs block and 0 = delta obs block, but the current Observation code byte definition requires that the reference obs block will always precede any delta obs block, thereby making the original meaning of bit 6 unnecessary.)
      • bit 7 : 1 = One or more ObsFlags fields follow in this obs block; 0 = no ObsFlags fields follow in this obs block (and therefore bits flags 2-6 of all ObsFlags() are assumed to be 0, consistent with Note 2 below).
      ObsFlags bytes to follow:
      		0 - 4
      (see
      below)      		 Note 1: Each ObsFlags(n) byte includes an ID so that these bytes can be included independently and without regards to order.

      Note 2: The value of bit flags 2-6 are assumed to be 0 for any ObsFlags() byte which is not present. (If ObsFlags(2) is absent on the reference block, then the frequency channel number (fcn) of the GLONASS-FDMA SV is not specified in 0x7f-05, i.e. a missing ObsFlags(2) byte does not imply a fcn of 0.)

      Note 3: In order to minimize the size of 0x7f-05, all ObsFlags() bytes, either specified explicitly or by default, in the initial reference block are assumed to apply for all following delta blocks for that SV in any one 0x7f-05 record, but can be overridden by an ObsFlags() byte in the delta block which then applies only for the delta block in which it occurs. For example, if an ObsFlags(0) is not present in the reference block then all delta blocks for the SV are assumed to have the same set of bit flags 2-6 set to 0 (i.e. see Note 2 above) unless an ObsFlags(0) is present for a delta block (in which case that block's ObsFlags(0) applies only to the delta block in which it occurs). Likewise, to specify the FDMA frequency channel number for a GLONASS SV, an ObsFlags(2) need only be present in the reference block to apply to all delta blocks for that SV.

      Note 4: For a GLONASS SV, an ObsFlags(2) need not be present, but this implies that the frequency channel number (fcn) for this GLONASS slot number occurred elsewhere, either in an earlier 0x7f-05 record or a 0x01-02 decoded GLONASS ephemeris record. Therefore, reading software needs to store the fcn when encountered for each slot number for possible later use. Encoding firmware or software may be designed to minimize the number of ObsFlags(2) bytes by, for example, only having an ObsFlags(2) in the reference block:
      • upon first detection of each GLONASS SV or after any one has been untracked for some period of time, e.g. perhaps 5 to 10 minutes
      • for each GLONASS SV being tracked at the beginning of each 5 or 10 minute interval
      • for any GLONASS SV being tracked where a change of fcn is detected (a rare, but possible, case)
      (The encoding strategies above for minimizing occurrence of ObsFlags(2) in regard to GLONASS frequency channel numbers should be interpreted as possible suggestions, not requirements.)
      [ObsFlags(0)] uint1 0 or 1 The bits of ObsFlags(0) will be interpreted as follows:
      • bits 0-1: ObsFlags ID (byte & 0x03), ID = 0
      • bit 2: Doppler field is present (see [Doppler] below)
      • bit 3: Slip count field is present (see [Slip count] below)
      • bit 4: 1 = slip count uses 16 bits; 0 = slip count uses 8 bits
      • bit 5: (ReducedPhaseAccuracy) 0 = phase resolution is 0.02 mm; 1 = phase resolution is 0.10 mm. See ReducedPhaseAccuracy in the Phase field description below and notes for more detail.
      • bit 6: (ExpandedDelta) 0 = 16 bits used for range deltas and 22 bits used for phase deltas; 1 = 20 bits used for range deltas and 24 bits used for phase deltas. Set when a delta exceeds the value able to be stored in the reduced representation, see ExpandedDelta in the Range and Phase fields below for more detail.
      • bit 7: 0 = this is the last ObsFlags(n) byte; 1 = at least one more ObsFlags(n) byte follows this one (max of 4 ObsFlags bytes)
      [ObsFlags(1)] uint1 0 or 1 The bits of ObsFlags(1) will be interpreted as follows:
      • bits 0-1: Aux block ID (byte & 0x03), ID = 1
      • bit 2: Range is smoothed
      • bit 3: Phase is smoothed
      • bit 4: Multipath reduction is enabled
      • bit 5-6: Reserved
      • bit 7: 0 = this is the last ObsFlags(n) byte; 1 = at least one more ObsFlags(n) byte follows this one (max of 4 ObsFlags bytes)
      [ObsFlags(2)] uint1 0 or 1 The bits of ObsFlags(2) will be interpreted as follows:
      • bits 0-1: Aux block ID (byte & 0x03), ID = 2
      • bits 2-5: GLONASS-FDMA frequency channel number (fcn) as 2c4b (range of -7 to +7); use of this field is highly recommended when the SV is GLONASS-FDMA, but need only be used for the reference block, i.e. if a delta block, then the same fcn as the reference block is obviously assumed
      • bit 6: Reserved
      • bit 7: 0 = this is the last ObsFlags(n) byte; 1 = at least one more ObsFlags(n) byte follows this one (max of 4 ObsFlags bytes)
      [ObsFlags(3)] uint1 0 or 1 The bits of ObsFlags(3) will be interpreted as follows:
      • bits 0-1: Aux block ID (byte & 0x03), ID = 3
      • bits 2-6: Reserved
      • bit 7: 0 = this is the last ObsFlags(n) byte; 1 = at least one more ObsFlags(n) byte follows this one (max of 4 ObsFlags bytes)
      CNo uint1 1 CNo MSBs to 0.4 dBHz resolution, to nearest 0.4 dBHz; range 0.0 to 102.0 dBHz bytes
      Range — 5, 3, or 2 If this is a reference obs block (first Observation code for this SV), then 5 bytes:
      • bits 0-37: range as u38b to 1 mm resolution, to nearest 1 mm, range 0 to 274877.906944 km. (Note: The range has been extended from the 0x7f-03 format to accommodate Galileo and SBAS.)
      • bits 38-39: representing the 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 CNo MSBs to obtain full CNo to 0.1 dBHz resolution
      If this is a delta obs block (after the initial reference obs block for this SV), then either 3 or 2 bytes depending on presence of ObsFlags(0) and its ExpandedDelta bit 6:
      • ObsFlags(0) present and ObsFlags(0) ExpandedDelta bit 6 = 1, then 3 bytes:
        • bits 0-19: (delta range - reference range) as 2c20b to 1 mm resolution, to nearest 1 mm, range -524.287 to +524.287 m
        • bit 20-21: reserved
        • bits 22-23: representing the 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 CNo MSBs to obtain full CNo to 0.1 dBHz resolution
      • ObsFlags(0) not present or ObsFlags(0) is present and ObsFlags(0) ExpandedDelta bit 6 = 0, then 2 bypes
        • bits 0-15: (delta range - reference range) as sint2 to 1 mm resolution, to nearest 1 mm, range of -32.768 to 32.767
      Phase — 3 If ExpandedDelta is set (ObsFlags(0) present and bit 6 = 1):
      • bits 0-23: (phase - range) stored as 2c24b to the resolution specified by ReducedPhaseAccuracy (-167.77215 to +167.77215 m or -838.8608 to 838.8607 m)
      If ExpandedDelta is not set (ObsFlags(0) not present or ObsFlags(0) and bit 6 = 0):
      • bits 0-21: (phase - range) stored as 2c22b to the resolution specified by ReducedPhaseAccuracy (-41.94303 to +41.94303 m or -209.7152 to 209.7151 m)
      • bits 22-23: representing the 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 CNo MSBs to obtain full CNo to 0.1 dBHz resolution
      [Doppler] 2c24b 0 or 3 Doppler, if present (i.e. bit 2 of ObsFlags(0) = 1), to 1/256 Hz resolution, to nearest 1/256 Hz; range -32767 to +32767 Hz. The maximum Doppler for a static observer is approx ±5KHz plus the clock PPM.
      [Slip count] uint1 or uint2 0, 1, or 2 Slip count, if present (i.e. bit 3 of ObsFlags(0) = 1), has a range indicated by the extended slip count bit 4 of ObsFlags(0):
      • If 0, a uint1 (range 0 to 255) slip count is used for each frequency. This 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.
      • If 1, a uint2 (range 0 to 65535) slip count is used for each frequency. This allows for an outage of up to 6553.6 seconds at a 10-Hz measurement rate or 65536 seconds at a 1-Hz measurement rate without slip ambiguity.

      Supplementary notes for 0x7f-05:

      • A small test program was written to estimate the size of the new record vs. the earlier defined 0x7f-03 record. When estimating the minimal size required to send dual frequency data for 12 satellites, the 0x7f-03 record required 225 bytes. The 0x7f-05 record required 237 bytes. The difference in size primarily is accounted for by the presence of the Observation Code byte. This is the overhead required to provide the flexibility required to handle future observation types without implicit ordering of the data. It is conjectured that the 0x7f-03 would also have to be expanded by 1 byte per SV to account for additional observation types, in which case the size would virtually be the same.
      • 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 ability to store multiple range/phase observations for each frequency is supported by this format. Each set of observations is explicitly identified by frequency and track type for each observation block.. The ability to have both "coarse" and "precise" ranges with the associated phase observations is supported by this format.
      • The cycle slip flags are always stored and refer to the current epoch. The slip count values are useful for real-time applications.
      • Phase is provided as a delta from the range as "phase - range". It is assumed that there will never be a Phase entry without the corresponding Range entry.
      • The use of the ExpandedDelta flag provides a mechanism for an additional 1 byte savings when the difference between the reference range and the range in the current observation block is between -32.678m to 32.767m. If the range difference exceeds this value, the ExpandedDelta flag is set and additional bits are used to extend the range of the delta at the cost of adding 1 additional byte for transfer.
      • The intent of the 0.1 mm ReducedPhaseAccuracy state is to handle overflow under very high ionospheric activity, especially when tracking at low elevations. The 0.02 mm phase accuracy should be used whenever possible.
      • The full 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.
      • Lower carrier frequencies have high ionospheric delay (delay is proportional to 1/f^2). It is recommended that the "primary" observable (master obs block) always be the lowest frequency and then the difference should always be positive. (Note for future consideration: Due to RF delays it is possible the difference will be slightly negative, so one possibility is to do Primary - Aux + 600; drop a bit and then the actual range that can be stored is -75.713 to +448.574.)


      Satellite System IDs for 0x7f-05:

      System ID #
      GPS 0
      GLONASS — FDMA 1
      SBAS 2
      Galileo 3
      Beidou 4
      QZSS 5
      IRNSS 6

      Observation Code IDs for 0x7f-05:

      System Freq.
      Band      		 Freq
      MHz      		 Channel or Code ID # Rinex Code Notes
      GPS L1 1575.42 unknown 0



      		C/A 1 1C



      		P 2 1P



      		Z-tracking or similar (AS on) 3 1W



      		Y 4 1Y



      		M 5 1M



      		L1C(P) 6 1L ID formerly referenced all L1C's



      		codeless 7 1N



      		L1C(D) 8 1S



      		L1C(D+P) 9 1X
      GPS L2 1227.60 unknown 10



      		C/A 11 2C



      		L1(C/A)+(P2-P1)
      (semi-codeless)      		 12 2D



      		L2C(M) 13 2S



      		L2C(L) 14 2L



      		L2C(M+L) 15 2X



      		P 16 2P



      		Z-tracking or similar (AS on) 17 2W



      		Y 18 2Y



      		M 19 2M



      		codeless 20 2N



      		(reserved) 21-22
      GPS L5 1176.45 unknown 23



      		I 24 5I



      		Q 25 5Q



      		I+Q 26 5X



      		(reserved) 27-31





      GLONASS G1 1602.00+k*9/16 unknown 0



      		C/A 1 1C



      		P 2 1P



      		(reserved) 3
      GLONASS G1a 1600.995 unknown 4



      		L1OCd 5 4A



      		L1OCp 6 4B



      		L1OCd+L1OCp 7 4X



      		(reserved) 8-9
      GLONASS G2 1246.00+k*7/16 unknown 10



      		C/A (GLONASS M) 11 2C



      		P 12 2P
      GLONASS G2a 1248.06 unknown 19



      		L2OSI 20 6A



      		L2OCp 21 6B



      		L2OSI+L2OCp 22 6X



      		(reserved) 23-31
      GLONASS G3 1202.025 unknown 13



      		Data 14 3I I



      		Pilot 15 3Q Q



      		Data+Pilot 16 3X I+Q



      		(reserved) 17-18





      Galileo E1 1575.42 unknown 0



      		A PRS 1 1A



      		B I/NAV OS/CS/SoL 2 1B B OS data



      		C no data 3 1C C OS pilot



      		B+C 4 1X



      		A+B+C 5 1Z
      Galileo E5a 1176.45 unknown 6



      		I F/NAV OS 7 5I



      		Q no data 8 5Q



      		I+Q 9 5X
      Galileo E5b 1207.14 unknown 10



      		I I/NAV OS/CS/SoL 11 7I



      		Q 12 7Q



      		I+Q 13 7X
      Galileo E5a+b 1191.795 unknown 14



      		I 15 8I



      		Q 16 8Q



      		I+Q 17 8X
      Galileo E6 1278.75 unknown 18



      		A PRS 19 6A



      		B C/NAV CS 20 6B



      		C no data 21 6C



      		B+C 22 6X



      		A+B+C 23 6Z



      		(reserved) 24-31





      SBAS L1 1575.42 unknown 0



      		C/A 1 1C



      		(reserved) 2-5
      SBAS L5 1176.45 unknown 6



      		I 7 5I



      		Q 8 5Q



      		I+Q 9 5X



      		(reserved) 10-31





      Beidou B1 1561.098 unknown 0 Formerly B1/E2



      		I 1 2I



      		Q 2 2Q



      		I+Q 3 2X
      Beidou B2 1207.14 unknown 4 Formerly B2/E5b



      		I 5 7I



      		Q 6 7Q



      		I+Q 7 7X
      Beidou B3 1268.52 unknown 8 Formerly B3/E6



      		I 9 6I



      		Q 10 6Q



      		I+Q 11 6X
      Beidou B1C 1575.42 unknown 12



      		Data 13 1D



      		Pilot 14 1P



      		Data+Pilot 15 1X
      Beidou B2a 1176.45 unknown 16



      		Data 17 5D



      		Pilot 18 5P



      		Data+Pilot 19 5X
      Beidou B1A 1575.42 Data 20 1S



      		Pilot 21 1L



      		Data+Pilot 22 1Z
      Beidou B2b 1207.140 Data 23 7D



      		Pilot 24 7P



      		Data+Pilot 25 7Z
      Beidou B2(B2a+B2b) 1191.795 Data 26 8D



      		Pilot 27 8P



      		Data+Pilot 28 8Z
      Beidou B3A 1268.52 Data 29 6D



      		Pilot 30 6P



      		Data+Pilot 31 6Z





      QZSS L1 1575.42 unknown 0



      		C/A 1 1C



      		C/B 5 1E



      		L1C(Data) 2 1S



      		L1C(Pilot) 3 1L



      		L1C(Data+Pilot) 4 1X



      		L1S 30 1Z Also L1-SAIF



      		L1Sb 31 1B



      		(reserved) 6
      QZSS L2 1227.60 unknown 7



      		L2C(M) (data) 8 2S



      		L2C(L) (no data) 9 2L



      		L2C(M+L) 10 2X



      		(reserved) 11-12
      QZSS L5 1176.45 unknown 13



      		I 14 5I Block I+II



      		Q 15 5Q Block I+II



      		I+Q 16 5X Block I+II



      		L5S(I) 25 5D Block II L5S



      		L5S(Q) 26 5P Block II L5S



      		L5S(I+Q) 27 5Z Block II L5S
      QZSS L6 1278.75 unknown 19 LEX



      		L6D 20 6S Both Blocks, Formerly S (data)



      		L6P 21 6L Block I LEX, Formerly L (no data)



      		L6(D+P) 22 6X Block I LEX, Formerly S+L



      		L6E 23 6E Block II



      		L6(D+E) 24 6Z Block II



      		(reserved) 17-18,28-29
      IRNSS L5 1176.45 unknown 0



      		SPS BPSK(1) 1 5A



      		RS BOC(5,2) Data 2 5B



      		RS BOC(5,2) Pilot 3 5C



      		RS BOC(5,2) Data+Pilot 4 5X
      IRNSS S-band 2492.028 unknown 5



      		SPS BPSK(1) 6 9A



      		RS BOC(5,2) Data 7 9B



      		RS BOC(5,2) Pilot 8 9C



      		RS BOC(5,2) Data+Pilot 9 9X



      		(reserved) 10-31


      *    The observables for the QZSS L1-SAIF are proposed to be stored with the PRN of the other observables for the same SV, i.e. QZSS L1-SAIF PRN 183 is stored with a PRN value of 193, and so on.

      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: 2023-08-31  17:24:35  America/Denver