Convert To Rinex Download |WORK|

[Virgen Vanier]

Time Binning with Option tbin

You can also invoke a time binning style of auto-windowing with option -tbin. The -tbin option is only available in versions of teqc made on or after 18 July 2008. This is a powerful option to create batches of RINEX or BINEX output files in various lengths, e.g. daily, 8-hour, hourly, 30-minute, 15-minute, 5-minute, ..., from one or more input files (manufacturers' formats, RINEX, or BINEX, and as usual, the input files all have to be of the same type). The -tbin option can create smaller output files than the input files (e.g. hourly files from daily files), and it also makes long files from several shorter files. It can use mixed length input files. So, the input might be a list of files of varying lengths, some shorter than a day, and the output could be binned into daily files. Two options are used for time binning. The first and required option is -tbin which has two arguments, such as -tbin 1h myfile. The first and required argument, such as 1h, is the time duration for each bin (output file). The trailing letter specifies time units: s for seconds, m for minutes, h for hours, d for days. You must use d, h, m, or s. Time durations in sub-seconds are allowed: if sub-seconds are indicated, then resulting filenames will expand to include an additional ".ddd" after the seconds value showing the time down to milliseconds. Any value for the time duration is allowed: caveat emptor! If you type 1s and the input data is most of a day long, you are asking for tens of thousands of files to be made. The second argument for -tbin, such as myfile, is the prefix part of the output filenames. The prefix can be a 4-char ID, or some other printable string without whitespace. The output filenames have the form == prefix + doy-of-year, where the filenames themselves would be:a) 0.yyo if delta (bin time duration) in days is an integerb) a.yyo - x.yyo if case (a) doesn't work, but24/(duration in hours) results in an integer hour, with the hour indicated by a letter from a to x:a = start in hour 0, ..., x = start in hour 23c) [a-x]00.yyo - [a-x]59.yyo if cases (a) and (b) don't work,but 60/(delta in minutes) results in an integer00 = start in minute 0, ..., 59 = start in minute 59d) [a-x][00-59]00.yyo - [a-x][00-59]59.yyo if cases (a)-(c)don't work, but 60/(delta in seconds) results in an integer (or maybeall remaining cases as well ...)00 = start in second 0, ..., 59 = start in second 59In a teqc command like

teqc -tr d +obs + +nav + -tbin 1h mytbinfile inputdatafile

the extra bare + signs after +obs and +nav mean make a sequence of obs and nav files which match the 1 hour time bins made with the -tbin 1h temp arguments. The + argument after the +obs and +nav options only has meaning when using the -tbin option. If you tried that without -tbin you'd end up with a file named + . The option +nav +,+ means make separate NAVSTAR GPS and GLONASS nav files for the time bins, butthis syntax can also be extended to also include SBAS, Galileo, Beidou/Compass, QZSS, and IRNSS -- in that order.For example, a command to translate from Trimble to RINEX

teqc -tr d +obs + +nav myfull.nav -tbin 1h myhourly grnr2600.dat

