PPP’s accuracy can be down to a few centimeter supplied long enough obs, shortened by using multifrequency obs.
Reading up on what OPUS does, they only use the GPS constellation, and you have some potentially really long baselines it seems.
It seems really easy to use, but have some significant drawbacks.
ZIThank you very much. Will download that version of .
Can’t seem to find that version with exe files. Anyone can point me to where it’s located?
Thanks
Christian, I wrote an [ article ] on alternatives to OPUS. There are indeed alternatives, however in the Unites States they are useless as OPUS has infinite provenance and the alternatives have little or none.
There are details concerning NAD83 frame implementation, ambiguity with tidal modeling (solid and interface) and other issues that make the NGS OPUS solutions preferable. If there is a difference between OPUS and any other solution, the OPUS solution is defined as being correct.
For these reasons and others, it is not reasonable to consider processing in any other service.
5 Likes
Thank you for looking at the Ryszard.
I can not duplicate the even-second-timestamps using version 2.4.3 b33, 2.4.2 or 2.4.3; with version 3.02, 2.11 or 2.12 RINEX. With the Interval box checked, set at 1 sec or set at 30 s spacing.
Could you try it again with the first day’s UBX file and keep/share a screen shot of both the main screen and the options screen of RTKCONV? (Perhaps with the latest version also.)
Sorry to be a pain, but I just can’t duplicate.
Thanks! 
Mark
The easiest way is to check the rtkconv.exe version that I used. It seems that the ‘Time Corr’ option is not active here.
rtkconv.zip (1.4 MB) 00013190.obs (444.8 KB)
change the extention to .exe
Thank you for sending me the file.
Just one more explanation. The options ‘Iono Corr’, ‘Time Corr’ and ‘Leap sec’ refer to the GNSS NAV DATA
That rtkconv file does make a file that is on even seconds, however the result will not process:
FILE: raw_201911152137.obs OP1574727054447
1009 WARNING! No antenna type was selected. No antenna offsets or
1009 pattern will be applied. Coordinates with reduced accuracy
1009 will be returned for the antenna phase center.
1009
9011 OPUS could not process the data file that was submitted. The data was
9011 either very noisy or it was collected in kinematic mode.Or OPUS software
9011 has issue during this time, please reupload later.
9011
I will try trimming the file and see if it will process, and will see what TBC does with it too.
This should not be this difficult.
For future refrence, here is the 2.4.3 b5 version @r.pazus used.
The antenna warning shows that without calibration parameters it requires a session trimming by increasing elevation mask. This is probably the reason for “very noisy data”.
But that’s a topic beyond this thread. LandSurveyOverview.pdf (397.9 KB)
there are no executable files in the release? not sure how to compile to make an executable file.
I think Emlid @tatiana.andreeva needs to fix this issue. Most manufacturers have their own RINEX converter software instead of relying on freeware. I tried to use EMLID’s version from their website but could not get the even seconds RINEX output.
Your hardware is useless if users cannot process the GPS data.
1 Like
Hi @marcosplata, @jjb,
First of all, I’d like to point out that we thoroughly tested RINEX logs recorded on Reach RS2 receiver with OPUS and may confirm that it should work just fine. I duplicate here some requirements to RINEX files from Reach RS2 that I posted earlier in this thread:
- The RINEX log should be recorded in Static positioning mode and contain GPS observations only with 1 Hz update rate
- It’s better to record raw data in RINEX 2.10 format as we used logs in this format for our tests and may confirm that it works
- The log should be recorded during 2,5 hours at least. According to OPUS, it’s better to use raw data logged for 4 hours
I’ve converted the 2nd file (that was logged during 4 hours with 1 Hz rate) to RINEX 2.10 containing L1/L2 GPS observations in RTKConv and then submit the file to OPUS. OPUS was able to process the file and I got the results. I can share it with you in PM if you’d like.
As for the 1st file (2 hours, 5 Hz update rate), I wasn’t able to convert it to the RINEX file with 1 Hz observations in our RTKLib version. It seems there is an issue with it, and we’ll check how we can fix this.
May I ask you to make sure you uploaded the correct file? This one contains only 12 minutes of data which isn’t enough for PPP.
1 Like
The UBX file is for testing of conversion to RINEX with even seconds. No need for long UBX file. I just want a version of the RTKConv that would give even seconds readings.
What version of RTKConv did you use? Can you give me the download link to it? I want to test it on my longer UBX files for submission to OPUS.
Thank you.
Would this not be a Rinex converter directly from uBlox? As that is the OEM of the gnss chip. Do they knot have one already?
Ublox rely on tecq/rtklib for RINEX conversion
Hey there,
I’ve tried to convert the file using RTKConv version @r.pazus shared above and noticed that this RTKConv provides only L1 observations after conversion. OPUS requires L1/L2 data, that’s why it can’t process this file.
We’ll think about adding this feature to our RTKLib version. Still, this hardly can affect processing with OPUS somehow as OPUS accepts RINEX data with non-integer time values.
You can download the RTKLib version for Reach RS2 in our docs.
I did not realize that, thanks. This must be the case since their binary message structure is published. Even still it would be nice to have an OEM utility as a back-up. They perhaps did not have to worry about Rinex when their market was low-level embedded positioning. Now that they want a piece of the precision market they should re-consider.
I have also noticed that even when I send my static files to the Canadian PPP service. Some times it interprets the data as L1 only and in Kinematic mode.
Perhaps this is occurs when there is not enough GPS SV’s in view with the L2C signal?