Overview of teqc and BINEX
Conversion of Ashtech RS-232 stream data to BINEX with teqc
Conversion of BINEX to RINEX with teqc
Conversion of BINEX endian-ness with teqc
Contact: UNAVCO data guru
At the present time, teqc has been modified to read/write a specific
subset of cases for BINEX record IDs
0x01 (GNSS navigation information) and
0x7f (GNSS observation data prototyping).
The translation aspects of teqc to these record IDs have so for been
prototyped for the conversion of Ashtech Z-12 real-time RS-232 data streams
containing MBEN/PBEN/SNAV records. But, it should not take very much additional
work to have teqc conversion to BINEX work for other Ashtech
receivers and formats, including the GLONASS receivers (Z-18 and GG24).
The 0x01 and 0x7f BINEX records should readily lend themselves to
TurboBinary data from TurboRogue and Benchmark/ACT receivers. In fact,
the design of these BINEX records was based in part looking in
advance to all of these types of data.
Each MPC record contains three data blocks, one for C/A code data, one for P-code on L1 data, and one for P-code on L2 data. Each of these has a phase and pseudorange value. To convert to BINEX, you have to tell teqc what observables you want to store, just like with RINEX, using the -O.obs option. To get everything possible, use -O.obs la+l1+l2+ca+p1+p2+s1+s2. Most of these are what you would expect from translating to RINEX. In this case, the la means L1(CA), i.e. phase value of the C/A code block, and l1 means L1(P1), i.e. the phase value of the P-code data on L1. (There is a slight difference between L1(CA) and L1(P1) of about 1 cm RMS in the Ashtech data.)
Unfortunately, the GPS week value is not stored in the MBEN/PBEN records, so this information has to be kept track of in some other fashion. If SNAV records are also present, the week information can be extracted/verified from the GPS week information in them, but the week value must be known before correctly before converting to a valid BINEX file. Assuming SNAV records are present, one way of accomplishing this is to execute:
The only item left to know is that you must specify that you want BINEX output rather than RINEX. This is accomplished with the +binex option (i.e. read as: "output BINEX"). Like many teqc options (e.g. -ash), this option takes an argument. Here, you need to specify the main BINEX record ID to be used to store the observables. This can be done in hexidecimal or in decimal. (For now, the subrecord ID is not specified.) For now, store the observables in record ID = 0x7f = 127.
The full teqc command to convert the Ashtech file to BINEX is then:doug1610.r03.bnx.
Now, one little (pun intended!) matter:
is a little-endian BINEX file, created
using a Solaris x86 version of teqc. The same file will be created if another
little-endian version of teqc is used: e.g. Linux on PCs, DOS, Windows, Windows 95/98/NT.
If you use a big-endian version of teqc (e.g. HP-UX, SUN OS, Solaris Sparc, DEC Alpha OFS1,
Silicon Graphics IRIX), then you would have obtained the big-endian BINEX file
(By the way, I am not proposing a file naming convention here. Name the BINEX files
It doesn't matter.)
Another option which may want to be considered for Ashtech data is the new teqc option +Ashtech_qd, used to include all Ashtech data (given the observation list), regardless of the status of the Ashtech "warning flag" byte for each data block. In other words, there are certain bits in this flag which indicate that the pseudorange or phase value may be "questionable". +Ashtech_qd turns off examination of those bits and dumps all the data asked for, "questionable" or not. You may want to use this option with either the above command creating BINEX from the Ashtech stream file, or with the above command creating RINEX from the Ashtech stream file.
You may want to compare the RINEX OBS file created from BINEX,
to the RINEX OBS file created directly from the Ashtech stream file,
You will notice occasional ±0.001 cycle discrepencies in the values for L1 and L2,
but no discrepencies for the pseudorange values for C1, P1, and P2. This is due to
a numerical artifact of double-rounding,
occurring because the BINEX 0x7f-00 phase values are rounded to the nearest 0.0001 cycle,
and these values are rounded again to the nearest 0.001 cycle for RINEX.
If you run teqc on a big-endian processor (e.g. the teqc executable for HP-UX, SUN OS, Solaris Sparc, DEC Alpha OFS1, Silicon Graphics IRIX), then you can convert a BINEX file to all big-endianness (even if the BINEX has some records which are little-endian, and other that are big-endian), e.g.
If you run teqc on a little-endian processor (e.g. the teqc executable for Solaris x86, Linux on PCs, DOS, Windows, Windows 95/98/NT), then you can convert a BINEX file to all little-endianness (even if the BINEX has some records which are little-endian, and other that are big-endian), e.g.
Last modified: Tuesday, 15-Jan-2019 21:14:08 UTC