will put all the GPS nav messages into one file myfull.nav, but the RINEX obs are tbinned as hourly files:
teqc: creating file myhourly260a.97o ...
teqc: creating file myhourly260b.97o ...
teqc: creating file myhourly260c.97o ...This example may be what you want if the tbin window is shorter than about 2-4 hours. Recall that the -tr d part is not required when the input file is a Trimble DAT/ION/EPH/MES download fileset (dat file) file.There is a second option, -ast, aligned start time, which may be used with -tbin to specify the start time of the first bin. This option is not required for time binning. If no -ast option is specified, time binning uses a default alignment starting at 00:00:00 on the first data (obs, nav, or met). Option -ast - or -ast _ means start alignment to the first epoch that is output; -ast [[[[[[YY]YY]MM]DD]hh]mm]ss[.sssss] means start alignment at the specified time. Sub-seconds may be used with -ast.Note the common and different option -st is reserved to mean when to start the data, which by default is the first epoch found. Don't confuse -ast and -st.Option tbin works for all these cases:N manufacturer's format or BINEX files -> M RINEX filesets
N RINEX files of same type -> M RINEX files of same type as input
N manufacturer's format or BINEX files -> M BINEX files
N RINEX filesets -> M BINEX filesThe RINEX filenaming scheme with tbin is:daily = 0.[onghem]
hourly = [a-x].[onghem]
minute = [a-x]00.[onghem] - [a-x]59.[onghem]
second = [a-x][00-59]00.[onghem] - [a-x][00-59]59.[onghem]
subsec = [a-x][00-59]00.000.[onghem] - [a-x][00-59]59.999.[onghem]where -- user supplied
== day of year
[a-x] for hours 00 - 23
== year modulo 100
[onghem] -- RINEX suffix, e.g. 'o' for RINEX obs file, etc.Note that teqc should select the coarsest filenaming binning in order to do what you've asked. Which filenaming binning is used depends on the -tbin unit selected or the -ast time unit. For example if using the default -ast (i.e. not explicitly specified) and using -tbin 30m test, then the minute filenaming binning is used; but if -tbin 1h test or -tbin 60m test, then the hourly filenaming binning is used. For creating RINEX with time-binning, you have pretty good control over which files end up being created with time-binned names; e.g.:+nav temp.gps,temp.glo +obs + -tbin 1h temp == all GPS nav messages go into RINEX file temp.gps and all GLONASS nav messages go into RINEX file temp.glo (in other words, neither are time binned), but all RINEX obs files are time-binned (to 1-hour in this case)+nav +,temp.glo +obs + -tbin 60m temp == all GLONASS nav messages go into RINEX file temp.glo, but all RINEX GPS nav files and all RINEX obs files are time-binned (again, to 1-hour)+nav +,+ +obs + +met + -tbin 3600s temp == all RINEX (GPS and GLONASS nav, obs, and met) files are time-binned (and again, to 1-hour)+tbin 3600s temp is a short-hand for the previous command (notice the + in +tbin), i.e., all RINEX files are time-binned.The only difference to create time-binned BINEX is to use the +binex option (which takes its usual argument), and the resulting BINEX files will be named differently from time-binned RINEX: = prefix + GPS week + '_' + day_of_week (Sun=0,...,Sat=6)daily = .bnx
hourly = [a-x].bnx
minute = [a-x]00.bnx - [a-x]59.bnx
second = [a-x][00-59]00.bnx - [a-x][00-59]59.bnx
subsec = [a-x][00-59]00.ddd.bnx - [a-x][00-59]59.ddd.bnxExamples of tbin usage:1) You want the input broken up into daily files and the created obs filenames to start with test:

teqc -tr d +obs + -tbin 1d test input.obs

If, say, the data started on day 2007:165, the output files would be named:
test1650.07o
test1660.07o
test1670.07o
test1670.07o
...
No nav files are made.2) You want the input broken up into files of 1/12 sidereal days with filenames starting with sidx, and you want the first file to be time aligned to 00h30m09s (GPS time, as usual) of the first day of data, andyou want the data to start at 01h30m10s in the first file; use:

teqc -tr d +obs + -tbin 7180.3409 sidx -ast 00:30:09.000 -st 01:30:10 input.obs

If the data started on day 2007:165, then the output files would be named:sidx165a3009.07o (but data here doesn't start in file until 01:30:10)
sidx165c2950.07o
sidx165e2930.07o
...Note that a sidereal day is 23h 56m 4.091s, so 1/12th is 7180.3409 seconds.3) With an input of one Topcon TPS file, cp_1p.tps the command

teqc cp_1p.tps

translates the input to RINEX as a single stream to stdout.To create hourly time-binned RINEX obs files, and distinct nav files for GPS and GLONASS, use:

teqc +nav +,+ +obs + -tbin 1h temp cp_1p.jps

creating temp027m.03n ...
creating temp027k.03o ...
creating temp027k.03g ...
creating temp027l.03o ...
creating temp027l.03g ...
creating temp027o.03n ...
creating temp027m.03o ...
creating temp027m.03g ...4) If you want the nav messages in a single RINEX nav file (temp0270.03n) for GPS and a single RINEX nav file (temp0270.03g) for GLONASS, with time binning making 1 hour obs files:

teqc +nav temp0270.03n,temp0270.03g +obs + -tbin 1h temp cp_1p.jps

creating temp027k.03o ...
creating temp027l.03o ...
creating temp027m.03o ...
creating temp027n.03o ...
creating temp027o.03o ...
creating temp027p.03o ...5) Use of the +tbin short-hand

