I’m less concerned with getting the actual results for this particular file, and more concerned with the process that you took to get a good solution.
Can you elaborate on the process that you used?
Thank you.
Did you shut off all of the other constellations except GPS? OPUS can only take GPS at 1hz.
Selecting a “Interval” of 30 (seconds) threw a:
FILE: interval30sOPUS.obs OP1607811050951
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
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
error.
I just got a solution using these settings (same as above) and 1 second interval.
When I change to 5 seconds, 15 seconds, or 30 second interval, it always fails. I also tested at .5 s and it was successful.
So, at least on the two datasets that I took the solution is:
This will start to cause problems for long data captures. These two captures were only 3.5 hours. If it was 12 hours or more then leaving it at 1s interval is going to mean the filesize will be too large.
Thoughts?
Here is another dataset that I tried to use the same technique:
With this dataset I get the following error:
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 ran through about 10 different variations and one finally worked to get a solution.
I cut observations off the beginning and end of the export and had a 1s interval:
Gave me solution:
FILE: middayinterval1s.obs OP1607825815842
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 SystemUSER: [alex@rockrobotic.com](mailto:alex@rockrobotic.com) DATE: December 13, 2020RINEX FILE: midd283s.20o TIME: 02:18:16 UTC
SOFTWARE: page5 2008.25 master93.pl 160321 START: 2020/10/09 18:50:00
EPHEMERIS: igs21265.eph [precise] STOP: 2020/10/09 23:30:00
NAV FILE: brdc2830.20n OBS USED: 1954 / 2646 : 74%
ANT NAME: EML_REACH_RS2 NONE # FIXED AMB: 16 / 28 : 57%
ARP HEIGHT: 2.134 OVERALL RMS: 0.016(m)REF FRAME: NAD_83(2011)(EPOCH:2010.0000) ITRF2014 (EPOCH:2020.7731)
X: -2682542.645(m) 0.062(m) -2682543.753(m) 0.062(m) Y: -1572404.864(m) 0.119(m) -1572403.716(m) 0.119(m) Z: 5550259.409(m) 0.077(m) 5550259.679(m) 0.077(m) LAT: 60 54 17.88394 0.114(m) 60 54 17.87760 0.114(m) E LON: 210 22 37.97864 0.071(m) 210 22 37.87576 0.071(m) W LON: 149 37 22.02136 0.071(m) 149 37 22.12424 0.071(m) EL HGT: 66.680(m) 0.079(m) 67.098(m) 0.079(m)ORTHO HGT: 57.598(m) 0.187(m) [NAVD88 (Computed using GEOID12B)]
UTM COORDINATES STATE PLANE COORDINATES UTM (Zone 06) SPC (5004 AK 4)Northing (Y) [meters] 6755048.087 768970.216
Easting (X) [meters] 357747.142 520469.044
Convergence [degrees] -2.29220556 0.32961944
Point Scale 0.99984795 0.99990513
Combined Factor 0.99983752 0.99989470US NATIONAL GRID DESIGNATOR: 6VUN5774755048(NAD 83)
BASE STATIONS USEDPID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
DP9272 MCES MCNEIL CANYON ELE CORS ARP N594445.880 W1511528.105 157576.8
DQ6620 AKSE SEWARD CORS ARP N600756.991 W1492611.259 86675.5
DO1812 AC51 STRANDLINEAK2007 CORS ARP N612953.102 W1515007.161 136084.4NEAREST NGS PUBLISHED CONTROL POINTInformation on nearest mark is not available due to database connectivity issues or
has restrictions on when or how it can be published.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.
I would suspect that the site was in a high multipath area due to the error code 9011.
I know there are many post about this topic. I’ve done many OPUS attempts and I’ve finally given in and decided to post. I’ve done 3 hour logging for static and 20-25min for rapid-static and have never received a solution.
If I log in Rinex, static, 1 hz and upload the OBS file is there any reason to use the RTKConv since I have it in Rinex already? Once again I’m using everything that is prescribed here but missing something. Antennae Height, File in OBS, Emlid as the type of Equip, Static, GPS only and 1hz. The file provided was run as rapid static.
raw_202102072009.obs (3.2 MB)
Errors I get are always a little different.
FILE: raw_202102072009.obs OP1612730488481
2005 NOTE: The IGS precise and IGS rapid orbits were not available
2005 at processing time. The IGS ultra-rapid orbit was/will be used to
2005 process the data.
2005
6029 After the single baseline analysis, fewer than 3 useable
6029 reference stations remain. Aborting.
After all this I resubmitted it and recieved a solution 2 mins later.
1 Like
Hi Thomas,
Thanks for sharing the update! Sometimes internal complications might prevent the services from delivering the solution properly for some period of time.
I just wanted to comment on one thing.
You don’t need any additional conversion if you have already logged the raw data with the OPUS requirements. You might want to use the RTKConv if you logged all satellite constellations - it will help you to leave the GPS ones only.
Is there any way to keep Reachview from inserting a “-” in the file name? Opus does not accept a file name with a “-” in it. I just change or remove the “-” but wanted to see how to prevent it from being inserted.
I am now trying to simply use the “prescribed settings” to log for opus so that I can submit without errors. Using RTKConv has been a bust 
It sure would be nice if using RTKConv would convert the UBX file to Rinex and it just worked on Opus. I used RTKLib to Convert leaving only GPS and using 4 hours of 6 hours logged. I kept getting file size too large error.
If I selected 30 second interval to reduce the file size then RTKConv would not generate the OBS file. If anyone comes up with the secret sauce for converting UBX files to Rinex that will work in Opus, please share. Until then I will just change to Static, Rinex 2.1 when collecting a benchmark to process in Opus.
1 Like
FYI. When I kept the start/stop time to exactly 4 hours, the OBS file size for Rinex 3.03 was 93,497kb. I still got an error “File too large”. So I reduced the time to exactly 2 hours, and the file size was 47,260kb for Rinex 3.03. Opus accepted that file and it was processed within about 2 minutes.
I thought the cut off for file size was 100mb so not sure what that magic number is.
Hi Tim,
Thanks for your patience!
If you’re working with the latest versions of the Reach Firmware (starting from 26.1), you don’t need to use the RTKConv app to upload the files directly to OPUS.
We’ve developed the Logging section that allows you to record RINEX files with the required GNSS system (for example, GPS only) and the required recording frequency (1s, 5s, 30s). This allows you to simply record the log for the required amount of time and then upload it directly to the OPUS.
Still, it can be helpful if you share your file with us so that we can take a closer look on why OPUS rejects it.
Hi Tim,
I just want to ask if you have checked the log with new settings?
Hi Tim, I am guessing you have more than just GPS turned on to have a file size that large. I would run it through RTKConvert and turn off the other constellations if you haven’t already done so. I think 4 hours usually puts me at about 20,000 kb
I never replied. But after I changed to the new options of logging Rinex 2.11 for OPUS on my RS2 I never have any issues (other than illegal file name). So I simply log a Rinex 2.11 (1 sec) file if I am going to submit to OPUS. It is also a given you need to wait 1-2 days to submit.
Hi Tim,
Sounds good! Glad to see your positive feedback 
Also, we’ve recently released a new feature that allows processing RINEX 3 in OPUS. So, now you can work with RINEX 3 too.
1 Like
Tim,
What I read on OPUS was that it is best to wait at least 24-48 hours. They said they usually get updates from CORS every 30 mins but I guess the 24 hours is to guard against their not having the data yet. I’m paraphrasing all of this and full disclaimer I’m a newbie.
This is some tips to help in your PPP process
if you wait for 24h o 48h is depending on if you need your PPP whit satellite orbit solutions(sp3) igr( only GPS, GLONASS don’t have) or broadcast ephemeris. Now the difference between a PPP with transmitted ephemeris, which is what would be done if you did the calculation the same day versus taking fast ephemeris that are available 17 hours later, is not significant. The precision of the PPP technique many times will be 3-5cm. Most relevant, it’s the Data quality in your RINEX, multipath orthe geographic zone, In my city after 2 hours in High Rate Rinex (1hz or more) record show convergent solutions to cm level (2-5). In many time 24h-48h its for Filed recorder at 15s or 30s samples, for example, CORS
1 Like