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 Use with TEQC
Binary Exchange format for GPS/GLONASS/SBAS
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: UNAVCO data guru
Last modified: 21 July 2004
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:
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:
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 Friday, 21-Jul-2006 23:21:09 UTC
|
unavco.org