Convert To Rinex Download ##TOP##

[Analisa Wisdom]

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 loc