Best Teqc option settings?

Appears that you do not use the QC feature which I find quite useful when dealing with problematic data. Note that to get a "full" analysis you need to have a navigation message with the same name as the observation file (e.g. alfa1230.16o and alfa1230.16n). Image copied from the teqc tutorial.

HTH,

DMM

As I said, I use 4 batch files. The first extracts the metadata so I have the exact start and end times of the data and a check on the GPS week. The second does a QC on the .dat file to look at the data to see if it appears ok, and tells me which satellites have no useful data. The third one posted above creates the RINEX. The last one does QC on the RINEX on the theory that checking as a last step seemed to offer the best chance of catching problems.
[PRE]
@ECHO . Batch file runs TEQC to check Rinex file
"C:Program FilesteqcWinTeqcteqc.exe" ^
+qc ^
-nav[file(s)] gps_nav.txt ^
-O.ag INDIV ^
-O.o "Bill Hart" ^
-O.at "TRM33429.00 NONE" ^
+plot2 ^
+err teqc_err4.txt ^
B02N3361.16o
@REM Be sure all lines of command except last end with the continuation carat

teqc_err4.txt[/PRE]

I need to look into the various other files that can be created for checking. I think one of them gives SNR per satellite by time, and would be interesting.

There is probably some way to automate the file names so I only have to edit it in one place, but the described process works for me.

Whatever works for you.

In the event I misunderstand your process, I will mention that the full QC option does create SNR (and other) detailed plots of receiver performance. The *.sum file created using the full QC, which is automatically created when running the option where a matching name navigation message exists, has a lot of nice details not available in the QC lite output. The "lite" version is created when a nav message is not available.

Whatever works for you.

I do create a nav file. Does forcing the name to always be the same, as above, cause a problem if I then supply that name to the last+QC checking batch file? Is the nav file supposed to come from somewhere other than the data I download and process from the receiver?

Perhaps these screen captures from

https://www.unavco.org/software/data-processing/teqc/doc/UNAVCO_Teqc_Tutorial.pdf

will help. Note the file names of the *.10o and *.10n files.

GeeOddMike, post: 402092, member: 677 wrote: Whatever works for you.

I managed to make something work, but I'm asking for recommendations on the best process. I get lost in the teqc options so may not be doing the best.

I do get a full qc report from my process. Actually twice, once when I first check the .dat file and again when I check the RINEX .16o file. These differ slightly if I trim time or satellites out. I think your .sum file is what comes out as .16s for me, and contains the lines shown in the screen capture below a time plot of which SVs were received and above the slip and snr data.

I get sn1, sn2, azi and other files. I haven't looked hard enough to find a good way to graph their contents. Looking at them with a text editor gets confusing.

View the output files using qcview

See: https://www.unavco.org/software/data-processing/preprocessing/qcview/qcview.html

Bill, I'm wondering why you're messing with teqc at all. Why not just submit the DAT file and let OPUS handle it? That'd save you a lot of work that's probably being duplicated by the OPUS processing anyway.

I remember now, I did try qcview last year and had no success. I played with the 32-bit version again tonight on the XP machine, and after some manipulation involving batch files, path changes, compatibility modes, etc. (some of which may not be really necessary?) I managed to get it to display the message
"File is not COMPACT format, cannot read."
File: B02N3361.sn1

which is a file that came out of the teqc run. So maybe I need another option when I run teqc?

I

Jim Frame, post: 402099, member: 10 wrote: Why not just submit the DAT file and let OPUS handle it?

I suppose I should try that. Tinkering was necessary with the files from the 4000sst because of the 1024 week problem, and I wanted to get a feel for what kind of quality reports it gave.

I hadn't re-thought that maybe I didn't still need those steps with the sse.

So you don't do any weeding out of satellites that just barely registered and have no clean data?

Bill93, post: 402102, member: 87 wrote: So you don't do any weeding out of satellites that just barely registered and have no clean data?

Nope. I make sure I have clean setups, then dump all the DAT files to OPUS and let it work its magic. I've processed hundreds of files that way, with good results.

I confess that modern receivers,antennas and software are amazingly capable. For the most part human intervention is unnecessary. As I started GPS processing when manual cycle slip fixing was required and their were few SVs and short windows when the minimum four (4) were visible, the change over the years was satisfying.

While my work required a lot of interaction with the data, in most cases after setting up the processing parameters runs were successful. In the very few cases where there were processing problems, I counted it as fun.

As for plotting teqc plot files, there is a Python tool at http://westernexplorerss.us/GNSSplotters/Teqcplot_Documentation.txt

Use in a Windoze environment is not straightforward.

HTH,

DMM

Corrected link for the python program document, in case anyone else is interested:
http://www.westernexplorers.us/GNSSplotters/Teqcplot_Documentation.txt

This page talks about versions of the teqc output files. It looks like the qcview program only works with very old versions of teqc that produce COMPACT format, whereas the python programs work with COMPACT3.
http://www.westernexplorers.us/GNSSplotters/