The problem here is probably different. There is simply no L2C here and hence only those calculations for L1.
USo I tried to convert the ublox from RS2 using an online RINEX converter
https://gps-solutions.com/gnss_converter
I then uploaded the resulting RINEX files (online & RTKCONV) to OPUS & AUSPOS.
from OPUS, I got a solution for the online converter RINEX file & an error from the RTKCONV RINEX file. for the RTKCONV file it says that it was less than 2 hours even though the RINEX header says it contains 4 hours of observed data.
RTKCONV file error message
> 1007 The RINEX dataset submitted to OPUS failed to pass an initial
> 1007 test for one or more of the following reasons.
> 1007 1. The data only contained values for a single frequency.
> 1007 2. RINEX file not formatted correctly.
> 1007 3. One of the lines in the RINEX file is over 80 characters
> 1007 in length.
> 1007
From AUSPOS, both RINEX files returned processing errors.
may be not a RINEX observation file
or may be a RINEX 3.x observation file
or an empty file or a part of RINEX header file only.
AUSPOS cannot get a solution.
If it is a RINEX 3.x file, please convert it to a RINEX 2.11 file and resubmit.
I think there is an error somewhere in the RTKCONV conversion process. Please someone from EMLID take a look and post for us a correct RTKCONV file,
PS: Rinex files are accepted by OPUS using RTKLib 2.4.3 b33 if you change the time decimal part to .00000 but is rejected if processed from RTKLib 2.4.3 EMLID b28 x64 .
Thank you.
Hi Juan,
Sorry it took so long to get back to you.
We’ve found a way to convert RINEX data from Reach RS2 so that the time becomes an integer. To get the integer time in RINEX data, you should specify the -TADJ=0.1 option in the Receiver Options field in RTKConv Options as it’s shown on the screenshot below:
However, this is not required for OPUS as it accepts standard RINEX data recorded on Reach RS2.
According to AUSPOS, their service can’t work with L2C data. Therefore Reach logs won’t process with AUSPOS. However, AUSPOS is working on the update that will enable this functionality in future versions.
Also, I’d like to point out that RTKLib version 2.4.3 Emlid b28 is designed for Reach RS+ and Reach M+ receivers and, therefore, outputs L1 data only after conversion. I assume that’s the reason why OPUS aborted the submitted data.
For Reach RS2, there is an RTKLib version 2.4.3 b31 that can be downloaded from our docs.
4 Likes
@tatiana.andreeva
finally!!! it’s on even seconds & I have compared both the integer & decimal converted RINEX files and processed them in RTKLib. The results of the base are the same and the rovers differ only in the x.xxx2 decimal part.
Can you tell me where you got the -TADJ=0.1 option ? Is it written in the RTKLib documentation? Thank you very much for your assistance on this matter.
1 Like
Hi Juan,
This is an internal RTKLib option, we’ve found it in the source code.
Juan,
Have you been able to successfully upload and process OPUS Rapid Static and Static jobs with your RS2 device since this fix? I am waiting to hear back about this issue also before I make a purchase of two devices. I am also waiting until the RS2 antenna has a calibrated file selection in the OPUS menu. Anyone know when that may occur?
David,
I just reprocessed a Rinex file from RS2 to verify if the uneven seconds would be accepted by OPUS. So i sent 2 Rinex files of the same observation - even & uneven time logging observations.
Both were accepted by OPUS. However the 2 positions varied by approximately 4cm. Please see coordinate output for the same point. I used the NONE antenna option for both sessions.
even seconds output:
SOFTWARE: page5 1801.18 master50.pl 160321 START: 2019/09/01 22:17:00
EPHEMERIS: igs20690.eph [precise] STOP: 2019/09/02 04:49:00
NAV FILE: brdc2440.19n OBS USED: 6312 / 9518 : 66%
ANT NAME: NONE NONE # FIXED AMB: 55 / 77 : 71%
ARP HEIGHT: 1.5 OVERALL RMS: 0.021(m)
REF FRAME: ITRF2014 (EPOCH:2019.6687)
X: -3174537.238(m) 0.062(m)
Y: 5316667.946(m) 0.083(m)
Z: 1523461.793(m) 0.037(m)
uneven seconds output:
SOFTWARE: page5 1801.18 master91.pl 160321 START: 2019/09/01 22:17:00
EPHEMERIS: igs20690.eph [precise] STOP: 2019/09/02 04:49:00
NAV FILE: brdc2440.19n OBS USED: 6588 / 7787 : 85%
ANT NAME: NONE NONE # FIXED AMB: 55 / 88 : 63%
ARP HEIGHT: 1.5 OVERALL RMS: 0.021(m)
REF FRAME: ITRF2014 (EPOCH:2019.6687)
X: -3174537.286(m) 0.025(m)
Y: 5316667.989(m) 0.078(m)
Z: 1523461.834(m) 0.038(m)
Interestingly, OPUS used more data from the uneven seconds logging file = 85% against 66% from the even seconds logging file. Also there were more observations in the even seconds file - 9518 vs 7787. Don’t know why since both came from the same observation file. My conclusion is the rinex conversion with the -TADJ 0.10 settings maybe removed or interpolated the data to even seconds which was detected by OPUS and thus rejected some of the interpolated data which then led to the difference in final solution? Not sure. Maybe others with more knowledge can chime in. I would like to know the reason.
Juan,
Is your measurement an occupation of a known control point and are you able to compare the absolute distance between the known point and OPUS point?
When I evaluate GNSS receivers for absolute accuracy I check their accuracy by occupying a known HARN (High Accuracy Reference Network) control station for a 2 hour observation period. Then I upload the Rinex data to OPUS then compare the OPUS results to the published HARN coordinates. Do you have any evaluations of this type that you can share with me? Thanks again.
Considering that there are no Reach RS2 receivers out there for demo purposes (at least not to my knowledge) I am also throwing this out there for anyone that may have actually tested their RS2 as I describe above? If so I would love to get your Test Rinex occupation files so that I could evaluate this for myself.
The point is a project control point used in a survey work. But even if it was an arbitrary point, the 2 solutions should give the same coordinates because they came from the same raw ubx file. The 4cm is small but there should be no 4cm discrepancy. Will try to upload original ubx file later today.
Hey there,
Just like to point out that it’s better to use raw data recorded on Reach directly with uneven time value for PPP in OPUS. These observations are more precise than the ones you get after conversion to the file with even time. In this case, RTKLib interpolates the data which may reduce the accuracy.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.
Hi everyone,
I’d like to revive this old topic to share a couple of options for getting logs with rounded seconds that we’ve added recently:
-
When you record logs in ReachView 3, you can choose the OPUS preset. Here’s a guide about logging data for OPUS in ReachView 3 – it’ll help you set up everything.
-
In case you convert the data in Emlid Studio, you can enable Time rounding in the Convert settings. As a result, you’ll get a log that can be used for further processing in OPUS or other services.