Tiger Software Suite provides you with everything you need to utilize your ViewPlus embosser to its full potential. Translate text to Braille directly with VP Formatter and generate industry leading tactile graphics with Tiger Designer. No matter your project, Tiger Software Suite will make you look like a pro for all your Braille needs.
TSS provides powerful Braille translation with intuitive controls directly from Microsoft Word and Excel. Complete with graphics editing software and full ink support, TSS provides everything you need to utilize VP embossers to their fullest potential. Starting with TSS v7.0, TSS is available as a yearly subscription including any updates in addition to the standard perpetual license (one perpetual license complementary with embosser purchase). Perpetual licenses will require paid upgrades while subscription licenses will support future new releases.
Delta Translator 3.0 full full version
Download Zip: https://ssurll.com/2vKmpG
All reported errata to the first edition have been addressed in this addition, and a full change log appears in Appendix F Changes. The diff-marked version linked in the frontmatter highlights all changes between the first and second editions. In addition to incorporating errata, the main change in this addition is to recognise that MathML parsing is also specified in [HTML5] and where necessary to note where HTML and XML usage differ.
No matter how successfully MathML achieves its goals as a markup language, it is clear that MathML is useful only if it is implemented well. The W3C Math Working Group has identified a short list of additional implementation goals. These goals attempt to describe concisely the minimal functionality MathML rendering and processing software should try to provide.
A color is specified either by "#" followed by hexadecimal values for the red, green, and blue components, with no intervening whitespace, or by an html-color-name. The color components can be either 1-digit or 2-digit, but must all have the same number of digits; the component ranges from 0 (component not present) to FF (component fully present). Note that, for example, by the digit-doubling rule specified under Colors in [CSS21] #123 is a short form for #112233.
As the previous examples show, to be useful, the concept of MathML conformance frequently involves a judgment about what parts of the language are meaningfully implemented, as opposed to parts that are merely processed in a technically correct way with respect to the definitions of conformance. This requires some mechanism for giving a quantitative statement about which parts of MathML are meaningfully implemented by a given application. To this end, the W3C Math Working Group has provided a test suite.
The test suite consists of a large number of MathML expressions categorized by markup category and dominant MathML element being tested. The existence of this test suite makes it possible, for example, to characterize quantitatively the hypothetical computer algebra interface mentioned above by saying that it is a MathML-input-conformant processor which meaningfully implements MathML content markup, including all of the expressions in the content markup section of the test suite.
Similarly, superscripts are attached to the full expression constituting their base rather than to the just preceding character. This structure permits better-quality rendering of mathematics, especially when details of the rendering environment, such as display widths, are not known ahead of time to the document author. It also greatly eases automatic interpretation of the represented mathematical structures.
Characters can be either represented directly as Unicode character data, or indirectly via numeric or character entity references. See Chapter 7 Characters, Entities and Fonts for a discussion of the advantages and disadvantages of numeric character references versus entity references, and [Entities] for a full list of the entity names available. Also, see Section 7.7 Anomalous Mathematical Characters for a discussion of the appropriate character content to choose for certain applications.
Note that since the rendering context, such as the available width and current font, is not always available to the author of the MathML, a render may ignore the values of these attributes if they result in a line in which the remaining width is too small to usefully display the expression or if they result in a line in which the remaining width exceeds the available linewrapping width.
The value "northeastarrow" is a recommended value to implement because it can be used to implement TeX's \cancelto command. If a renderer implements other arrows for menclose, it is recommended that the arrow names are chosen from the following full set of names for consistancy and standardization among renderers:
A particularly important case for renderers to handle gracefully is the interaction of alignment elements with the matrix content element, since this element may or may not be internally converted to an expression containing an mtable element for rendering. To partially resolve this ambiguity, it is suggested, but not required, that if the matrix element is converted to an expression involving an mtable element, that the mtable element be given the attribute alignmentscope="false", which will make the interaction of the matrix element with the alignment elements no different than that of a generic presentation element (in particular, it will allow it to contain malignmark elements that operate within the alignment scopes created by the columns of an mtable that contains the matrix element in one of its table cells).
In MathML 3, a subset, or profile, of Content MathML is defined: Strict Content MathML. This uses a minimal, but sufficient, set of elements to represent the meaning of a mathematical expression in a uniform structure, while the full Content MathML grammar is backward compatible with MathML 2.0, and generally tries to strike a more pragmatic balance between verbosity and formality.
In MathML 3, formal semantics Content MathML expressions are given by specifying equivalent Strict Content MathML expressions. Since Strict Content MathML expressions all have carefully-defined semantics given in terms of OpenMath Content Dictionaries, all Content MathML expressions inherit well-defined semantics in this way. To make the correspondence exact, an algorithm is given in terms of transformation rules that are applied to rewrite non-Strict MathML constructs into a strict equivalents. The individual rules are introduced in context throughout the chapter. In Section 4.6 The Strict Content MathML Transformation, the algorithm as a whole is described.
The full algorithm described inSection 4.6 The Strict Content MathML Transformation is complete in the sense that it gives every Content MathML expression a specific meaning in terms of a Strict Content MathML expression. This means it has to give specific strict interpretations to some expressions whose meaning was insufficiently specified in MathML2. The intention of this algorithm is to be faithful to mathematical intuitions. However edge cases may remain where the normative interpretation of the algorithm may break earlier intuitions.
In the text below, descriptions of semantics for predefined MathML symbols refer to the Content Dictionaries developed by the OpenMath Society in conjunction with the W3C Math Working Group. It is important to note, however, that this information is informative, and not normative. In general, the precise mathematical semantics of predefined symbols are not not fully specified by the MathML 3 Recommendation, and the only normative statements about symbol semantics are those present in the text of this chapter. The semantic definitions provided by the OpenMath Content CDs are intended to be sufficient for most applications, and are generally compatible with the semantics specified for analogous constructs in the MathML 2.0 Recommendation. However, in contexts where highly precise semantics are required (e.g. communication between computer algebra systems, within formal systems such as theorem provers, etc.) it is the responsibility of the relevant community of practice to verify, extend or replace definitions provided by OpenMath CDs as appropriate.
External definitions (in OpenMath CDs or elsewhere) may also be specified directly for a csymbol using the definitionURL attribute. When used to reference OpenMath symbol definitions, the abstract triple of (symbol name, CD name, CD base) is mapped to a fully-qualified URI as follows:
The OpenGL ES 3.0 specification[17] was publicly released in August 2012.[18] OpenGL ES 3.0 is backwards compatible with OpenGL ES 2.0, enabling applications to incrementally add new visual features to applications. OpenGL 4.3 provides full compatibility with OpenGL ES 3.0. Version 3.0 is also the basis for WebGL 2.0.[19]The actual is version 3.0.6.[20]
Time Binning with Option tbinYou 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 RINEXteqc -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 filesetsN RINEX files of same type -> M RINEX files of same type as inputN manufacturer's format or BINEX files -> M BINEX filesN 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 = .bnxhourly = [a-x].bnxminute = [a-x]00.bnx - [a-x]59.bnxsecond = [a-x][00-59]00.bnx - [a-x][00-59]59.bnxsubsec = [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.obsIf, say, the data started on day 2007:165, the output files would be named:test1650.07otest1660.07otest1670.07otest1670.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.obsIf 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.07osidx165e2930.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 commandteqc cp_1p.tpstranslates 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.jpscreating 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.jpscreating temp027k.03o ...creating temp027l.03o ...creating temp027m.03o ...creating temp027n.03o ...creating temp027o.03o ...creating temp027p.03o ...5) Use of the +tbin short-handteqc +tbin 1h mytbinfile grnr2600.datis a short-hand for teqc +nav +,+ +obs + +met + -tbin 1h mytbinfile grnr2600.dat Notice the +tbin instead of -tbin.6) BINEX example with +tbinteqc +binex 0x7f-03 +tbin 15m tmp input.obs! Notice ! using RINEX OBS default observable list! Notice ! using RINEX MET default observable listteqc: 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 teqcSection 14.Recall that executing the commandteqc fbar0010.97obasically 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.97oBut, 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. Thusteqc fbar0010.97o fbar0020.97o > good0010.97oor using regular expressions (most UNIX shells)teqc fbar00[12]0.97o > good0010.97oproduces 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.97oReceiver 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 teqcSection 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: the general type of receiver
the general type of native binary format from this receiver,
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, executeteqc -tr s -week 866 +nav fbar2240.96n fbar.bin > fbar2240.96oLet'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.96oNow, 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 commandteqc -tr s +nav fbar2240.96n fbar.bin > fbar2240.96oduring 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 justteqcis 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.96nHere 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.96nIf 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 morewhere 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.datshould returnprobable format of fbar.dat: Trimble download teqc: ... exitingThe 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: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.)
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"!.
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.
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 OptionsSection 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.datshould return a 19-line metadata summary about the Trimble DAT file trimble.dat(assuming that the auto-identify function works correctly). Executingteqc +mds trimble.datreturns "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.datThere 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 *MESIf 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 Benchmark receivers, teqc will work correctly.TurboBinary
TurboBinary data can include normal-rate data (record 0x68), 1-sec rate data(record 0x1a), up to 50 Hz-high-rate data (records 0xdb and 0xdc, plus using informationin record 0x1a), and the so-called "30-1 second" format which is a mix of normal-rate data(record 0x68) and 1-sec LC data (record 0xde). The default translation is to do allthese record types. However, you can tailor your translation with these options: -TBhr leave out high-rate data -TB1s leave out 1-sec data (this also deletes the high-rate data) -TBnr leave out the normal-rate data -TBLC leave out the LC data recordsThe result of various option combinations is: (no options = default) translate all records -TB1s translate only normal-rate data -TB1s -TBhr (same as -TB1s) translate only normal-rate data -TBnr translate 1-sec and high-rate data or LC data (whatever is left) -TBhr translate 1-sec and normal-rate data -TBhr -TBnr translate only 1-sec data -TBLC leave out the LC data records, leaving the normal-rate -TB1s -TBnr translate no observation data (oops!) -TBLC -TBnr translate no observation data (oops!)For TurboBinary data collected with firmware dated before about 1 Dec 92 (version 2.5or earlier), it is necessary to apply a correction to obtain valid pseudoranges.To activate this correction, use the option +TB_ca_fix.For TurboBinary data collected with a Benchmark ACT receiver, you may want totry the -aoa tbY option to generate the RINEX OBSfile. This will use the C/A-derived L1-phase value for the RINEX L1, ratherthan the noisier Y1-codeless derived L1-phase value.Ashtech Data Formats:
For all Ashtech formats except the U-file "data mode 7", the internal "smoothing"corrections to the pseudoranges are not applied by default; specify the option+smooth to turn this on. (The pseudorange smoothing appears to be done by defaultin the Berne ASRINEXO translator and the Ashtech ASHTORIN translator.)For the U-file data mode 7, the pseudoranges are either stored with or withoutthe smoothing corrections applied; there is no way to change this during thetranslation.Also, the RINEX L1 observable from teqc may be noted to vary slightly(by up to 1 cm or so) from the L1 observable reported by other translators. This results from the use of the L1-phase value reported in the P1-code data block,rather than the L1-phase value reported in the C/A-code data block. Preliminarytesting at MIT suggests that the L1-phase value in the P1-code data block results in a slightly lower RMS. For the time being, teqc willcontinue to report this L1-phase value, though you can switch to theL1(C/A) by using the +CA_L1 option.For Ashtech download file sets, teqc may only work correctlyfor "Version: 3" type downloads. For example, the older "Version: 1" and "Version: 2"type downloads will not translate correctly at the present time, and the BerneASRINEXO or the Ashtech ASH2RIN translators should be used, ortry the Ashtech convert.exe program to change the B-file to a Version 3 B-file.A bug in the some earlier firmware for the Z-XII resulted in the millisecond clockresets being applied an epoch too late. If you notice periodic millisecond slips(occurring just prior to the reported clock reset times), try using the option+Ashtech_old_clk_reset during translation. This should remove this receiverfirmware artifact from the data.Wavelength Factors: What teqc Does With ThemSection 17.Wavelength factors, i.e. specifying whether L1 or L2 is being recording ina full-wavelength or half-wavelength (squaring mode), can be done in variousways in RINEX. In short, 1) there is a required RINEX header record WAVELENGTHFACT L1/2 specifying the default wavelength factors for L1 and L2 for all SVs,2) there can be other WAVELENGTH FACT L1/2 records specifying the a differentset of wavelength factors for specific SVs, and 3) there can be the use ofbit-1 in the LLI flag of the L1 or L2 observations to indicate the oppositestate of wavelength factor from the last WAVELENGTH FACT L1/2 record fora specific SV. The possible set of values for any WAVELENGTH FACT L1/2 recordis "1 0", "1 1", "1 2", "2 0", "2 1", and "2 2". Setting bit-1 of theLLI flag indicates a full-wavelength mode if the last WAVELENGTH FACT L1/2 recordfor that frequency and that SV--somewhere earlier in file--was set at "2"(half-wavelength). Likewise, setting bit-1 of the LLI flag indicates a half-wavelengthmode if the last WAVELENGTH FACT L1/2 record for that frequency and thatSV--somewhere earlier in the file--was set at "1" (full-wavelength).The methodology used by teqc is a simple specific subset of all of the possibilitiesfor RINEX, but still retains all the same information. On output (either when translatingfrom native binary formats to RINEX or RINEX to RINEX), only the defaultWAVELENGTH FACT L1/2 header record will appear and only the L1/L2 states of"1 1" or "1 0" are used. In other words, the default setting reported in the RINEXfile header is always full wavelength for L1 and L2 (if present), even for squaring receivers.Specific half-wavelength observations are indicated by setting the appropriate bit-1 ofthe LLI flag on the L1 or L2 observations. Period.During translation, you have the option of excluding all half-wavelength observations.To do this, include either -L1_2 or -L2_2 to exclude squared L1 or L2, respectively.This works either when translating native binary formats to RINEX or during anyRINEX to RINEX operations. The default settings of teqc for wavelength factors are+L1_2 and +L2_2, i.e. include all half-wavelength observations.Basic Commands: A ReviewSection 18.The following examples assume that the shell environment variables $teqc_OPT and $teqc_CONFIGare unset or empty: teqc forces all initialization and reports the current GPS weekbased on the system time teqc +id identification of the teqc version you have, plus other informationlike your computer system time, sent to stderr teqc -help or teqc +help complete option list is spewed to stderr teqc +err my_help_file +help complete option list is spewed to file my_help_file instead of stderr;+err option redirects all stderr to specified file teqc ++config dumps the current configuration to stdout teqc +qc ++config dumps current configuration and default qc settings/values to stdout teqc +v RINEX_file reads the RINEX file RINEX_file and verifies its format; nothing is sentto stdout, though a verification message is sent to stderr teqc ++config RINEX_OBS_file dumps current configuration and OBS headersettings/values of RINEX_OBS_file to stdout (can use RINEXNAV or MET file also) teqc RINEX_file reads and spews RINEX_file (with possibly some slight formattingimprovements) back out to stdout teqc +dh 6 RINEX_OBS_file reads and spews header and first 6 hours of observations ofRINEX_OBS_file back out to stdout teqc RINEX_file_1 RINEX_file_2 reads and splices the two RINEX files RINEX_file_1 and RINEX_file_2back out to stdout as a single RINEX file; target RINEX files should be of the same typeand in time order teqc -O.mo foobar RINEX_OBS_file read RINEX_OBS_file and change monument name to "foobar";edited RINEX OBS file is spewed to stdout teqc +qc RINEX_OBS_file qc of RINEX_OBS_file; automatically searches forname-matching RINEX NAV file;qc short report segment is spewed to stdout;full qc report and qc plot fileswritten to file system teqc ++sym symbol hierarchy of symbol codes andassociated meanings for qc ASCII time plot are spewed to stdout teqc -tr do +nav RINEX_NAV_file trimble.dat translate Trimble dat file trimble.dat; RINEX OBS file spewedto stdout; RINEX NAV file written to RINEX_NAV_file teqc -warn rest of command shut off warnings going to stderr; other functionality remainsUsing teqc in Scripts: Substitution for Batch ModeSection 19.Because teqc is 100% non-interactive, it is very well suited to be used inscripts and to be run in background. In fact, this is precisely the reasonit is designed to be 100% non-interactive. Let's look at a simple scriptto translate Trimble *.dat files to RINEX and then qc the resulting RINEX files:#!/bin/kshfor file in $*doecho $fileteqc -O.int 30 -tr d +nav $file%dat97n $file > $file%dat97oteqc +qc -set_mask 15 -plot $file%dat97o > $file%datqcdone#end of scriptMake sure the script is executable, i.e. execute (in UNIX) chmod 755 script,where script, say, is the name of your script file. To use itscript *.datLet's take a closer look at what is going on when executing this script. The shell expandsthe *.dat on the command line to include all files in the working directory the endwith .dat. Each of these file names are processed by the script. The firstline of the script forces the script to be run in a Korn shell (ksh). Thefirst real part of the script is to merely echo the name of each .dat file.Next, each .dat file is translated, with a sampling interval of 30 secondsbeing inserted into the header. The resulting RINEX NAV andOBS files willhave the same prefix as the .dat file, but will end in 97n and 97o,respectively, rather than dat. Next, the RINEX files are qc-ed, setting theelevation mask to 15 (overriding the default fo 10). Sincewe are not asking for COMPACT plot files (option -plot), only two qc filesare created, again both having the same prefix as the .dat file. The moreobvious one will end with qc, redirected from stdout. This is theshort report segment (about one page in length).The other file created will end with 97S,and is the full report, including--in this case--both the short report segment(just like what went to stdout) and the more detailed long report segment.If you wish to suppress the short report segment in the report (the *.97S file),include a -s on the qc command line. If you don't want anyqc report file, include a -report onthe command line. There is no way to suppress theshort report segment going to stdout bycommand line option, but you can alwaysuse a > /dev/null on UNIX to eliminate the stdout.Obviously, this script (as written) creates RINEX files named correctlyaccording to the Berne naming conversion for *.dat files collected only in1997, though the script will function for most *.dat files.Notice that the GPS week has not been specified. For most *.dat files (at least fromTrimble receivers with recent firmware),one of the first records usually contains the GPS week that the datastarts. If this record is missing or is corrupted, then the resultingRINEX OBS file will probably have the wrong dates for the observations,leading to a poor qc report. For these rare *.dat cases, you must explicitlystate the GPS week using the -week option.Differences between teqc's qc mode and original UNAVCO QCSection 20.This section is only for those who are familiar with the original UNAVCO QC program(which is no longer supported) and are making the transition to the new teqc +qc.Interface Differences:replacement of file qc.inp with teqc command line options, or equivalentformat in environment variable $teqc_CONFIG, or in one or more configuration fileswhich are accessed with the -config filename option; all options have areasonable default value so the user need not be initially concerned with the details
elimination of file qc.fil for batch modes; use a command line script instead
elimination of auxiliary files like qc.tim or qc.sym
roughly,
original QC stdout is like the teqc +qc *.YYSqc report fileoriginal QC *.YYS file is like the teqc +qc stdout(qc short report segment)Internal Differences (or Why the New QC Results Look SlightlyDifferent From the Old QC Results):(nominal) one pass of files in teqc [original QC often required twocomplete passes of each RINEX OBS file]
handling of NAVSTAR GPS, GLONASS, Galileo, Beidou/Compass, QZSS, IRNSS, and SBAS[original QC designed for NAVSTAR GPS only]
well-defined symbol hierarchy for ASCII time plot[original QC had only a partially defined symbol hierarchy]
cubic spline xyz fits of SV orbits for elevation, azimuth estimates[original QC used direct linear fits of elevation, azimuth which wereonly good for stationary antennas and were not smooth; algorithmoccasionally resulted in large errors in azimuth]
improved multipath algorithm
improved detection and reporting of observation data gaps[original QC often did not detect and report long data gapsfor individual SVs, and had no means of reporting shortdata gaps for all SVs]
correct identification of SV data below elevation mask[original QC often falsely reported epochs below elevation maskw/ data, when, in fact, the receiver stopped tracking whenthe SV was well above the elevation mask]
correct count of ionospheric delay slips and "observations per slip"[original QC would count the first observation w/ both L1 and L2as an SV started to be tracked again after it had been observedand then set as an ionospheric delay slip]
satellite elevation and azimuth accounts for WGS 84 ellipsoidal Earth model[original QC assumed spherical Earth model, resulting in elevationerrors up to 1/5 for mid-latitudes]
more accurate tally of expected number of observations for each SV[for some data sets, original QC sometimes reported more observations thanexpected, resulting in "%" values exceeding 100%]
sign of clock resets shown on ASCII time plot[original QC did not shown the sign of the clock reset]
correct reporting of indicators in ASCII time plot[original QC often did not show some clock resets, sometimes incorrectlyshowed a clock reset to occur when there was none, and other minor problemswith indicators]
does not produce any unneeded auxiliary files (like AUXFIL or temp.orb)
Interpreting teqc's qc Mode OutputSection 21.The quality check output from teqc is in two portions,the short report segment and thelong report segment. Theshort report segment include an ASCII time plotand a summary report on various parameters. Thelong report segment gives a more detailed breakdownon some of these parameters either by SV or by elevation (if qc full).Short Report Segment:In the short report segment, one of the most compact pieces of informationfrom a qc output is the ASCII time plot. In this plot, a visual summary ofvarious types of quality indicators are displayed for each satellite asa function of time. The SV PRN number is displayed on both the left and rightside of the plot. The width of the ASCII time plot is controlledby the -w[idth] option, and is normally set to 72, though it canvary from 1 to 255; with a width of 72 and 24-hours worth ofobservation data, each ASCII character "bin" represents exactly 20 minutesof time. Each character shown in each spot in the ASCII time plotis the most significant item of note that took place for all of theobservation epochs represented by that bin, according to a well-definedsymbol hierarchy.A listing of the entire ASCII plot symbol table canbe dumped to stdout by executing:teqc ++symLikewise, a summary of the symbol hierarchy table can be included in the short reportsegment by including a +sym option with any qc-mode run. But in this tutorial,let's take a closer look at the symbols and their hierarchy. The symbols usedon each "SV" line are as follows, with the first symbol having the highestpriority in the symbol hierarchy, decreasing through the list: C a clock slip occurred; a clock slip is an MP1 and MP2 slipthat occurred for all satellites being observed (tracked)and had a value that was the same integral number of millisecondsto a resolution specified by -msec_tol in milliseconds; detectionis turned off with -cl option m similar to a clock slip, but only some (i.e. not all) satellitesbeing observed (tracked) had an MP1 or MP2 slip that was anintegral number of milliseconds, or the integral number wasdifferent for the different satellites; note: if the millisecondslip tolerance is 1e-2 (see -msec_tol), then there is roughlya 2:100 chance that a random MP1 or MP2 multipath slip will betagged as an m, rather than M, 1, or 2 (see elsewherein this table) I ionospheric delay (phase) slip occurred; detection is turned offwith -ion option M both MP1 and MP2 (code) slip occurred, but was not integralnumber of milliseconds; detection is turned off with -mp option 1 only MP1 (code) slip occurred, but was not integral number ofmilliseconds; detection is turned off with -mp option 2 only MP2 (code) slip occurred, but was not integral number ofmilliseconds; detection is turned off with -mp option - for qc full, satellite was above elevation mask, but nodata was apparently recorded by the receiver; for qc-lite(no ephemeris information), the data gap must also be lessthan the maximum specified (see argument of -gap_mx in minutes) + (qc full only) satellite was below elevation mask and acomplete set of phase and code data was collected ^ (qc full only) satellite was below elevation mask and apartial set of phase and code data was collected . phase and/or code data for SV is L1 and C/A only & A/S is off;if qc full, satellite was above elevation mask : phase and/or code data for SV is L1 and P1 only & A/S is off;if qc full, satellite was above elevation mask phase and/or code data for SV is L1, C/A, L2, P2 & A/S is off;if qc full, satellite was above elevation mask * phase and/or code data for SV is L1, P1, L2, P2 & A/S is off;if qc full, satellite was above elevation mask , phase and/or code data for SV is L1 and C/A only & A/S is on;if qc full, satellite was above elevation mask ; phase and/or code data for SV is L1 and P1 only & A/S is on;if qc full, satellite was above elevation mask o phase and/or code data for SV is L1, C/A, L2, P2 & A/S is on;if qc full, satellite was above elevation mask y phase and/or code data for SV is L1, P1, L2, P2 & A/S is on;if qc full, satellite was above elevation mask L Loss of Lock indicator was set by receiver for L1 and/or L2;detection is turned off with -lli option _ (underscore) (qc full only) satellite between horizon and elevation maskwith no data collected by receiver; indicator is turned offwith -hor option ` ' (blank) qc lite: no satellite tracked; qc full: no satellite calculatedto be above horizon (+hor option) or above mask (+hor optionor both -hor and +mask options) (see also -set_hor and-set_mask options)Let's examine a simple example. Suppose that the horizon is setat 0 and the elevation mask is set at 20. Let'salso suppose that the receiver starts tracking a particular satellitewhen it reaches 25 of elevation and continues to trackthe satellite down to 5 of elevation. Let's also assumethat no slips occurred during tracking and that the +hor optionis set. For qc full (SV ephemeris available), the SV symbol trackmight then look something like one of the following:A/S on: _____--oooooooooooooooooo+++++__A/S off: _____--******************+++++__ 1 2 3 4 5 6At time (1), the SV rises above the horizon (0). At time (2), theSV rises above the elevation mask (20), but the receiver doesn'tstart tracking until is rises to 25 at time (3). Between times(3) and (4) all phase and code observables are collected by the receiver(L1, L2, C/A, and P2 for A/S on; L1, L2, P1, and P2 for A/S off). Datacontinued to be collected as the SV dropped below the elevation maskat time (4) until the receiver stopped tracking at an elevation of 5at time (5). The SV finally sets below the horizon at time (6).For qc lite, the above SV symbol track would appear as:A/S on: oooooooooooooooooooooooA/S off: *********************** 1 2 3 4 5 6as teqc as no information about the elevation of the satellite.If the -hor option is set, the above qc full SV symbol tracks wouldthen appear as:A/S on: --oooooooooooooooooo+++++A/S off: --******************+++++ 1 2 3 4 5 6so that you can determine everything you could with +hor set, except forthe rise and set times of the SV at times (1) and (2), respectively. Forqc lite, the SV symbol tracks would remain the same as before, since theoptions -hor and +hor are meaningless.Any additional symbols that occur in an SV symbol track not in the aboveexamples fall into a "not so good" category, though seeing a lot of -symbols in a qc full output is also "not good". Let's take a look in moredetail at what these other indicators might be.The first "not so good" category could generally be considered "missing data".As mentioned above, the worst missing data indicator (qc full only) is the-, which means that the SV was calculated using the supplied ephemeristo be above the elevation mask, but no observation data was present forthis SV. In other words, all data is missing.Following the - "all data missing" indicator are the partial missing dataindicators. For example, if A/S is normally on, seeing ; or , indicatesthat there was at least one observation epoch in that bin where L2 observables(i.e. L2 and P2) were missing. You are unlikely to see a y, as thiswould require a Y-code receiver (capable of tracking P1 while A/S is on).(An exception to this is when qc-ing data from an Ashtech receiver like theZ-XII. The C/A and P1 pseudorange observables are reported for all SVs,regardless of whether A/S is on or off.)If A/S is normally off, seeing : or . indicates that there was at leastone observation epoch in that bin where the L2 observables were missing.A indicates that, for some reason, the receiver could not track P1,even though A/S was off, so the receiver instead recorded the C/A observable.If you are using a P-code (not a Y-code) receiver that reports C/A and P1pseudoranges for each SV at each epoch (like the Ashtech Z-XII), you may want to use the -Y option, which informs teqc that this is data not froma Y-code receiver, and to treat the qc analysis as though from a P-code receiver.Special Treatment of Data from Codeless ReceiversYou may have a data set that was collected with a "codeless" or "squaring"receiver. For these receivers, the pseudoranges P1 and P2 are never recorded,and the default qc report will show that all observations were incomplete,as none of them can have a P2 observation (though C/A is acceptable in placeof the missing P1). Also, the SV symbol tracks for the examples above wouldthen appear as:A/S on: _____--,,,,,,,,,,,,,,,,,,+++++__A/S off: _____--..................+++++__ 1 2 3 4 5 6which (correctly) indicates a lack of L2 and P2, even though the observableP2 is not possible (and thus never present) and L2 may be always present.You can inform teqc that the data is to be interpreted as though it werecollected by a codeless receiver by including a -P option (and, of course,the default option in +P). In this case, the absence of P-codes is ignoredfor statistics and the data indicators change collapse to just two possibilities(from the original eight possibilities): . phase and/or code data for SV is L1, C/A;if qc full, satellite was above elevation mask o phase and/or code data for SV is L1, C/A, and L2;if qc full, satellite was above elevation maskNotice that the A/S state (on or off) is ignored, as this is irrelevant for processingsquared data. Then, when using the -P option, the above SV symbol trackswill appear as:A/S on: _____--oooooooooooooooooo+++++__A/S off: _____--oooooooooooooooooo+++++__ 1 2 3 4 5 6i.e., there is no difference whether A/S is on or off. You will probably seean occasional . data indicator:A/S any: _____--ooo.ooooooo.oooooo+++++__ 1 2 3 4 5 6indicating one or more observation epochs where the observable L2 is missing.A listing of the entire ASCII plot symbol table modified for codeless receiverscan be dumped to stdout by executing:teqc -P ++symOther IndicatorsThe next set of "not so good" indicators are for slips in the observables.A common type of slip is an ionospheric delay (phase) slip indicated by a I symbol.These often occur when the SV is at low elevation, both while rising and setting,so the example SV symbol tracks from above might really appear as:A/S on: _____--Iooooooooooooooooo++I+I__A/S off: _____--I*****************++I+I__ 1 2 3 4 5 6In this example, ionospheric delay slips are detected shortly after the receiver startstracking the SV and as the SV is close to setting.The other common type of slip is for one or both of the multipath (code)observables, MP1 and MP2. Again, these frequently occur at low elevations.There are three symbols: M for slip on both MP1 and MP2, 1 for slipon MP1 only, and 2 for slip on MP2 only. Notice that the multipathslip indicators take a lower priority in the symbol hierarchy,so if an ionospheric delay slip and multipath slip occur at different observationsepochs within the ASCII bin, only the I symbol will be seen (assumingthat the option configuration is +ion and +mp). If you use -ionto suppress ionospheric delay slip detection, the above SV symbol tracks mightnow appear as:A/S on: _____--Mooooooooooooooooo++2+M__A/S off: _____--M*****************++2+M__ 1 2 3 4 5 6Interestingly, the occurrence of ionospheric delay or multipath slips in therecorded observations is not only a function of the antenna environment(meaning all the way back to the transmitting SV), but is also a functionof the specific receiver. Due to internal slip detection and phaseobservables resets, data from some receivers show virtually no ionospheric delayslips and nearly all multipath slips. Other receivers do not reset thephase observables, and show a larger number of ionospheric delay slips thanmultipath slips.The last type of slip is the "n-millisecond clock slip", where the valueof n is usually 1, denoted by the symbol C in the SV symbol track. Thisslip is reported if all SVs being tracked have slips in MP1 and MP2equivalent to the same number of integral milliseconds, to a tolerancespecified by the -msec_tol option. If you set the tolerance to1e-17 (milliseconds), you probably will never see any of these slips.However, the default tolerance is 1e-2 (milliseconds), and with thisvalue the qc mode of teqc seems pretty capable of detecting theseslips if they are present.What does it mean if you see the C symbol in an SV symbol track?There are several causes, some more harmless than others. If theC symbol is preceded by an observation gap (no data collected forany SVs), there may be one or more millisecond clock resets missingfrom the observation epoch time tags. Also, if you use teqc to splicetwo RINEX OBS files together and clock resets occur in the first file,a C will occur at the first epoch of the second file (since the teqcsplice does not modify the observation times in the second file toaccount for the accumulative clock resets in the first file). In othercases, however, if the observation epochs are fairly continuous, andthe C indicator is appearing two or more times in 24-hours of data,there is a strong possibility that the receiver was not healthy.This latter possibility (that the receiver was not healthy) promptedthe inclusion of another slip indicator, the "n-millisecond multipathslip". It was observed that some receivers get so unhealthy that,even though n-millisecond clock slips should be occurring (i.e.,given the specific receiver, no millisecond clock resets are present,even though they were expected) none were being found becausethe multipath slips for different SVs had different millisecondequivalents. In short, the value for n was not a constant for all SVsbeing tracked. In this case, the m symbol is used. There issome probability (roughly about 2 : inverse of millisecond tolerance)that a random multipath slip will be recorded as an m instead ofas a M or 1 or 2; so, treat the occasional m as you wouldany multipath slip. However, if you start to see lots of msymbols, especially if you have seen C symbols being reported inthe data from the same receiver, suspect that the receiver is ailing.The next "not so good" category is presence of data gaps. Thereare really two types of gaps. One is a complete observation gapfor all SVs. This can be caused perhaps by the receiver being turnedoff and later turned back on, by a loss of all data for a period oftime either internal to the receiver itself or due to a communicationbreakdown with the receiver. Currently, a complete observationgap is not indicated in the SV symbol tracks, except (on occasion)if they are present in a qc lite run.The other type of gap is the SV data gap, where the receiver stopstracking an SV for a period of time even though it is well abovethe horizon or elevation mask, perhaps due to an obstruction.The exact definition of an SV data gap depends on whether teqc isrunning in a qc full or qc lite mode. For qc full, an SV data gapoccurs if there are one or more missing observation epochs whilethe SV is above the elevation mask. For qc lite, an SV data gapoccurs if tracking stops for more than the specified minimum time(-gap_mn, again) and then tracking resumes before a specifiedmaximum time (see -gap_mx option). The symbol used in the SVsymbol track is now -, so an SV data gap might look like:A/S on: _____--Ioooooooooo--ooooo++I+I__A/S off: _____--I**********--*****++I+I__ 1 2 3 ab 4 5 6which occurred at the interval (ab). The meaning is really the sameas the interval (23), i.e. the SV was above the elevation mask, but nodata was received.The only other indicator for SV data, low in thesymbol hierarchy, is the"Loss of Lock" indicator, L, which is used when the receiver issuesa loss of lock for either the L1 or the L2 observable. A large numberof L symbols may indicate an unhealthy receiver or antenna.This should rarely, if ever, be seen in the ASCII time plot.Following the SV symbol tracks are one or four more, depending onwhether you are using qc lite or qc full, respectively. For qclite, there is a symbol line labeled "Obs". This records themaximum number of SVs that were tracked by the receiver for eachbin using a hexadecimal representation. For example, if there isa 7 on this line, then 7 SVs were tracked for at least one observationepoch represented by that time bin; if there is a b on this line,then 11 SVs were tracked for a least one observation epoch representedby that time bin; and so on. If no SVs were tracked, a (blank),rather than 0, is shown. If one or more s are present on the "Obs"line in a qc lite run, this is your best indicator that a completeobservation gap has occurred.For qc full runs, the "Obs" line is replaced by four lines, labeled"-dn", "+dn", "+XX", and "Pos". The "+XX" line is the one most likethe qc lite "Obs" line; the XX is replaced by the elevation mask indegrees (rounded to the nearest degree) and indicates the maximumexpected number of SVs that are above the elevation mask, accordingto the supplied ephemerides, again using a hexadecimal notation.The difference between the qc lite "Obs" line and the qc full "+XX"line is the difference between reality and theory: "Obs" shows whatwas seen, where "+XX" shows what could have been seen (above theelevation mask).The discrepancy between reality and theory is recorded in the "-dn"and "+dn" lines, which are the SV tracking discrepancy counts, andrecord the two bounds of the discrepancy given the current elevationmask. These lines can be thought of as showingthe "good new/bad news" to the number of SVs not tracked. The line"-dn" records the minimum discrepancy of all observation epochs forthat time bin while the line "+dn" records the maximum discrepancy ofall observation epochs for that time bin. The discrepancy countis also shown in hexadecimal notation, with ' ' (blank) for 0.As of 2009 Mar 9, there is also a reverse discrepancy indicator, '+',meaning that there is data for one or more SVs below the elevation mask.For the discrepancy lines to work correctly, the option -max_rx_SVsmust be set correctly. This states the maximum number of SVs thatare capable of being tracked by the receiver, and currently has adefault value of 12. If a complete observation gap occurs withqc full, a group of c characters will be shown (c is hexadecimal for 12),at least on the "+dn" line, and if the gap is large enough, on the"-dn" line as well.By way of example, let's suppose there is a '1' on the "-dn"line; this means that every epoch in that time bin is missing at least 1SV that could have been tracked. A '2' on the "-dn"line means that every epoch in that time bin is missing at least 2SVs that could have been tracked, and so on. A ' ' (blank, i.e.0) on the "-dn" line means that there is at least one epoch in that time binwhere all possible SVs (given the receiver's channel limit) were being tracked. On the "+dn" line, a 1' means there is at least one epoch inthat time bin that is missing 1 SV that could have been tracked; a '2'means there is at least one epoch in that time bin that is missing 2 SVs that couldhave been tracked; and so on. A ' ' (blank, i.e.0) on the "+dn" line means that every epoch in that time bin hadall possible SVs (given the receiver's channel limit) being tracked.When populated with non-zero entries (i.e. not ' ' or blank),the "-dn" and "+dn" lines with "-dn" on the top form a simple type of histogram, forexample, Kunming IGS site, 2007 Jan 17 (with a TurboRogue receiver with only8 channels):-dn 1 12223321 122111123 11321111112211211 1111 -dn+dn1211 1 11121 222421335433342222323335311223332122322232223211223 11 +dnfollowed by the theoretical SVs that could have been tracked on the "+XX" line;again, Kunming IGS site, 2007 Jan 17:+10889877777777777668aa989aabbbbbaaaaaa9aaaa97899bbba9aaaaaaaaaaa9999aa8888+10The "Pos" line records the success or non-success of calculatedcode positions for the antenna at the different epochs. Generally,you should see an o recorded for each bin in which a positioncalculation was successful.The last symbol line in the ASCII time plot is labeled "Clk". This linerepresents all millisecond receiver clock resets present in the observationtime tags with either a + or -symbol, meaning either a positive or negative millisecond receiverclock reset was detected, respectively. Another symbol which maybe placed on this line is ^, which is lower in theclock symbol hierarchy that either + or -, and indicates at least one missedobservation epoch in that time bin, though a correct value of theobservation sampling interval must be set (see -O.int option) forthis to work correctly. This symbol was added to help reveal two things:1) the existence of "micro-gaps", i.e. missing data periods less thanthat set by the -gap_mn option, and 2) to identify short gaps duringwhich a millisecond clock reset may have occurred. For example, ifa portion of the "Clk" symbol track is:Clk: + + + ^^ + + + ^+ + + + + 12 3then you can suspect a missing (positive) millisecond receiver clock resetat time (1) due to the regularity of the rest of the identified resets andthe missing epoch indicator ^, and other missing observation epochs attimes (2) and (3). Other micro-gaps might exist in the data, but theirpresence would be hidden by the + symbols.Incidentally, another "micro-gap" indicator exists for qc full runs on the"+dn" line. Since this is maximum discrepancy between the number of SVsthat could have been observed and what were actually observed. However,for missing observation epochs (no SVs observed), rather than placing acount of just "SVs that could have been observed" based on the ephemerides,teqc places a count of the maximum allowed by the receiver. So, fora receiver capable of tracking 12 SVs (see -max_rx_SVs option), you willalso see a c (hexadecimal for 12) on this line when missing a observation epoch.Following the "Clk" line of the ASCII time plot is a scale bar with tickmarks. The separation between tick marks is indicated a few lines lowerat "Time line window length". The tick marks should occur at even valuesof the tick interval. For example, if the time window starts at01:39:30.000 (1h 39m 30s) and the tick interval is 3 hours, the tickmarks will be placed at 03:00:00, 06:00:00, 09:00:00, and so on, tothe best resolution possible on the ASCII plot. The tic interval isself-scaling, from 0.1 seconds to 7 days, depending on the length ofthe time window.At the end of the ASCII time plot, the beginning and end time and date followat the ends of scale bar. Seconds are only printed out if they are non-zero.Following the ASCII time plot in the short report segment is a reportsummary. First is a listing of the name of target files, and if qc-full,the RINEX NAV files used.The bounds of the time window is then shown. If the times of the first and/orlast observation epochs do not match the bounds of the time window, theseepoch times are shown as well.If the configuration environment variable or any configuration files were used,these are listed next.If the observation interval is non-zero, this is given.The total number of satellites (SVs) with any type of observations is thengiven. This is followed by a list of missing SVs, up to the maximum setby default (probably 32), or using the -PRNs option, for each satellitesystem that had any members. Finally, if doing qc-full, a list of SVs thatdid not have ephemeris information is given.The number of SVs which can be simultaneously tracked by the receiver isthen given. This currently has a default value of 12, or can be changedusing the -max_rx_SVs option.If the observation interval is non-zero, the total number of possibleobservation epochs in the time window is given. This is followed thenumber of epochs that actually had "complete observations" from at leastone SV.The definition of a "complete observation" is important, so it will bedefined in detail here. In order for an observation from a GPS SV tobe "complete", it must have :P1 or C/A code data
P2 code data
L1 and L2 phase data
S/N for both L1 and L2 be at or above specified minima
if qc-full, an SV elevation at or above the elevation mask
Then the numbers of possible, complete, and deleted observations are given. If doingqc-full, the both the number of possible observations above the horizon and abovethe elevation mask are given first. Next, the number of complete observations isgiven; if qc-full, this is restricted to those observations above the elevationmask. Next, the number of deleted observations is given; if qc-full, this isalso restricted to those observations above the elevation mask.If the multipath option was set (which it is by default), the average multipathRMS is given. If a moving average window was used (which is used by default),information about the length of this window is given. If qc-full, the multipathRMS is only for observations above the elevation mask.The number of detected millisecond receiver clock resets is then given. This isfollowed by the total drift of the receiver clock, an estimate of the averagereceiver clock drift, and, if the number of clock resets is non-zero, the averagetime between resets in minutes.The length of time required before an SV data gap is reported is given next.If qc-lite, a maximum time is also given.If the detection of n-millisecond clock slips is on (+cl option), the numberof epochs with n-msec clock slips is reported. This occurs when all SVs withmultipath observables must have multipath slips of the same size to within aspecified tolerance (fraction of millisecond).This is followed by the number of other n-millisecond multipath slips which donot qualify as n-millisecond clock slips. Given a non-zero tolerance, thereis a certain probability that a few multipath slips fall within the tolerance.Therefore, a second value is given in parentheses and this is the total numberof multipath slips for the time window (no elevation mask cutoff). If thetolerance is set to 1e-2 millisecond, ratios on the order of 2:100 are expecteddue to chance. Significantly higher ratios are an indication of a sickreceiver.Next if doing the derivative of the ionospheric delay observable (+iod) ormultipath (+mp), counts of the number of IOD and/or multipath slips isgiven. If qc-full, this is further broken down according to elevation mask.In order to qualify as a count here, both MP1 and MP2 must slip (though notnecessarily by the same amount) at the same epoch for a particular SV.Finally, a "SUM" line in printed, showing the start and end times of the window,the length of the time window in hours, the observation interval in seconds,the number of possible observations (if qc-full), the number of completeobservations, the ratio of complete to possible observations as a percent (if qc-full),the multipath RMS values for MP1 and MP2 (limited by the elevation mask if qc-full),and lastly the "observations per slip".The "observations per slip" needs a bit of explanation. First, "observations" means"complete observations" as defined above, including the elevation mask if qc-full.Second, "slip" means "either an IOD slip and/or both MP1 and MP2 slips occurredduring the epoch having a complete observation for this SV".Some additional information for each SV can be included in the short report segmentby using the +ssv option. Similar to the main SUM line, shown for each SVwith observations are: the expected number of observations, the number of completeobservations, the number of deleted observations, ratio of complete to possibleobservations, multipath RMS values for MP1 and MP2, and the observations per slip.Long Report Segment:The long report segment contains a further breakdown of information by SV and byelevation (if qc-full). In the long report segment, individual SVs are oftenreferenced. The leading character indicated the satellite system:G: NAVSTAR GPS (US) system R: GLONASS (Russian) system E: Galileo (European) system C: Beidou/Compass (Chinese) system J: QZSS (Japanese) system I: IRNSS (Indian) system S: SBAS (e.g. WAAS, EGNOS) The first portion is a list of some of the processingparameters, followed by a time stamp of the first and last observation epochswithin the time window, and the observation interval.Next is a breakdown of observations per SV. If doing qc-full and the SV hadephemeris data, the values in the first four columns have meaning: #+hor: number of observations above the horizon for this SV : mean elevation of SV above the horizon for epochs with observations #+mask: number of observations above the elevation mask for this SV : mean elevation of SV above the elevation mask for epochs with observationsNext are the number of reported and complete observations. If doing qc-full and theSV had ephemeris data, the values are for epochs only above the elevation mask;otherwise, the values are for all epochs: #reprt: number of observations with any data reported for this SV #compl: number of "complete" observations reported for this SV(see definition in "Short Report Segment")Next are the number of L1, L2, P1, P2, and C/A observations. Again, if doingqc-full and the SV had ephemeris data, the values are for epochs only above theelevation mask; otherwise, the values are for all epochs: L1: number of L1 observations for this SV L2: number of L2 observations for this SV P1: number of P1 observations for this SV P2: number of P2 observations for this SV CA: number of C/A observations for this SVIf doing qc-full, any SV computed to be above the elevation mask but not havingany data reported is listed next.If doing qc-full, any SV not having ephemeris data but having observation dataof any kind is identified with a "*".Next, a summary tally is given. If doing qc-full and a site position was found,the total number of observation below the elevation mask is given (i.e., numberof observations excluded because of low elevation). Next, reasons forincomplete observations (above the elevation mask if a site position was found)are summarized: missing L1, L2, P1 or C/A, or P2, or poor S/N for L1 or L2.Following this is the number of observations reported with any code or phasedata. (Note: If an SV has only, say, Doppler data, it will not be reported here.)This is followed by the number of observation deleted for any reason:below elevation mask (if qc-full), missing code or phase data, and/or poor S/N.Finally, the number of complete observation is given.Next, repeat of the receiver clock offset and drift statistics is given.Next there is one of several elevation histograms, from the horizon angle (defaultof 0) to the zenith (90). These need some explanation as to the styleof presentation. The x- or horizontal labeling of the histograms may use somethinglike: 5=% 1m 15=% 2mIn these cases, the histogram is really then a dual histogram, using the "=" symbolto show percentages and the "" symbol to show meters, and a "#" symbol to showwhere both histograms occur. Hence, histogram lines like:################======would show about 7% and 1.1 meters on the first line and 4% and 0.1 meters on the second line.A ">" at the extreme right of the histogram bar indicates that the bar extends off scaleto the right. The y- or vertical labeling of the bins is in degrees from the horizon to thezenith.The first histogram in for the ionospheric delay. Currently then is not a measureof the ion RMS in the qc (hence all the values are zero), so the only validscale is the percentage of observations that had ionospheric delay slips.Beneath this is the MP1 RMS summary per SV and the gross statistics for all SVs, followedby the MP1 RMS histogram. The summary per SV shows the number of observations abovethe mask angle (default of 10) and how many were deleted for MP1 observations (dueto lack of one or more observables), followed by the mean elevation (in degrees), and theMP1 rms in meters. There is also a breakdown of MP1 slips above and below 25 ofelevation, and what the receiver reported for slips in L1 and L2. The individual SV MP1statistics are followed for the gross statistics for all SVs. The elevation statistics and histogramshows the total number of observations per elevation bin, the number of MP1 slips detected,and the mean MP1 rms numerically, followed by the histogram bars for MP1 rms in meters (as ""symbol) and the percentage of observations that had MP1 slips (as "=" symbol).(Recall that if "" and "=" overlap the "#" symbol is used.)The MP2 summary follows and is analogous to the MP1 summary.The final two histograms are for the L1 and L2 SNR values. These are also dual histograms,showing the mean SNR with the "" symbol and the one-sigma value with the "=" symbol.(Recall that if "" and "=" overlap the "#" symbol is used.) In these histograms, bothscales use the same units, which are arbitrary. If a manufacturer's format binary file was used as inputfor the qc, or a RINEX OBS file with observables S1 and/or S2,then the units are receiver specific. If a RINEX OBS file withoutS1 or S2 is used, then the scaled RINEX 0-9 flag for SNR is shown."Strange" BehaviorSection 22.If doing qc full mode (i.e., NAV file(s) supplied eitherimplicitly or explicitly or using binary target files)the qc full>>>>>>>... indicator may, on some file data sets, pause part waythrough and then appear to keep going. Don't panic. Everything is operatingnormally. Here's what is happening:The qc full mode really starts off in a qc lite mode. When using target files(as opposed to stdin), teqc has the luxury of being able to go to anyarbitrary location in a file. The first primary goal of the a qc full run isto find the pseudorange point position of the antenna. A certain minimal amountof information is required before this is possible. There must be a certain numberof SVs reporting pseudorange data for a given epoch and teqc must haveephemeris information for those SVs. Occasionally, this does not happen earlyin the file. When it does happen, teqc starts re-reading and re-processingthe target file now knowing the antenna position. If plot files have beenrequested, this is when they are written. The pause you are seeing is thetime it takes teqc to go back and re-do all these items and get back up tothe epoch when the point position was determined.
If doing qc full mode (i.e., NAV file(s) supplied eitherimplicitly or explicitly or using binary target files)and the plot option is turned on, but no position was found (for whatever reason),no plot files are created. This is a consequence of the logic used for theqc full mode (see above item).
Direct qc of binary files produces a slightly different result than qc ofRINEX files. This is due to the direct qc of binaries being designed fordirect data streams from receivers, and thus lacking the capability oftreating the data stream as a file. Also for direct qc, the plot fileinformation regarding the elevation and azimuth of each SV will begin atthe first epoch where both the antenna position and an SV ephemeris areboth known, whereas for qc of RINEX files, the elevation and azimuth informationwill be computed for the entire window of interest. This behavior canusually be correctly by pre-loading a RINEX NAV file, say, from the samesite and the previous day, using the -nav option.
If doing any qc mode, the user intends to input NAV file(s), but uses +nav filenameinstead of -nav filename, the original file filename may be re-openedand destroyed. One safeguard has been implemented to help prevent thiswhen the qc command is ordered:
teqc [options] +qc [options] +nav filename [rest_of_command]in other words, turning on the qc option before specifying the RINEX NAV filename,and the command does not involve a translation from binary. In this case,the program will not allow the filename to be re-opened in a "write" mode,which if it took place would destroy the original file.When using the Borland DOS shell version of teqc, ASCII lines written to filesby teqc terminate with a newline ('\n' = CTRL J = 0x0a). ASCII lines spewed tostdout and then redirected to a file will be terminated with a carriage return('\r' = CTRL M = 0x0d) and then the newline. This added carriage return isapparently being done by the DOS shell.
The WatCom DOS shell version of teqc results in the extra carriage returnsbeing added in both cases, both as files written by teqc and stdout redirectedto a file.As usual, if you ftp the DOS-created files to UNIX in ASCII mode, the addedcarriage returns are removed; if you ftp the same files to UNIX in binary mode,the added carriage returns are left in the files. Last modified: 2019-12-24 02:29:42 America/Denver 2ff7e9595c
Comments