I just received a new RS2 and I’m getting started with it using the ReachView3 app. I’m also new to GNSS so I’m trying out a few things to see how it works. So far, I’ve gotten NRTK working but I’m having trouble with OPUS-RS.
I followed the advised settings on Emlid’s OPUS guide and all topics on the forums but I’m still getting the same error message from OPUS. I’ve tried logging two 1hr observations at 1s intervals in RINEX 3.03 and RINEX 2.10 and one 20min observation at 1s intervals in RINEX 3.00. I also tried a 2.5hr at 30s in RINEX 2.11 but it still didn’t make a difference.
I’ve tried changing the file names to make the ZIP name out of the receiver shorter so OPUS will accept it but once I got a message saying the files inside need to match that name. I changed their names to match and hit the same recurring problem.
What am I missing?
I’d expect to be able to log OPUS-RS in the field and get a solution back without leaving the site or pulling out a laptop to mess with the files. Ideally, I hope to pull the file right out of the ReachView3 app and submit it to OPUS as is.
I’ve used OPUS for the last ten years and I occasionally have the same issues. For one, OPUS is a GPS only processing service for now. You can submit a file with other GNSS data in it, but many times this is the reason OPUS didn’t process the file. If there are other GNSS data in the first minutes and no GPS data at the beginning, this is mainly the reason OPUS failed.
The use of other GNSS data supposedly is planned for the near future. Also, OPUS decimates all files submitted to 30 second intervals. Another issue, if using OPUS-RS, it’s best to manually select at least 9 of the closest CORS. Some stations don’t always download their files after the hour and many wait 2 hours or more. Not all CORS are federal government maintained. Many are privately maintained. OPUS is mainly for CONUS and territories of the USA. Always make sure your observations have a clear sky, OPUS doesn’t like dirty data. Another tidbit, let your receiver get an accurate position before starting to log any data. This will help immensely. Many times without doing this, the receiver position may be hundreds of feet or even miles away if traveling from another observation session in another county.
I managed to get two of my RS files to work TWO DAYS after collecting the data. My trial run was eye opening. I thought OPUS was more immediate than that.
I’ve checked your data and see several reasons for the issues with processing.
OPUS has quite strict requirements for the data, and I’ll try to sum up some of the recommendations that can enhance a chance of getting successful results:
Some of the data you shared has quite poor observation quality with low SNR. Please double-check your surveying conditions to make sure there are no heavy obstacles that could affect the data like buildings, trees, cars, humans, laptops, etc. I see in your photo that Reach RS2 is placed near tall trees with thick foliage, so I’d recommend at least trying to raise it higher;
Some of the logs are recorded in RINEX 3.03 format. At the moment, we recommend using our RINEX 2.XX version while working with OPUS cause we tailored it to be supported;
According to OPUS, it processes files successfully on the third day after collecting the data because it takes some time to obtain enough amount of corrections data from CORS. That’s why I’d recommend trying it once again after that.
Thanks! I managed to get a return on two of my files when I tried them a few days later. I thought OPUS worked faster than that. I’ll have to change my workflow plans to accommodate such a delayed turnaround.
