The last few weeks I've been having terrible luck getting rinex files to process with OPUS-RS and I suspect part of the problem is the GNSS and Galileo satellite data in the rinex file. Below message keeps coming up. I've checked the Rinex files over and can't find anything obvious other than all the obvservatins extraneous to GPS data. Do I need strip out all the GNSS and Galileo data from the Rinex file? How best to do that if that's the solution. If anyone can point me in the right direction, that would be awesome.?ÿ
FILE: 65421371.21o OP1621373745445
?ÿ6015?ÿ?ÿ OPUS-RS will not attempt a solution because the submitted data
?ÿ6015?ÿ?ÿ was collected at a location that is more than?ÿ km outside of
?ÿ6015?ÿ?ÿ the area spanned by the set of?ÿ CORS sites whose GPS data OPUS-RS
?ÿ6015?ÿ?ÿ would use in processing the submitted data. These CORS sites are:
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ ac70
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ ab28
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ ac62
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ Your station is?ÿ?ÿ?ÿ?ÿ 110.7 KM outside the polygon enclosing the reference stations
Been having the same problem with RINEX files created from Topcon tps files using tps2rinex utility.?ÿ I switched to just loading the tps files into OPUS, no issues.
You may have problems if you convert the receiver format files to RINEX3 that includes al observation data for other contantallations other than GPS. This was addressed in the recent NGS Geospatial Summit.?ÿ ?ÿTry converting the data to RINEX2 format and submit.?ÿ
Just curious was the error message you transcribed wrong? Was your site in fact within the polygon?
?ÿ
?ÿ
on the issue of RINEX translators, with the decision (by UNAVCO?) to no longer support teqc, will users have no other option than vendor s/w??ÿ
In an analysis performed by NGS on the Texas 2011 GSVS there was mention of problems with OPUS-RS when P2 observations were not logged. I do not know whether this issue has been fixed. See:
As to that P2 problem or one like it way back then, I had correspondence with the OPUS-RS folks and reminded them that RSGPS would take either C1 or P1 and they needed such a switch for C2 or P2. Then there was a problem in that certain receivers would output C2 and not P2 for those C2 capable satellites, so that one or the other was left blank, such that the switch had to be for RSGPS had to look for C2/P2 satellite by satellite. On the sender end one could write an observation merger program to replace any blank C2 data with P2 data and vice versa to allow RSGPS to use it's preferred choice. It is easier for a receiver to accept the broadcast L2C value rather than cross-correlate all the observations to calculate the P2 value. Truth be told one could just replace any missing data with the C1 values and RSGPS will give a solution, not perfect, but usable.
When Charlie Schwarz? retired at NGS he was never really replaced by any single expert. I apologize because my mind fails me on the name of the also retired tecq expert.
Paul in PA
That would be Dr Lou Estey. See his ??Goodbye? here: https://postal.unavco.org/pipermail/teqc/2019/002644.html?ÿ
for some amusing insights into teqc.
?ÿ
@geeoddmike It's all wrong as far as the polygon goes. The generic GP in the Rinex appears correct but the CORS being selected is not. I'm obviously missing something.
I hate misleading error messages.
To remove data for GLONASS and GALILEO, I??d use teqc from UNAVCO: https://www.unavco.org/software/data-processing/teqc/faqs/faqs.html
?ÿ
@geeoddmike Trimble creates two files in the receiver, a .t02 and .dat. The .t02 contains all observations, Galeileo and Glonass while the .dat is GPS only. Using the .dat file to convert to Rinex, the problem persists in OPUS not selecting the correct CORS. I have a ton of work so I need to get to the field but somehow I need to get to the bottom of this as OPUS-RS is a significant check on my work when I have to localize on other OPUS control to get new control into an area.
Well, I figured out, at least in my region, OPUS-RS has a bug in it for selecting the appropriate CORS to use, so by customizing which CORS for it to use, selecting via the https://geodesy.noaa.gov/CORS_Map/ , it's providing a solution. Small additional step but gets the job done.?ÿ
Bada Bing Bada Boom baby!
Try Trimble RTX post processing. Free.
Glad you solved your problem. BTW, I hope you contacted the folks running OPUS ( NGS.OPUS@noaa.gov ) to detail your problem with the selection of CORS used.?ÿ
I have always found them to be helpful and responsive. Contacting them for help on a project I am undertaking, I received a reply within hours. In short order another message from one of the principles at NGS provided me helpful advice and promises to work on my suggestion.
They do respond and while not always able to accommodate requests they do try.
Using the Beta ??Level Project Page?? A user?ÿcan retrieve leveling observations via ??cut and paste?? from the display. I suggested it also be available as a delimited text file.
My little project is to compare the difference in heights in the new datum via xGeoid20A/B with the difference in heights from the actual field leveled values. This would involve a sampling from various states using points that have well-determined ellipsoid heights and were both leveled to in the same leveling project.
Unfortunately there is no relevance for Alaska.?ÿ
@williwaw?ÿ ?ÿ Same it Florida. OPUS will choose Reference Stations 100 to 200 miles away in order to get nice geometry, overlooking Stations 5, 30 and 40 miles away, at a more obtuse triangle.
I had data that I sent to OPUS, Trimble, and CSRS-PPP.?ÿ Got three different solutions on most points, no agreement at all.?ÿ
Best was when I got RTK on the same points, on two different days, and/or when I ran traverse to the points.?ÿ
Ended up throwing out all the post processing results
I had data that I sent to OPUS, Trimble, and CSRS-PPP.?ÿ Got three different solutions on most points, no agreement at all.
That's interesting, I wonder if that's due to observation location. How big of a shift are you seeing?
For any recent moderate to long length static session I've been seeing agreement at the 1-3cm level between the three, at least for the ITRF values at the observation epoch. AUSPOS seems to agree pretty well too.
Trimble RTX uses a different tectonic plate model than HTDP to shift results back to 2010.00 epoch, so there will always be a difference between it and OPUS, especially here on the west coast. Can't remember what CSRS uses off the top of my head...
That's interesting, I did some testing using OPUS solutions vs. Trimble RTX and they agreed within about 5mm horizontally, vertically the RTX solution seemed a bit better but I was a ways from NAVD88 control. The simplicity of using RTX is a big selling point but the way TBC handles OPUS makes it not much of a difference. It's all hands free, point and click and it's done, no conversion, no separate downloads.?ÿ
?ÿ
@geeoddmike Sent them an email. Thanks for your help and suggestions. Cheers!
