Hi @mag ,
Thank you for sharing your code.
I suggest removing the NMEA “\r” termination check. All NMEA messages are terminated with “\r\n”.
If you want to do a more thorough check of the data, our Python UBX Integrity Checker contains code for checking both NMEA and RTCM checksums. You could try running the checker as-is. It will spit out the NMEA and RTCM message types and let you know if there are any checksum failures.
I hope this helps,
Paul
I am assuming it failed from me not having the correct rtcm messages selected it did not give analysis of failure of the error. I did wait a couple days to make sure the ephemerides were available (I think that is the correct term) from the CORS. RTKlib did appear to view the information and show information, I ran it through EMLID studio to time align and trim it a little after converting it.
OPUS has pretty stringent requirements; I’ve had many instances where it rejected a RINEX file (that appeared to me to be fine), then CSRS handled it just fine. I’d recommend uploading your file to CSRS first, since that is an easier system to work with, and use that as a first tier validation of your RINEX.
For OPUS: If you are using an RTKLib based converter (like Emlid Studio), highly recommend checking the RINEX to see if all timestamps are aligned to whole seconds. If memory serves, OPUS requires every timestamp to be zero aligned to the whole second, so instead of 45.000243, must be 45.000000.
There is some good info in this previous forum thread as well:
OPUS Post processing - GPS/GNSS / Development Boards - SparkFun Community
Static OPUS is pretty finicky and Rapid Static will be more so. One issue that pops up is OPUS assumes every GPS sat has dual frequency data. With a L2C-only receiver this is not the case since there are still a half dozen or so sats without the L2C signal. A file where some sats don’t have L2 data is (probably) looked at as a noisy, poor quality dataset. For OPUS Static I’ve got files to process by removing the sats without L2 data. Of course the data left still has to be good enough.
Here’s a skyplot (RTKPLOT) of a one hour dataset I recorded recently with a Quectel LG290P. Look at all the L1 only (orange) sats. There just happened to be 5 visible at this time. No L2 data for them. What’s left might not be enough for good processing especially if one or two happened to be blocked by something.
Check your dataset in RTKPLOT to see if you have some L1-only sats. That may not be the only issue, but could be a contributing factor.
Thanks for the extra context jpb. Does anyone know of any reason to use OPUS over CSRS? From what I can tell, their output and configurability is about the same. The only differences that I know of are that OPUS is very needy when it comes to input, and CSRS is flexible, modern and sane.
Yes, OPUS is an adjusted network of Sites that Engineers and Surveyors can tie to.
It is how we can define the ground truth to our work.
Nailing down a position in reference to the NGS network has a lot of value.
Personally, I’d rather tie my work to actual (up to date) coordinates from CSRS-PPP, but the Industry as a whole might take decades to transition from “how we’ve always done it”.
The inherent “snag” to PPP is data validation. Sure, there’s a lot going on behind the curtains to check the validity of a computed PPP position; but we don’t have a way to physically check the results on the ground. The best way that I know is to backup the position with another PPP mission on a different day with different Satellite geometry. Any GNSS position can be wrong, but it’s rare to be wrong multiple times with the exact same “wrong” answer.
The key is to make PPP easy for anybody. While things are getting easier, there’s still a bit of a learning curve. We also need to think about the huge range of needs and expectations.
IE: A 3-6 hour PPP mission can be absolutely fine for precise coordinates for a control point to tie a Topo down to a permanent point in the middle of nowhere.
But I want weeks of 24 hour missions to establish the position of a permanent Base Station.
Summary: If someone is familiar with OPUS then there is a reason, they probably aren’t starting out in GNSS as a hobby. Opening a new door to CSRS-PPP is easy for them. If someone isn’t familiar with OPUS already, then they probably don’t need to be 
CSRS-PPP will likely be perfect for their needs.
These are just 1 man’s opinions…and I might be wrong 