teqc +tbin 1h mytbinfile grnr2600.dat

is a short-hand for

teqc +nav +,+ +obs + +met + -tbin 1h mytbinfile grnr2600.dat

Notice the +tbin instead of -tbin.6) BINEX example with +tbin

teqc +binex 0x7f-03 +tbin 15m tmp input.obs

! Notice ! using RINEX OBS default observable list
! Notice ! using RINEX MET default observable list
teqc: creating file tmp1488_1a00.bnx ...
teqc: creating file tmp1488_1a15.bnx ...
teqc: creating file tmp1488_1a30.bnx ...
teqc: creating file tmp1488_1a45.bnx ...The options +obs, +nav, or +met will not be required with the -tbin option in new versions of teqc, if the input target files are RINEX (but if the input is more than one file, the input files still all have to be of the same type). This simplified command syntax choice will be in the next full release after September 2009.Splicing with teqc
Section 14.

Recall that executing the command

teqc fbar0010.97o

basically spews the contents of fbar0010.97o back out to stdout. Supposeyou have the RINEX OBS files fbar0010.97ofor 1 Jan 1997 and fbar0020.97ofor 2 Jan 1997 and you want to combine them into a single RINEX OBS file.It would have been easy if the RINEX standard had been written so that twoRINEX files could be simply concatenated to one another to produce a newvalid RINEX file, a la the UNIX cat system command:

cat fbar0010.97o fbar0020.97o > oops0010.97o

But, alas, the RINEX standard does not allow this sort of obvious simplicityand thus the file oops0010.97o is generally useless.

However, teqc takes care of the RINEX-idiosyncraticboundary between the two files. Thus

teqc fbar0010.97o fbar0020.97o > good0010.97o

or using regular expressions (most UNIX shells)

teqc fbar00[12]0.97o > good0010.97o

produces a valid RINEX file, good0010.97o, with an added comment at the boundary:RINEX FILE SPLICE COMMENT(Note: This splice comment occurs only in a spliced RINEXOBS file, since the current RINEX standard does notallow for comments after the headers of RINEX NAVand RINEX MET files.)Multiple files can be spliced together and any of them can be for any sessionlength. However, the order (like always) must be time-sequential.Header information from files after the first on are winnowed to preserveonly pertinent parts, and this can be further reduced by including the-phc = delete post-header comments option, e.g.

teqc -phc fbar00[12]0.97o > good0010.97o

Receiver clock reset information is not carried across the splice boundaryof RINEX OBS files. Thus if there are millisecond receiver clock resets inthe first file OBS file, and the second OBS file has these millisecond resetsinitialized back to zero, there will be a n-millisecond receiver clock jumpat the boundary of the OBS splice.

If desired, you can combine the window and splice operations in a single command.Use any of the windowing options in combination withthe splice procedure.

Translating with teqc
Section 15.

teqc is being enhanced to handle a number of native binary formatsfrom various receivers. For now, teqc handles common formats formany dual-frequency (L1 and L2) and a few single-frequency (L1) receivers.The general use of teqc for all native binary formatsis similar. You need to specify three things:

1. the general type of receiver
2. the general type of native binary format from this receiver,
3. what you are interested in extracting.

