Trimble rinex file converter

These files require some manual fiddling. There is a 4 step process: 1. Use teqc to create a diagnostic file that contains information about the time and byte position of each data record in the file. Run a perl program that processes this file to make a list of epochs around UTC midnight along with their byte locations. Edit this file, or a copy, to keep only those lines for the epochs at midnight.

Use a simple awk command to convert this file into a script to run the program chop, which chops bytes out of a file. Edit this script to make a final simple change, and run it. OK, that is 5 steps. The reason for all of these steps is because of the millisecond offsets in the data, so that it becomes difficult for a long file to predict exactly which observation is the one at UTC midnight.

To do it would require figuring out which way the clock is drifting. It would not be too hard to do that, but is too much programming hassle. For example, suppose the file tk5e The sequence of commands to split the file is given below.

The file tk5e Now the trick is to edit this file and keep only the lines that correspond to the day boundaries. Be careful about the millisecond offsets. A trick is that once you have found the first one, you can delete 43 lines and the line after that will be the next one. The number of detected millisecond receiver clock resets is then given. This is followed by the total drift of the receiver clock, an estimate of the average receiver clock drift, and, if the number of clock resets is non-zero, the average time 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. This occurs when all SVs with multipath observables must have multipath slips of the same size to within a specified tolerance fraction of millisecond. This is followed by the number of other n-millisecond multipath slips which do not qualify as n-millisecond clock slips.

Given a non-zero tolerance, there is 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 number of multipath slips for the time window no elevation mask cutoff. If the tolerance is set to 1e-2 millisecond, ratios on the order of are expected due to chance. Significantly higher ratios are an indication of a sick receiver.

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 not necessarily 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 complete observations, 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. Similar to the main SUM line, shown for each SV with observations are: the expected number of observations, the number of complete observations, the number of deleted observations, ratio of complete to possible observations, 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 by elevation if qc -full. In the long report segment, individual SVs are often referenced.

WAAS, EGNOS The first portion is a list of some of the processing parameters, followed by a time stamp of the first and last observation epochs within the time window, and the observation interval. Next is a breakdown of observations per SV. 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.

Following this is the number of observations reported with any code or phase data. Note: If an SV has only, say, Doppler data, it will not be reported here. Finally, the number of complete observation is given. Next, repeat of the receiver clock offset and drift statistics is given. These need some explanation as to the style of presentation. The y- or vertical labeling of the bins is in degrees from the horizon to the zenith.

The first histogram in for the ionospheric delay. Currently then is not a measure of the ion RMS in the qc hence all the values are zero , so the only valid scale is the percentage of observations that had ionospheric delay slips.

The MP2 summary follows and is analogous to the MP1 summary. In these histograms, both scales use the same units, which are arbitrary.

If doing qc full mode i. Don't panic. Everything is operating normally. 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 any arbitrary location in a file. The first primary goal of the a qc full run is to find the pseudorange point position of the antenna.

A certain minimal amount of information is required before this is possible. There must be a certain number of SVs reporting pseudorange data for a given epoch and teqc must have ephemeris information for those SVs. Occasionally, this does not happen early in the file. When it does happen, teqc starts re-reading and re-processing the target file now knowing the antenna position.

If plot files have been requested, this is when they are written. The pause you are seeing is the time it takes teqc to go back and re-do all these items and get back up to the epoch when the point position was determined. This is a consequence of the logic used for the qc full mode see above item. This is due to the direct qc of binaries being designed for direct data streams from receivers, and thus lacking the capability of treating the data stream as a file.

Also for direct qc, the plot file information regarding the elevation and azimuth of each SV will begin at the first epoch where both the antenna position and an SV ephemeris are both known, whereas for qc of RINEX files, the elevation and azimuth information will be computed for the entire window of interest.

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. This added carriage return is apparently being done by the DOS shell.

The WatCom DOS shell version of teqc results in the extra carriage returns being added in both cases, both as files written by teqc and stdout redirected to a file. Don't Panic Introduction: teqc Section 1. To subscribe or unsubscribe to the teqc email forum, use the above URL. To send a message to the teqc email forum: address-- To: teqc unavco. Types of Data Section 3. A minimum set of header records must be present for each file. Also, lowercase versions of the following header lines are recognized and converted to uppercase if output e.

XX where valid information i. The rest of the fields in other header records can be blank if a descriptor string is expected or have some numerical value if a numerical value even if it is zero is expected, but these other header lines must be present with or without non-blank information. XX where valid information, i. However, teqc should be able to read the entire file and will report records which have not be coded yet.

MES files are not required, but if they are present and you are using target file names not stdin , then teqc will use the matching MES file for each target input file to help resolve certain metadata. Currently, only the record 55h with ephemeris information and record 57h GPS or MET observables have been coded, though, again, teqc will report and skip other records. Normally, the Ashtech "smoothing" of the pseudoranges in not applied, but can be turned on. The translation to RINEX should work correctly in cases where the B-file "version" is 3 or greater--which is the case for any recent Ashtech firmware.

For translations where the version number of the B-file is 2 or less, the phase translation will be in error. Like with the Ashtech download format, the Ashtech "smoothing" of the pseudoranges in not applied by default, but can be turned on. Ashtech R-file: An R-file format can be downloaded from some receivers, such as the Z, and this can be directly read by teqc. Ashtech U-file: An U-file format can be downloaded from the micro-Z receiver, and this can be directly read by teqc , including the new "data mode 7" format.

