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 Use with TEQC

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


Index:
BINEX homepage
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: GAGE BINEX contact


Overview of teqc and BINEX:
You may already be familiar with the teqc engine; if not, please see the teqc homepage. Basically, teqc allows the user to read a wide variety of native receiver formats and convert (i.e. translate) to RINEX ASCII format; perform a variety of editing tasks, like modifying RINEX metadata (e.g. header information); and/or quality check GPS, GLONASS, and/or SBAS observation data. Except when doing using the quality check (qc) mode and a few other specialized cases, the default output of teqc is RINEX. With the addition of BINEX read/write capability, this is still true. New teqc options have to used to allow the outputting of BINEX, and sometimes for the reading of BINEX. It is the use of these options that will be discussed on this page, along with links to actual files so the user can experiment on their own. (But be careful: some of these links point to binary data files.) Please be informed that the teqc commands will only work on versions of teqc on or after ~1 July 1999. (To find which version of teqc you are using, execute:
    teqc +id
and examine the version line.)

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.

Conversion of Ashtech RS-232 Stream Data to BINEX with teqc:
Assume that you have an Ashtech RS-232 file with MBEN, PBEN, and SNAV records, by way of example doug1610.r03. (The Ashtech header fields of the records should start with ASCII strings like $PASHR,MPC,, $PASHR,PBN,, and $PASHR,SNV,. You can check this by executing and examining the "frame" and "type" values.) Note: PBEN records must follow each block of MBEN records in order for teqc to correctly read Ashtech RS-232 format (whether converting to RINEX, BINEX, or any other use). In general, the teqc option -ash s can be used to specify that that input stream (stdin) or file(s) are Ashtech RS-232 stream format, though this is sometimes not necessary if the file starts cleanly with the start of a valid Ashtech stream record.

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 single line:
    week: 909
is returned to stdout, indicating that the data probably start on GPS week 909 for this file.

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:

where one could also substitute +binex 0x7f with +binex 127, with the same result. Ashtech SNAV records are converted to BINEX record ID = 0x01 automatically, and are contained within doug1610.r03.bnx.

Now, one little (pun intended!) matter: doug1610.r03.bnx 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 doug1610.r03.BNX. (By the way, I am not proposing a file naming convention here. Name the BINEX files astaire and rogers --or rogers and astaire. It doesn't matter.)

Conversion of BINEX to RINEX with teqc:
It will probably be a while until BINEX readers exist as direct front ends on most processing packages. In the meantime, you can convert BINEX to RINEX using teqc. Like with other native formats, you may have to tell teqc that you are inputting BINEX, using the new -binex option (i.e. read as: "inputting BINEX"). If you are familiar with teqc, the following command will then make immediate sense to you at this point: where here the RINEX observables L1, L2, C1, P1, and P2 are being extracted. The astute reader may ask at this point, "Which L1?", since the BINEX file contains both L1(CA) and L1(P1). The answer here is L1(P1). This is analogous to the default behaviour of using teqc create RINEX directly from the Ashtech file, i.e. where L1(P1), rather than L1(CA), is extracted as RINEX L1. In order to extract L1(CA) as RINEX L1, add the extra option +CA_L1 (i.e. read as "use L1(CA)") to either of the above two commands. (Note: You can't get both L1(CA) and L1(P1) in a RINEX file, since the RINEX specification currently only allows one L1 observable. But, this may change in the future!)

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, doug1610.r03.obs, to the RINEX OBS file created directly from the Ashtech stream file, doug1610.r03.97o. 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.

Conversion of BINEX Endian-ness with teqc:
One of the beauties of BINEX is that the record endian-ness can be optimized for a particular processor endian-ness, but if BINEX software is written correctly, it really doesn't matter, since any byte-swapping required is mere noise in reading a BINEX record. But, if you want, you can change the endian-ness of a BINEX file by using teqc.

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.

The BINEX that you get with either operation is identical to what you would have gotten if you had created BINEX direct from the Ashtech stream file on that processor in the first place.
 

Last modified: 2023-05-12  13:22:24  America/Denver