(The big-endian/little-endian problem of the different binary formats isautomatically handled by teqc, so don't worry about it.)

Teqc also reads non-native formats, at the present time limitedto the RINEX format, the ARGO format, and BINEX. As you have probablyalready determined, the RINEX format is assumed by default. To forceteqc to interpret the input in the other non-native formats, use:

• -binex for BINEX
• -rtigs for the IGS RTigs format
• -soc for the JPL Soc format
• -argo for the ARGO format

(Note: there is no corresponding -rinex flag for RINEX since thisis always assumed to be the default.)

For native or receiver specific formats, an option flag may be needed to specifythe general type of receiver, and its argument is used to specify the receiver format:

• -ash for Ashtech
• d -- B/E/S/D download fileset (B-file required)
• s -- RS-232 stream format
• r -- R-file
• u -- U-file (note: -ash u is always required for a U-file)
• -leica for Leica
• lb2 -- LB2
• mdb -- MDB
• d -- DS download fileset (OBS file required)
• -topcon for Topcon
• tps -- TPS format
• -javad for Javad
• jps -- JPS format
• -septentrio for Septentrio
• sbf -- Septentrio Binary Format
• -nct for Navcom Technology
• b -- Navcom binary format
• -tr for Trimble
• d -- DAT/ION/EPH/MES download fileset (dat file required)
• s -- RS-232 RT17 stream format
• tsip -- TSIP
• -aoa or -jpl for a TurboRogue/TurboStar or Benchmark receiver
• cb -- ConanBinary
• tb -- TurboBinary
• -cmc for Canadian Marconi Corporation
• allstar -- Allstar format
• -ublox for u-blox
• ubx -- UBX format
• -motorola for Motorola
• oncore -- Oncore format
• -rock for Rockwell
• z -- Zodiac format
• -ti for Texas Instruments
• g -- TI-4100 GESAR and BEPP/CORE formats
• rom -- TI-4100 ROM format

For translation to RINEX, the user can specify what type file is of primaryinterest; if none is specified, RINEX OBS is assumed.For example, using either the receiver argument (i.e. format specification)or appending an o onto the end of format specification means toextract OBS by default, and so on:

• -tr d or -tr -do: translation of Trimble DAT to RINEX OBS
• -aoa cbn: translation of ConanBinary to RINEX NAV
• -ash rm: translation of Ashtech R-file to RINEX MET

Suppose, for example, that the file fbar.bin contains thethe Trimble RT17 for GPS week 866, 11 Aug 1996 - 17 Aug 1996 from aTrimble SSE receiver. Then, execute

teqc -tr s -week 866 +nav fbar2240.96n fbar.bin > fbar2240.96o

Let's dissect the command line. First the -tr option flag tellsteqc that the target file(s) are from a Trimble receiver.The argument to -tr is s (equivalent to just so), which tells teqc that thenative format is the RS-232 RT17 data stream and that you want to send translatedRINEX OBS to stdout. But the RT17 file fbar.bin, in general, is allowedto contain both record types for both GPS observations and ephemerides.The command line option +nav fbar224.96n tells teqc to dump any ephemerisinformation in fbar.bin to the RINEX NAV file fbar2240.96n;if there were no ephemeris records in fbar.bin, then fbar2240.96n will beempty after execution is complete.

If you had had a Trimble *.dat file, fbar.dat, the analogous command line wouldhave been:

teqc -tr d -week 866 +nav fbar2240.96n fbar.dat > fbar2240.96o

Now, what about the option -week 866 (or using an alternative formatof -week 96:224)? By doing this, you are explicitlytelling teqc that the observation data starts in GPS week 866;it may run on into GPS week 867 (or later), but teqc will track this. If youhad executed the shorter command

teqc -tr s +nav fbar2240.96n fbar.bin > fbar2240.96o

during the week of 11 Aug 1996 - 17 Aug 1996, and your CPU system time hadbeen set corrected, then teqc would have computed the GPS week and used that(after issuing a warning to stderr: recall executing just

teqc

is one way for you to find out what GPS week teqc thinks it is).

Why must the GPS week be specified? It turns out that there is no information in theTrimble RS-232 GPS observation records (and some other native formats) to indicate whichGPS week it is from; this is ancillary information that must be recorded external tothe contents of the observation records. (There is GPS week informationin the Trimble ephemeris records, but there is no guarantee that there will beany ephemeris records in an arbitrary RT17 data segment, let alone anephemeris record in advance of all observation records.A similar argument applies for Trimble *.dat files: there is no GPS week informationin Trimble's DAT observation records--though the GPS week appears in other records whichare usually in a *.dat file. Additionally, when using teqc with DAT files astarget files--not stdin--teqc will attempt to find a name-matching MES fileto help resolve the GPS week problem. But, again, there is no guarantee that amatching MES file is present.)

Incidentally, the GPS week can be supplied by several formats when using the-week option:

-week WEEK (WEEK = GPS week, e.g. -week 866)
-week [YY]YY:DOY (YY = year, DOY = day of year, e.g. -week 96:228 or -week 1996:228)
-week [YY]YY:MM:DD (YY = year, MM = month, DD = day, e.g. -week 96:8:15 or -week 1996:8:15)

You can also use a / (slash) as the delimiter instead of a : (colon).Remember: you are specifying the GPS week when the data begins.

All or part of the RINEX header field PGM / RUN BY / DATE is filled inautomatically by teqc during translation. The program field is filled inwith the name of the executable (teqc in this case) and its current versionnumber.

The date is filled in by a query of the system time, and we are assumingthat the system time is set correctly. On UNIX systems, this date is UTC,which is then written to the RINEX file. On Microsoft systems, this datemay or may not be UTC. For Microsoft Windows 95/98/NT systems,the date should be set according to a specific time zone, or witha known offset between local time and UTC. For these cases, the dateobtained should correctly be UTC.

For Microsoft DOS or Windows (or Windows 95/98/NT/2000/XP, in case teqccannot determine the OS), teqc will query for the environment variable$UTC_MIN_OFFSET, which if set, should contain the numerical value of minutesthat should be added to the system time to yield UTC. The switches betweenDaylight Saving Time and Standard Time will have to be done manually.If this environment variable is not set, the system time will be queriedand put into the date field as "Lcl" = Local time.

Now examine the command line:

teqc -tr sn -week 866 +obs fbar2240.96o fbar.bin > fbar2240.96n

Here the argument to the -tr option flag is sn, i.e. your main interestis the ephemeris information in fbar.bin, which is dumped to stdout as aRINEX NAV file (and here redirected to the file fbar2240.96n). The+obs fbar2240.96o option instructs teqc that if any observation recordsare encountered in the target fbar.bin, they are to be decoded and writtenas a RINEX OBS file fbar2240.96o. Again, the option -week 866 is neededto determine the epochs of the observation data, not the ephemeris data.

Again, the analogous command line for a Trimble *.dat file would be:

teqc -tr dn -week 866 +obs fbar2240.96o fbar.dat > fbar2240.96n

If you execute the above commands for the RS-232 file fbar.bin and do not have the environment variables$teqc_OPT or $teqc_CONFIG set (or if you do have them set but they do not containany -O.* or -N.* header modification options), then you will find that mostof the RINEX header fields in fbar2240.96o and fbar2240.96n are blank.Why? Like the GPS week in RS-232 observation records, there are no fields in the TrimbleRS-232 data records to hold the type of information that would occupy theseRINEX fields. About the only fields that are filled automatically by teqcare those for the initial RINEX VERSION / TYPE record (which are implied),the default WAVELENGTH FACT L1/2 record (implied by the receiver type,in this case), and the # / TYPES OF OBSERV record. However, you can overridethese blank values by specifying your own -O.* and/or -N.* optionsusing the command line, $teqc_OPT, $teqc_CONFIG, or other configuration files.This is using teqc simultaneously in edit and translate modes.

The above translation procedure can also be windowed. Currently, though,fast search algorithms have not been written for any binary format,so you must use an explicit windowing (windowing options(6), (7), or (8)) or specify the window delta time from the start(windowing option (2)).

The translation procedure can also be qc-ed. Here let's assume thatyou have a Trimble *.dat file called fbar.dat. For the normal type of qcoperation, try something like:

teqc +qc -week 866 [-st 960811000000] +dh 24 -tr d \
+obs fbar2240.96o +nav fbar2240.96n fbar.dat more

where now, stdout will contain what you now expect from a qc-mode execution,but the RINEX OBS file is still being output to the file fbar2240.96o usingthe option flag +obs. The -st option is optional, indicated by the squarebrackets. You use the explicit windowing (in this example,windowing option (7) using both the-st option and the +d* option).

If translating to RINEX OBS,an auto-identification feature of teqc may eliminate the need tospecify the input format. The auto-identification feature has been developed forall the above formats except the Ashtech U-file (which always requires -ash u).To make sure that teqc is able to identify a particular file, usethe +mdf option. Thus:

teqc +mdf fbar.dat

should return

probable format of fbar.dat: Trimble download
teqc: ... exiting

The assumed stdout for any translation is always RINEX OBS. Thereforewith the auto-identification:

teqc -tr d trimble.dat > RINEX_OBS

can be reduced to:

teqc trimble.dat > RINEX_OBS

The auto-identification will work most of the time but is not guaranteed!This is because the auto-identification is based on reading only a small number ofbytes (usually only 1-4 bytes) at the beginning of the file.This is probably most useful if you are testing files manually on the commandline. For use of teqc in scripts, use explicit receiver/format options.

To review, there are a few things to remember when using binary data:

1. You may need to specify the record type of primary interest, e.g. usingthe -tr option for Trimble data, with a d argument for download(*.dat) format or s for RT17 stream format. If not doing a qc mode, theRINEX file type that corresponds to this record type is dumped to stdout,e.g. if -tr do is used, RINEX OBS file information is dumped to stdout.(For most cases when doing qc mode, qc information is dumped to stdout.)
2. You should specify the GPS week during which the binary stream starts, oryou accept your computer system version of the local time from which the GPSweek is computed. For most formats, you might first try leaving offthe -week option, though occasionally the record containing the initialGPS week is corrupted, bogus, or missing, and (depending on the situation) teqcmight try to use the system time for the GPS week. Additionally, some Trimble MESfiles have been found that contain strange years like "19116"!.
3. If doing a qc mode, you must supply some information about the length ofthe time window of interest, using either the +d* flag, or one of theexplicit window options (6) - (8). If doing theformer, the time of the first data observation becomes the start time of thewindow. The partial argument format for the -st and/or -eoptions also work.
4. If doing a qc mode, stdout is used to dump a copy of the short report segment.In order to capture the RINEX file type that would have gone to stdout ifnot doing a qc mode, specify the RINEX file name by using a +obs, +nav,or +met option.

Also, the time binning option can be used during translation. For translation problems, etc., contact teqc technical contact for help.

Special Translator Considerations and Options
Section 16.

There are some translator options which are not specific to a particularnative binary format. There are

-L2 to indicate an L1-only (no L2 tracking) receiver
-P to indicate a P-codeless receiver

Using these options when needed helps set the default set of RINEXOBS observables. For receivers that are bothL1-only and P-codeless, use both -L2 and -P.

Two useful options that can be used anytime, but are sometimes veryhelpful prior to translating, are the metadata extractions options+meta and +mds--which also work with RINEX as the targetfiles. For example,

teqc +meta trimble.dat

should return a 19-line metadata summary about the Trimble DAT file trimble.dat(assuming that the auto-identify function works correctly). Executing

teqc +mds trimble.dat

returns "metadata short"--a shorthand for just the start and end times of the file, plusthe file size in bytes. If either of these terminate in a line like:

week: ####

this is an indication that you should use the -week option to set the startingGPS week to the indicated value, e.g.

teqc -week #### +meta trimble.dat

There are several translator options which are specific to a particularnative binary format.

• Trimble *.dat or RT17 Data Formats
  

There is a set of options to remove half-wavelength phase data (squaring mode)from the translated RINEX OBS file. These are -L1_2 or -L2_2 to removesquared L1 or squared L2, respectively. Of the types of binary data thatteqc currently handles, the only types where these flags may be of useis with the Trimble *.dat or RT17 data stream formats.

Also, when translating *.dat from P-codeless receivers (e.g. SD, STD, SST), you probablywill have to use the -P option. This informs teqc that the datahas no P-codes, and it performs bit-cleaning on certains flags. Without thisbit-cleaning, you are likely to only get the L2 observable.

When using the newest generation of receivers (e.g. SSE, SSi, 4700, 5700), a fewepochs of squared L2 data for a particular SV may be reported. Normally, theseepochs are translated with the appropriate bit-1 of the LLI flags added tothe RINEX OBS file with the (squared) L2 data (seeteqc's handling of wavelength factors for moreinformation). These L2 observables can be entirely removed during translationby using the option -L2_2, i.e. no squared L2 data is passed to theRINEX OBS file.

When using a Trimble DAT file as a target file (and not stdin), teqc attempts to finda Trimble MES file with the same path and name prefix. The name matching uses:

*dat-> looks for *mes*DAT-> looks for *MES

If a matching MES file is found, it is read to obtain the starting GPS week andcertain metadata (though there is no guarantee that this information is correct).

• ConanBinary:
  

Teqc should not be used to translate ConanBinaryfrom the early Rogue receivers. The data in this type of ConanBinary is SV-ordered, ratherthan time-ordered, and teqc will only translate the first SV PRN numberof data. (Use JPL translators for this type of ConanBinary.) For ConanBinaryfrom the TurboRogue/TurboStar and Benc