I was asked by a Client to do a survey in the mountains 120 miles from here.?ÿ I was curious to see the results for single baseline if OPUS was not up and running.?ÿ Following is the difference (3 hrs static data) between OPUS with 3 local CORS stations and post processing single baseline using our base station 120 miles away:
North: 0.014
East:?ÿ ?ÿ0.003
Height:?ÿ 0.24
Just wondering what I did wrong to deserve this?
Or just an anomaly?
?ÿ
I was expecting 1/1,000,000 plus.?ÿ This should not be happening, or should it?
OPUS is still GPS only, whereas your single base post processing probably included the other constellations. My current understanding is that?ÿ OPUS will go full GNSS when they roll out the new datum c.2025.?ÿ
120 x 5280 / 0.24 = 2,640,000
It's all about the PPMs.?ÿ First, making the assumption that your units are feet, 120 miles is 633600 feet.?ÿ That gives you a 2d error of 1/45,257,142 which is 45 times what you were expecting.?ÿ Using the worst post processed accuracies for current receivers of 5mm + 0.5 ppm million at best you should except .102 m [0.333 ft] (0.005 m + 0.097 m). which your observations beat, assuming the OPUS value has no error for the purpose of this comparison.?ÿ As we all know, OPUS solutions do in fact have error so I would say you are doing better than should be expected.
P.s.?ÿ Not sure if it is still the case, but in the past some of the major players post processing software was not very good at processing very long base lines.?ÿ TGO comes to mind, I would fall back to GPSurvey, Trimble Total Control or NGS software when lines started getting that long.
Also, if you have the post processing software, you can download the 'local' CORS and process them for better and vector adjusted results.
Values are in feet.?ÿ I only used GPS and Glonass for this task.?ÿ I post processed using Leica GeoOffice.?ÿ I don't often have this opportunity to compare long baselines vs OPUS (CORS Network).
Just fyi, this site was in the Western part of Virginia and 12 miles from Greenbank with their antenna array yet no published CORS data.
thanks and would like to hear from others w single baseline comparisons.?ÿ If the ephemeris and constellations are broadcasting better accuracy and we are able to post process same, why use OPUS except to check.?ÿ And as pointed out above, what can we expect with Galileo and BDS added.
That's similar to results I would expect. For years there were only two CORS sites nearby my location. By nearby I mean 150 miles south and 130 miles northwest. If I processed a baseline from the south CORS it would be .2' to .3' different in height from processing using the NW CORS point. Every time. It was consistent although I don't recall which one was low it was always the same.?ÿ
Now there is a "local" CORS point which has always been closer for elevations so I defer to it when I'm interested in GPS elevations, I don't use any OPUS derived heights unless I'm out in remote locations.?ÿ
I would expect you will see the same results each time you try this experiment. It may be the processing engine, mine have been Trimble; GPsurvey, TSO, TGO and TBC.?ÿ
My question is what did you use for your height comparison; Ellipsoid or orthometric?
As for the Green Bank WVDOH operated CORS, looks like data and coordinates are avaiable.
?ÿ
@mark-mayer 2025 now??ÿ Well that's kicking the can down the road. First is was to be with the 2022 datum, of which the datum is pushed back to 2025. Trimble's own static point data processing service has been using Galileo and Beidou for over 3 years now. Free service. https://www.trimblertx.com/?ÿ Note that it uses Trimble owned CORS around the world and not NGS stations. So it's a world wide service unlike OPUS. Whenever I send a static file to both Trimble RTX and OPUS, at most the results are within 0.1' feet of each other horizontally and vertically and often within 0.05' or less.?ÿ And not that it matters for longer static sessions, but Trimble RTX will process data if recorded at 10 second intervals while OPUS decimates data to every 30 seconds.
2025 now??ÿ Well that's kicking the can down the road. First is was to be with the 2022 datum, of which the datum is pushed back to 2025. Trimble's own static point data processing service has been using Galileo and Beidou for over 3 years now. Free service.
Public service <> private service. Different goals, different user segments, different legal status, and very, very different funding schemes.
It was an aggressive timeline to begin with, but NGS has been hit hard by cuts over the past few years. Administrators did not just wake up one day and send out a memo saying "Hey guys, let's delay the rollout of the new datums!"?ÿ
There was an NGS Webinar on the subject a few weeks ago. You can find it on their website, if you wish. Dr. Dru Smith laid out the reasons for the delay. Part of it is that the GRAV-D gravity surveys are not yet complete and were on hold for some months during COVID-19. But mostly it seems to that there have been unanticipated tasks that are injecting themselves into the process. What might be less charitably referred to as "mission creep". And a desire to have everything ready for a single roll out of the entire package rather than a piecemeal distribution. Adding GNSS to OPUS could probably be done sooner, for example, if they focused on doing just that. But they don't want to release that until they have upgraded the whole system. There are a limited number of brains involved, and those brains are elsewhere on the critical path to the new datum roll-out.?ÿ
hpalmer:
?ÿ
What is the issue?
?ÿ
I used ellipsoidal heights and applied factors to both to convert to orthometric in the same file and used same for comparison.?ÿ Following are results from OPUS.?ÿ What I found interesting is the distance to the COORS stations.?ÿ They did not use Greenbank (12mi away) and the closest was 42 miles.?ÿ ?ÿ
?ÿ
?ÿ?ÿ?ÿ?ÿ?ÿ USER: palmer?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ ?ÿ DATE: September 20, 2020
RINEX FILE: 2584264m.20o?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ TIME: 20:51:50 UTC
?ÿ
?ÿ SOFTWARE: page5?ÿ 1801.18 master96.pl 160321?ÿ?ÿ?ÿ?ÿ?ÿ START: 2020/09/20?ÿ 12:10:00
?ÿEPHEMERIS: igu21240.eph [ultra-rapid]?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ STOP: 2020/09/20?ÿ 14:45:00
?ÿ NAV FILE: brdc2640.20n?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ OBS USED:?ÿ 6150 /?ÿ 6261?ÿ?ÿ :?ÿ 98%
?ÿ ANT NAME: LEIGS15?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ NONE?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ # FIXED AMB:?ÿ?ÿ?ÿ 31 /?ÿ?ÿ?ÿ 31?ÿ?ÿ : 100%
ARP HEIGHT: 2?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ OVERALL RMS: 0.016(m)
?ÿ
?ÿ
?ÿREF FRAME: NAD_83(2011)(EPOCH:2010.0000)?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ ITRF2014 (EPOCH:2020.7201)
?ÿ?ÿ?ÿ?ÿ?ÿ
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ X:?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 898359.372(m)?ÿ?ÿ 0.013(m)?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 898358.464(m)?ÿ?ÿ 0.013(m)
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ Y:?ÿ?ÿ?ÿ?ÿ -4931386.428(m)?ÿ?ÿ 0.021(m)?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ -4931384.986(m)?ÿ?ÿ 0.021(m)
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ Z:?ÿ?ÿ?ÿ?ÿ?ÿ 3931988.053(m)?ÿ?ÿ 0.013(m)?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 3931987.981(m)?ÿ?ÿ 0.013(m)
?ÿ
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ LAT:?ÿ?ÿ 38 17 55.28270?ÿ?ÿ?ÿ?ÿ?ÿ 0.017(m)?ÿ ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ38 17 55.31266?ÿ?ÿ?ÿ?ÿ?ÿ 0.017(m)
?ÿ?ÿ?ÿ?ÿ E LON:?ÿ 280 19 28.04095?ÿ?ÿ?ÿ?ÿ?ÿ 0.011(m)?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 280 19 28.01482?ÿ?ÿ?ÿ?ÿ?ÿ 0.011(m)
?ÿ?ÿ?ÿ?ÿ W LON:?ÿ?ÿ 79 40 31.95905?ÿ?ÿ?ÿ?ÿ?ÿ 0.011(m)?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 79 40 31.98518?ÿ?ÿ?ÿ?ÿ?ÿ 0.011(m)
?ÿ?ÿ?ÿ EL HGT:?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 760.664(m)?ÿ?ÿ 0.018(m)?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 759.378(m)?ÿ?ÿ 0.018(m)
?ÿORTHO HGT:?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 791.784(m)?ÿ?ÿ 0.073(m) [NAVD88 (Computed using GEOID18)]
?ÿ
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ ?ÿ?ÿ?ÿ?ÿUTM COORDINATES?ÿ?ÿ?ÿ STATE PLANE COORDINATES
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ UTM (Zone 17)?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ SPC (4501 VA N)
Northing (Y) [meters]?ÿ?ÿ?ÿ?ÿ 4239785.778?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 2070811.469
Easting (X)?ÿ [meters]?ÿ?ÿ?ÿ?ÿ?ÿ 615812.873?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 3397175.784
Convergence?ÿ [degrees]?ÿ?ÿ?ÿ?ÿ 0.82093611?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ -0.73367778
Point Scale?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 0.99976518?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 0.99996378
Combined Factor?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 0.99964587?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ 0.99984444
?ÿ
US NATIONAL GRID DESIGNATOR: 17SPC1581239785(NAD 83)
?ÿ
?ÿ
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ BASE STATIONS USED
PID?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ DESIGNATION?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ LATITUDE?ÿ?ÿ?ÿ LONGITUDE DISTANCE(m)
DM4706 WVCV CANAAN VALLEY CORS ARP?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ N390055.076 W0792725.009?ÿ?ÿ 81804.7
DM4710 WVNR ELKINS CORS ARP?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ N385344.505 W0795130.270?ÿ?ÿ 68167.2
DH7958 LOYA LOYOLA A COOP CORS ARP?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ N382533.900 W0785321.774?ÿ?ÿ 70156.2
?ÿ
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ NEAREST NGS PUBLISHED CONTROL POINT
HW1826?ÿ?ÿ?ÿ?ÿ?ÿ G 58?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ N381753.000 W0793947.000?ÿ?ÿ?ÿ 1094.7
You submitted right after observing, so there were probably no data from Greenbank at the time - some stations only push static data every 24 hours, others every hour on the hour. Submitting again now might get you slightly different coordinates, with different CORS selected and an updated ephemeris.
Check out the short-term time series to see how stable the CORS used in the solution were/are...
Few things here:?ÿ
?ÿ
You mentioned the survey was in the mountains:?ÿ What did your Satellite Horizons look like??ÿ Play with the elevation mask and see if it helps with the noise esp if you were collecting down in a Hollar or a ravine.?ÿ May or may not help.?ÿ Also, pick through the session editor ( if using trimble, not sure what leica uses) and clean up the data to get better results.?ÿ reprocess.
?ÿ
The rapid precise files files are a good start, and the final orbitals will give you the solutions that may provide better results but take about 2 weeks, esp with GLONASS.?ÿ
?ÿ
It is only GPS. and I agree, a few tenths is a bit much, but not if thats all the birds were providing that day at that time.
?ÿ
Keep us posted!
?ÿ
thanks - a few tenths difference vertical in 120 miles is pretty darn good.?ÿ My observations of long single baselines are:
do not discount the quality of single baseline data vs network -?ÿ
wait until the days data is downloaded and available to CORS (thanks Rover)?ÿ
?ÿ
did not mask the data - our base station is on top of an 80' tower - not sure about the CORS stations - the rover would not have picked up those blocked out by hills and would have had may cycle slips through low orbit trees.?ÿ Only processed GPS and Glonass.
?ÿ
?ÿ
In your post dated 23 Sept. you asked: ??...why use OPUS except to check.? Aside from supporting users with receivers but no processing software there is the advantage of using a tool with a standard approach to data processing that includes a good deal more modeling than available in some commercial packages.?ÿ
Your OPUS solution even though it uses the ??ultra-rapid? orbits looks good. The peak-to-peak errors (computed by comparison of the three single baselines) are all good. The NAVD88 value derived using GEOID18 at 0.073 m is rather large. Of course, the geoid model uncertainty at that location is 0.049 m.?ÿ
If height was important to your client, I would have tried to recover and tie to a benchmark 1,095 meters away. It is PID:HW1826.
As Rover83 states, submitting data shortly after observations results in the use of the ??ultra-rapid? orbits. Nowadays these orbits have a reported accuracy of 5 and 3 centimeters for the ??predicted? and ??observed? products respectively. The ??Final? orbits are accurate at the 2.5 cm level. Remember that orbit error over distance to the SV is proportional to the baseline error over baseline length. Doing the math, the difference in orbit products results in no meaningful difference at the longest baseline in your project (82 km).
Rover83 also suggests examining the short-term plots at the CORS you use. Sound advice. Note that the plot for WVGB shows a 10-day period where no data was available for the site.?ÿ
Screen captures related to my comments are shown below:
?ÿ
Missing images
Original post attempt timed out...
In your post dated 23 Sept. you asked: ??...why use OPUS except to check.?
I think I'd ask the reverse of that question. With OPUS being free, low effort, and the definitive gold standard I need a reason to use anything else. Now, I can think of 2 such reasons:
- Making use of GNSS constellations other than GPS
- working during government shutdowns
There was a once upon a time when I routinely resolved static vectors, so it's in my skill set. But I haven't done it, or had the necessary software available to me, since early 2013.?ÿ The only time it's been a thought is during the government shutdowns. The use of GNSS is going to be of greatest aid for short duration observations, not so much for long baselines that exceed RTK limitations. And with CORS, the call for long length baselines other than to position an RTK base is greatly diminished.
I use OPUS to position my RTK base, and the vectors resolved by my dc by the RTK method, as fodder for StarNet.?ÿ?ÿ
