3 posts were split to a new topic: OPUS solution is lower by 134mm compared to known elevation
So if I understand you correctly, you were able to keep the GPS, GNSS, AND GALILEO selected but then using rtkconv you removed them to use with OPUS?
NGS OPUS works best when you can collect a static, RINEX 2.11 file (GPS and GLONASS only). A 15 or 30 second update rate. You must collect a 2 hour file for use with OPUS Static and at least 15 minutes if you are able to use Rapid-Static (OPUS-RS). There are constraints to using Rapid-Static (see NGS webpage for them) and there now is a map to see if you are likely to be able to use OPUS-RS.
1 Like
Did you wait for 48 hours before resubmitting file?
Yes, exactly.
BTW the other hardship is that you canāt specify lower than 1hz logging rate, which means that unless you decimate the data (I also ran into problems here) you can only submit about 6-8 hours of obs data to OPUS.
The reason for that is OPUS wonāt accept files >100MB, and 1hz data longer than about 8 hours creates files >100MB.
Just FYI
Iād like to formally request a 0.2Hz (5s) recording interval
15s interval would be better, but I will settle for 5s (0.2Hz) as well for static data.
Iām a little tired of decimating the data with Teqc or rtklib.
If I can simply log data at a 5s interval, it will cure a lot of my problems.
Thanks so much dev team - looking great so far
2 Likes
Hi @geohawk,
Thanks for your suggestion!
Weāre working on adding this functionality in future releases of our app.
4 Likes
Any updates on adding this feature?
1 Like
Hi Seth,
Itās on our roadmap. However, I canāt give any ETAs for now. Weāll post an update once thereās news.
Has anyone found a consistent way to get an OPUS solution with the RS2 RINEX data?
Iāve had some success in the past with using gfzrnx to convert from RINEX 3.03 to 2.11 and use only GPS. But, there are many times where I just keep getting errors.
./gfzrnx_osx -finp Football\ field/raw_202005260133_RINEX-3_03/raw_202005260133.obs -fout Football\ field/NoMarker.20O -vo 2 -satsys G -f
Error I get:
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
1020 OPUS aborted on the submitted data file for one or more of the following
1020 reasons. OPUS cannot process the data file.
1020 1. Collection interval of the data file was not one of the allowed rates.
1020 The intervals that are accepted are 1,2,3,5,10,15,30 seconds.
1020 2. The time of each epoch is offset from one of the above intervals. The
1020 seconds epoch field must coincide with one of the above rates.
1020 3. The data file may have been collected in kinematic mode. OPUS does not
1020 process kinematic data files.
1020 4. Note: OPUS processes data every 30 seconds, and 2+ hour files
1020 collected at the 1 second rate should be changed to 30 seconds.
1020 5. If your data were collected today or yesterday, we may not have
1020 sufficient CORS data - try resubmitting your file tomorrow.
1020
Can anyone post the exact commands they use to convert their files?
Thank you!
I ran multiples over the last few days and have had no issues. I followed these instructions. Also, can you run fine. 2.10 vs 3? I ran every available constellation listed and the in rtk-conv removed all but gps.
We recommend using the following configurations to log RINEX data on Reach RS2 for OPUS:
- In the RTK Settings tab, choose Static Positioning mode, enable GPS only and set up the update rate to 1 Hz
- Go to Logging tab and select RINEX 2.10 raw data format
- Enable raw data recording and log the data for more than 2,5 hours. According to OPUS, itās better to use raw data logged for 4 hours at least
1 Like
Also it appears you arenāt selecting the RS2 in the antenna type. Iād make sure you pick that too on OPUS.
1 Like
Thanks Seth!
I just copied one of the many fail messages Iāve had. I think perhaps converting from RINEX 3 to 2 isnāt the same as logging in RINEX 2.10. Iām going to try that.
I have the reach rs2 setup right now collecting. Iāll report back in a couple of days once I can send up to Opus.
1 Like
Iāve installed a permanent antenna on the side of our building down to an M2. Ran a four-hour observation using the details above and the next day at 12 pm EST, ran it through OPUS and it came back with no issues.
1 Like
I collected data two days ago and just ran it through OPUS and Iām still getting the error:
1020 OPUS aborted on the submitted data file for one or more of the following
1020 reasons. OPUS cannot process the data file.
1020 1. Collection interval of the data file was not one of the allowed rates.
1020 The intervals that are accepted are 1,2,3,5,10,15,30 seconds.
1020 2. The time of each epoch is offset from one of the above intervals. The
1020 seconds epoch field must coincide with one of the above rates.
1020 3. The data file may have been collected in kinematic mode. OPUS does not
1020 process kinematic data files.
1020 4. Note: OPUS processes data every 30 seconds, and 2+ hour files
1020 collected at the 1 second rate should be changed to 30 seconds.
1020 5. If your data were collected today or yesterday, we may not have
1020 sufficient CORS data - try resubmitting your file tomorrow.
1020
Steps to reproduce:
- Logged RINEX 2.10 for about 3.5 hours
- obs file was too large for OPUS so I used RTKCONV to change the interval to 30s
- Uploaded to OPUS and selected the āEML_REACH_RS2 NONEā antenna
I logged a second observation using RINEX 2.11 for about 4 hours and I got the exact same result.
1 Like
File from RS2:
RTKConv to decemate to 30s
FILE: raw_202012101955OPUS.obs OP1607798140689
1008 NOTE: You provided a zero or negative antenna height.
1008 If ARP HGT = 0.0, OPUS solves for the position of your selected antennaās reference point (ARP).
1008 If ARP HGT < 0.0, OPUS solves for a location inside or above the antenna
1008
NGS OPUS SOLUTION REPORT
========================
All computed coordinate accuracies are listed as peak-to-peak values.
For additional information: OPUS: the Online Positioning User Service, process your GNSS data in the National Spatial Reference System
USER: xxxxxxxxxxxxxxxxx DATE: December 12, 2020
RINEX FILE: raw_345t.20o TIME: 18:36:38 UTC
SOFTWARE: page5 2008.25 master57.pl 160321 START: 2020/12/10 19:56:00
EPHEMERIS: igr21354.eph [rapid] STOP: 2020/12/10 22:50:00
NAV FILE: brdc3450.20n OBS USED: 2377 / 2977 : 80%
ANT NAME: EML_REACH_RS2 NONE # FIXED AMB: 20 / 26 : 77%
ARP HEIGHT: 0 OVERALL RMS: 0.017(m)
REF FRAME: NAD_83(2011)(EPOCH:2010.0000) ITRF2014 (EPOCH:2020.9424)
X: -1260562.180(m) 0.029(m) -1260563.104(m) 0.029(m)
Y: -4744027.921(m) 0.059(m) -4744026.604(m) 0.059(m)
Z: 4061391.133(m) 0.067(m) 4061391.003(m) 0.067(m)
LAT: 39 47 35.82240 0.012(m) 39 47 35.84065 0.012(m)
E LON: 255 7 10.09106 0.014(m) 255 7 10.03933 0.014(m)
W LON: 104 52 49.90894 0.014(m) 104 52 49.96067 0.014(m)
EL HGT: 1585.203(m) 0.090(m) 1584.324(m) 0.090(m)
ORTHO HGT: 1602.775(m) 0.118(m) [NAVD88 (Computed using GEOID18)]
UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 13) SPC (0502 CO C)
Northing (Y) [meters] 4404821.000 522558.751
Easting (X) [meters] 510228.587 967459.965
Convergence [degrees] 0.07646389 0.39069444
Point Scale 0.99960129 1.00000885
Combined Factor 0.99935276 0.99976022
US NATIONAL GRID DESIGNATOR: 13SEE1022804821(NAD 83)
BASE STATIONS USED
PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
DF9219 ZDV1 DENVER WAAS 1 CORS ARP N401114.272 W1050737.959 48569.4
DM5962 CTMC CDOT GOLDEN CORS ARP N394317.493 W1051134.335 27935.1
DG7429 P041 MARSHALL FIELD CORS ARP N395658.150 W1051139.316 31964.8
NEAREST NGS PUBLISHED CONTROL POINT
KK1535 U 392 N394749.048 W1045254.365 421.5
This position and the above vector components were computed without any knowledge by the National Geodetic Survey regarding the equipment or field operating procedures used.