The translations assume that only one antenna port on the receiver is being used. The files with the suffixes. The files with the other suffixes e. But there is some prototype code in teqc in case the user comes across any examples. Navcom binary: Binary data from Navcom receivers can be read with teqc. ConanBinary data from original Rogues are ordered by SV number, rather than by time, and will not translate correctly with teqc. TurboBinary TurboBinary data is readable with teqc.

This includes data with normal-rate data, high-rate 50 Hz data, and the so-called " second" data containing LC data. JPS Soc format: Supported. The translation will include multiple ns clock resets the Allstar's clock steering signature between consecutive epochs. This is because examples of certain record types have not yet been encountered in use to date. These translators are being included primarily to read legacy data.

It may also be helpful for the first-time user to be aware that: A minimal number of assumptions have been made about the file names that teqc uses. The Berne-recommended naming convention for RINEX files, though not necessary for teqc , is quite acceptable and can be readily used on the command line or in scripts using teqc. Your may receive a "Notice", "Warning", or "Error" to stderr. If something is wrong ususally an "Error" or usage problem , teqc informs the user and terminates.

In general, teqc does not use hard-wired array sizes, but instead allocates and deallocates memory as needed. As long as your computer has enough computer memory, you should never run into array bound problems.

The basic design of teqc is command-line oriented, following the UNIX shell model. Documentation specific to other operating systems e. DOS will be included as the program is ported and tested on other operating systems.

Operating Systems and Hardware Section 5. Another basic design feature is the use of standard input stdin , standard output stdout , and standard error stderr. Instead of a file as input, teqc can be in a pipeline accepting a RINEX format stream or binary data stream as stdin. Stderr is reserved for reporting problems that may occur any time teqc encounters something in any file or in stdin that it doesn't like or understand.

Stdout is used for dumping the ASCII product requested by the user consistent with the command line syntax. The output from teqc then has the following caveats at the present time: stdout and stderr must be able to be separated.

Consequently, the user is encouraged to use a shell that can distinctly separate stdout and stderr. For the remainder of this document, it will be assumed that the UNIX user is using either sh or ksh , though the following examples should allow a user to easily use csh or a MS DOS shell to achieve the same results.

Though the rest of this tutorial assumes you will be using sh or ksh , you can easily use teqc with csh or a DOS to control stdout and stderr. General Concepts About Syntax Section 7. This is mentioned since other file names may be present in the options, but any files listed in the options are part of the processing configuration and are not considered to be targets of the processing.

Even executing just teqc i. For this reason, both work here. You can either think of -O. Sometimes, especially with new features e. XX format compliant, i. One way of doing this is to execute: teqc fbar XX format. All information originally in the target file will be retained in the output version --and if its not, there's a bug, so please report this. Or you could execute: teqc fbar After doing the above three commands, it might also be instructive to do something like: diff fbar If the original file were produced by teqc , you shouldn't see any differences --and, again, if you do, there's a bug, so please report this.

XX format compliancy, but don't want to save any re-processed stdout. There are several ways to do this e. XX specifications at the end of the execution of the file, or a error message dumped to stderr if a problem was encountered. For NAV files, a sanity check is performed on the three times for each ephemeris. When inputting multiple target files of the same type, teqc looks to see if this time ordering remains sequential though neighboring epochs of exactly the same time are currently allowed --except for RINEX NAV files, where the information is sorted before it is used.

For this reason, assuming that the data in fbar In principal, any of this information can be modified by anyone using an editor for ASCII files, such as "ed", "ex", or "vi" on a UNIX OS, on a file-by-file basis which, incidentally, highlights one of the most severe vulnerabilities of RINEX--ease of intentional or non-intentional data tampering.

However, it often occurs that the same type of information needs to be corrected on a large set of RINEX files and that the same corrected information needs to be placed in these fields on all the effected files.

For example, suppose the monument marker name needs to be corrected to read " the foobar site " in the OBS file fbar This can be accomplished by executing teqc -O.

The -O. Notice the double-quotes on the command line encapsulating the string which contains blanks as white space. If you wished to change the monument name to just " foobar ", you could execute teqc -O. To see the difference, try: teqc -O. Internally, 12 bits are used to store the value of the year, giving teqc the capability of dealing with years.

Thus, with the internal calendar starting at A. Note that you can't use times before 1. The characters in the brackets and the brackets themselves are optional material included only to make the option more understandable to the user; only the characters to the left of the leading [ is used to identify the configuration option. Thus -O. However, like the rest of the option flag name, only printable characters are allowed in the brackets; no white space is allowed.

Let's return to the metadata from the fbar There is an important difference between the last two example commands, though it should not be apparent at this point i. Here the option hierarchical procedure used in teqc is introduced. To make full use of teqc 's capabilities, it is strongly suggested that the user eventually become familiar with this hierarchy. All that is needed now is to know the order in which configuration options are processed.

The first configuration options that are processed are the command line options, processed left to right. For example, execute: teqc -O. Which is used? The answer is the first one encountered, which in this case is the one to the left. To convince yourself, also try: teqc -O.

Actually, the executable looks for an environment variable that matches the name of the executable. The next configuration options that are processed are all the specified configuration files. A list of these are formed in the following way. Now all that is needed to is to find each of these configuration files if they exist , which is done in the following way. Subscribe to Knowledge Base Get notified when new articles are added to the knowledge base. All Categories. Development and Testing Facility-managed Projects General Information 9.

Geodetic Imaging Cables and Connectors 6. Comms and Networking Equipment Enclosures 9. GNSS Antennas GNSS Receivers Allen Osborne 6. Javad 2. Leica 3. Magellan Ashtech Septentrio Topcon Trimble Trimble NetR5 Trimble NetR8 Trimble NetR9