Happy New Year all,
Thanks for all the support this past year Surveyors!
If I had to ask for one tool, is an easy-to-use, Windows-based TEQC tool with a ton of functionality to Trim, merge, decimate, combine, and be constellationally "aware" to fix the problems that have be fixed for successful OPUS Share submission.?ÿ Something like what CSRS-PP provides for interogation of a file, then allows the end user to fix a file.?ÿ Right Now, I use a Trimble specific online tool, submit to CSRS, fix the tool with TEQC or the deprecated WINTECQ tool, then resubmit and repeat until I get the file to pass.?ÿ?ÿ
Mentioned here in a file (2016) by UNAVCO was the idea to update TEQC..... Microsoft Word - GDS Plans for GNSS Modernization.docx (unavco.org)?ÿ
This tool doesn't need to be free - I would pay alot for something like this!
Cheers.
Yes this. Anyone have any suggestions?
I too lament the demise of UNAVCO’s teqc tool.
I copy a poster presented at a SIRGAS meeting showing a comparison of teqc and two other tools: GFZRNX and BNC.
https://www.sirgas.org/fileadmin/docs/Boletines/Bol20/10g_Costa_et_al_2015_GNSS_data_check.pdf
The site to GFZRNX is: https://dataservices.gfz-potsdam.de/panmetaworks/showshort.php?id=escidoc:1577894
A screen capture of most of the linked page is shown here:
It is not free as far as I can tell.
My previous post indicated the software is NOT free. It can be free if you are engaged in a scientific study and NOT used in “routine work.” In any even you must register to download the software. Here are more details:
Thank you GeeOddMike. I'll give gfzrnx a try. After a quick look at the gfzrnx manual, it doesn't look like I can extract, for example, the exact 35 minutes of data I want from a multi-hour RINEX file. I've seen a few folks on here suggesting submitting multiple shorter (15min-2hr) files to OPUS-RS as well as sending the whole (for example) 3.5 hour file to OPUS. I haven't done this yet but I do want to try it. I also want to remove the first few minutes of my RINEX files from when my receiver was still settling down.
But I only looked at the gfzrnx manual for 15 minutes. I could have missed something. I got the impression it was written more to be part of an automated CORS data processing chain and less as a Swiss Army Knife for surveyors.
And it's still another tool in the tool box, so thank you. TEQC doesn't work on RINEX 3; perhaps if I get a RINEX 3 file grzrnx could convert it to RINEX 2.11 for TEQC.
The problem as I see it is that teqc being free for all those years means that few people are willing to pay for something like that. As I get older and ponder semi-retirement, I would consider doing that if I thought I could at least pay for my time, but I doubt there is enough of a market to make it financially feasible. I have written a few programs that deal with rinex files, but nothing with the extensive capabilities that teqc had.
For the past 30 years I have developed a lot of my own programs to help my workflow, but it is easy to write programs for use by only me, no help files necessary, no "user-friendly" interface, no rigorous testing, just write it and then fine tune it. One problem with developing software for use by others is anticipating all the things that can go wrong.
I did develop one program that I sold some copies of, that was to log data from Trimble receivers at CORS, back in the late 90's when all Trimble had was logst, which had major issues. For a while all of the PennDOT CORS used my program, called logdat, until Trimble came out with a better program than logst. I didn't make much money on it, but it definitely helped me to understand the data flow from the receivers, dat files, and rinex files. Another DOT wanted to also use it at their CORS, but by that time a new version of windows came out that caused my program to crash, and I didn't want to spend the time fixing it.
My view is that UNAVCO is to be commended for supporting Dr Lou Estey in the development and maintenance of teqc. The tool required a significant investment in time and resources. When Dr Estey retired the tool was no longer sustainable.
He was able to get manufacturers to provide him information about how they gather and store GNSS observables in their receivers is a significant achievement. Having tried to work with manufacturers on similar (though non-GNSS) efforts were mostly fruitless.
Nowadays I mostly write scripts and an occasional GUI under Matlab to work on problems of interest to me. One of the joys of retirement.
There is an NGS webinar scheduled for 9 March 2023 which will address CORS installation, operation and maintenance. This would be a great opportunity to ask about teqc and alternatives.
I started a separate thread about the webinar that contains details about registration, etc.
There's an open source tool, written in Rust, simply called 'rinex'. It is being curated by the GeoRust community.
It has conversion and QC features and as a stated goal to be a replacement for teqc. I have myself submitted a bit of code to it.
Interesting, thanks for sharing. Curious, are there any clear plans as to how to implement file translator? Is a team member planning to work with receiver manufacturers to integrate their proprietary file types into Rust?
File QC is one thing, but reverse engineering proprietary static GNSS data... that is a heck of a task.
The proprietary file formats that teqc supported were - as far as I know - the main reason why it was not open sourced. The vendors gave teqc source code to support their formats, but that source code was never licensed under an open source license.
I have myself suggested the expansion of 'rinex' with a plugin architecture, allowing for others to write import modules, open or closed. The suggestion is here: https://github.com/georust/rinex/discussions/134 . This is, however, not prioritized at the moment.
But in any case, user feedback is very much appreciated. There are downloadable executables so you don't need to install the Rust toolbox and compile yourself.
