I am also having issues. I can get my .obs file to process using the NRCAN service, but not with OPUS. I have tried both static and rapid. I have converted to 2.10 rinex. My base was setup in kinematic with average single and took observations for about 2 hours+.
Attached are the 2.10 rinex files.
We’ll check the data and write back!
Does it have to do with the RTK being set to Kinematic rather than Static for my Base? Are there any consequences to setting the base as Static rather than Kinematic?
I would imagine if you have a base you probably intend on keeping it over a single point for the duration of the survey.
This setting is needed for RTK solution computation so that it hardly can impact RINEX recording.
I have checked the raw data, and it looks like there are no more than 4 satellites with high SNR at a time for L1.
There is not a lot of L2 data, too.
In the meantime, OPUS handles only GPS satellites. The longer the session duration is, the better the results tend to be. Moreover, as Reach RS2 uses L2C data only, it’s better to plan the survey for the time when there are more L2C satellites in view.
It’s more likely that there is not a lot of data for OPUS to calculate the solution. According to OPUS support, approximately 90% of solutions use 70% or more of the observations, and approximately 30% of solutions use 90% or more of the observations.
Also, according to their stats from here, for Static PPP, it’s better to record log for more than 4 hours.
Thank you for getting back to me. I think I found a workflow that is as close to working right for me as possible using field genius and localization over known points. It looks like relying on opus to set a brand new point is too unreliable for everyday use. If I could have one wish it would be to have the base spit out its assumed coordinate in state plane (or support state plane/utm in general).
Thanks for the request! It’s on our roadmap.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.