Any tips on editig Rinex files?

I have heard tales of some GPS Cowboys who would do such things.

I use TopCon Tools for my initial processing and there is a flimsy way to disable data in the Occupation View window. I use it rarely, but when there's an obstruction you can see the fragmentation and disable that data. I can output from TopCon Tools to Rinex, though I have never tried disabling segments then outputting.

I would be happy to try if you send the file and a list of satellites and times to disable. spledeus at c4.net or thadd at ese-llc.net (same emailbox)

Thadd

Thanks Thadd. I need to learn how to do this for myself so I'm not groveling on hands and knees every time I run into this issue. Truth be told I really just don't want to have to go out and buy knee pads. 🙂 I can disable the offending segments in either TGO or TBC, but not then re-export that as an edited Rinex to submit to OPUS, at least not that I've found anyway.

Yippy Ki Yay

You can cut holes in your data with Teqc. The software and all necessary documentation is on the UNAVCO website. I taught myself how to do it easily enough. I don't know for sure how OPUS handles files with time gaps. Teqc can be a little clunky to run from the command prompt window, but the results are always perfectly formatted, which you can't guarantee with Notepad edits.

Just using a text editor (I use UltraEdit). Sometimes there are less than 4 (or 5, or 6) SV's in the first couple of epochs. You can simply use the editor to delete those epochs (start with the line with the date/time, and delete all lines up to but not including the date/time that you want to keep.

You can use teqc to delete a particular satellite or satellites, also to window out a start and stop time. Not the most straightforward or intuituve set of commands, but once you understand them it is not difficult. Here is a link to a nice interface for teqc from Mark Huber at the USACE:

WinTEQC Editor

I can send some used knee pads; I just got new ones.

I will have to try the disable / export from Tools next time I process to see what it does. Could be the same, nothing.

Good luck, I am interested in the editing process.

Chris, Send In The Files

When you are in a canyon situation it is sometimes necessary to be selective about picking CORS. Picking a CORS on the other side of the mountain guarantees fewer intervisible satellites. Keep on the visible side but expect some bias in your solution position.

John Hamilton's words are a good start.

It may be necessary to look at your complete RINEX file and compare it incrementally to a Planning sky view. then you pick the limited times you have balanced satellites and make several OPUS-RS submissions.

Let me take a look, I am tired of real work this week.

Paul in PA

This looks extremely promising. Thank you very much.

Chris, Send In The Files

Roger that Paul.

Never liked the command-line interface of TEQC. This app has a straight-forward process too.
Thanks for the tip!

TBC/TGO

Why don't you pic a couple, 3 CORS from the NGS UFCORS and download your own RINEX files for TBC and process yourself? You can fix/edit your cycle slips on your mark and then process the static ties to your chosen CORS. Back in the day before I got comfortable with OPUS I processed all my primary geodetic control that way.

I Sent You An OPUS Solution

Chris,

Observations of your file;

Only about half your GPS observations included P2 observations. The GLONASS fared much better. The lack of all that P2 pretty much precludes an OPUS-RS, but I will split the file and see what happens.

I used the Silkwerks teqc and parsed it to 30 seconds, GPS only in C1 L1 L2 P2 format.

teqc does not recognize your TRM60158.oo antenna and I did not find it in the OPUS list.

Your file also went past UTC midnight, 20:35 to 00:20 the next day. You have to wait an extra day for OPUS to process it. When you first submitted you might have been OK if you deleted the last 21 minutes, 20:35 to 23:59

Paul in PA

It's all part of my diabolical plan to take over the world

Bwahahahaha

Well, at least this part of it anyway.

You're right dig. That is the way I use to do it in the pre-OPUS days. Now I'm just a bit spoiled I guess. That and short of time for just about everything. I do a lot of little surveys all over the place. My predecessor here did everything on local coordinate systems. I've been working on tying in all of these older jobs together whenever I have the opportunity and bringing them into real world coordinates, with the ultimate goal of creating an area wide control file instead of having a gazillion different coordinate files scattered all over kingdom come. OPUS is the key to making it happen because I'm a more or less one man show and just don't have the time to process everything myself anymore, and have a life.

I Sent You An OPUS Solution

You are the man Paul. Thanks.

Chris, What Is Your Antenna Type ?

Also you want to make sure the RINEX converter has it right.

Paul in PA

Chris, What Is Your Antenna Type ?

Using R8 Model 3's

R8 GNSS/SPS88x is the default in 'Convert to Rinex'

Typically select 'TRMR8-GNSS3' when submitting to OPUS

Have to run out and stake some ROW this afternoon, typical last second request.
'Jump!' they say, 'How high?' say I.

Have a great weekend all.

Williwaw out.

Your RINEX Converter Says It Is TRM60158.00

You may have to manually edit that wvwn though OPUS is supposed to ignore that information. I had no idea to use another antenna, so make sure you resubmit it correctly.

I did not get any OPUS-RS results yet nor an abort.

Paul in PA

It's all part of my diabolical plan to take over the world

I am working to the same goal here. I have been exporting my control to a GoogleEarth KMZ that is linked and automatically updates on every machine in the office. That way the crew can see where the control points are without going to notes or asking me...

Did your predecessor run in 2-d or 3-d? I have miles of traverse data in 2-d being processed in one file, then miles of 3-d traverse, GPS vectors and levels being processed in a different file. It is so much fun to try to get 30 year old traverse notes to make sense and damn did they like their POLs...

OPUS-RS, Yes, No, Yes, No

I started by splitting the file in two equal Parts and submitting to OPUS-RS.

First half Solution was spot on to the OPUS position.

Second half aborted, too noisy.

I trimmed the back end off until I got to 3 satellites with P2 data. That also got me before UTC midnite.

OPUS-RS solution close enough to first solution, 0.038m E-W slop.

I trimmed it back farther to get it to end with 4 satellites with P2 observables.

Aborted, too noisy.

Were this my project I would trim back again until I cleared out the majority of noisy data. Then using that end time I would resplit the overall RINEX file into two equal length sets, and resubmit.

What it does show is that the data overall is good and a reobservation is unnecessary.

Paul in PA