It's official, OPUS-RS hates me. I've submitted several files over the past few months as double checks on short static sessions or network RTK positions. If I get a solution at all it is almost always based on stations in KY, NC, & GA but typically I get one of two messages.
Message #1:
FILE: 06482360.obs OP1387467083153
6014 OPUS-RS cannot find three reference stations within 250 km of
6014 your position and with suitable data for use with your dataset.
6014 OPUS-RS requires at least three reference stations and is
6014 currently limited to a maximum distance of 250 km. If you wish
6014 to use reference stations more than 250 km from your rover station,
6014 you may use the User Selected Base Station feature on the OPUS
6014 Options page.
6014
6014 If your data set is recent, it is likely that data from the nearby
6014 CORS stations have not yet been uploaded to the CORS archive. You
6014 may want to try again later.
Message #2:
FILE: log1353a.13o OP1387430242539
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
6034 ATTENTION!! The quality of the GPS data from the rover or nearby
6034 CORS sites was too noisy and below minimum standards to attain a
6034 meaningful solution. To avoid this unexpected inconvenience the
6034 user may want to re-observe at a different hour of the day and for
6034 a longer period of time.
The below solution was run today on a file I collected in August. Notice that all stations used are from out of state. I got the same solution back in August for this same station. A second station a mile away with similar site and satellite conditions observed immediately after the station below will not return a solution at all then or now.
FILE: 06482370.obs OP1387467040679
6011 Warning - OPUS-RS was able to find a set of reference stations
6011 with data suitable for use with your dataset. However, your
6011 position does not fall within the polygon enclosing these reference
6011 stations. This means that the geographic interpolation algorithms
6011 performed within OPUS-RS must instead perform extrapolation.
6011 Extrapolation, especially if your position is far from the
6011 reference stations, is prone to error. Use this solution with
6011 caution.
Your station is 35.8 KM outside the polygon enclosing the reference stations.
NGS OPUS-RS SOLUTION REPORT
========================
All computed coordinate accuracies are listed as 1-sigma RMS values.
For additional information: http://www.ngs.noaa.gov/OPUS/about.jsp#accuracy
USER: stephen@wardlandsurveying.com DATE: December 19, 2013
RINEX FILE: 0648237a.13o TIME: 16:16:49 UTC
SOFTWARE: rsgps 1.37 RS52.prl 1.89 START: 2013/08/25 00:46:00
EPHEMERIS: igs17550.eph [precise] STOP: 2013/08/25 01:31:45
NAV FILE: brdc2370.13n OBS USED: 2403 / 2646 : 91%
ANT NAME: TRM22020.00+GP NONE QUALITY IND. 12.65/ 25.29
ARP HEIGHT: 2.00 NORMALIZED RMS: 0.333
REF FRAME: NAD_83(2011)(EPOCH:2010.0000) IGS08 (EPOCH:2013.64671)
X: 526688.860(m) 0.006(m) 526688.071(m) 0.006(m)
Y: -5150215.120(m) 0.033(m) -5150213.663(m) 0.033(m)
Z: 3713274.605(m) 0.024(m) 3713274.484(m) 0.024(m)
LAT: 35 49 57.21873 0.006(m) 35 49 57.24461 0.006(m)
E LON: 275 50 20.67861 0.005(m) 275 50 20.65325 0.005(m)
W LON: 84 9 39.32139 0.005(m) 84 9 39.34675 0.005(m)
EL HGT: 220.855(m) 0.041(m) 219.544(m) 0.041(m)
ORTHO HGT: 251.485(m) 0.045(m) [NAVD88 (Computed using GEOID12A)]
UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 16) SPC (4100 TN)
Northing (Y) [meters] 3969098.645 167898.883
Easting (X) [meters] 756452.393 766149.459
Convergence [degrees] 1.66295488 1.07666897
Point Scale 1.00041049 0.99994840
Combined Factor 1.00037581 0.99991374
US NATIONAL GRID DESIGNATOR: 16SGE5645269098(NAD 83)
BASE STATIONS USED
PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
DL1890 NCMU MURPHY CORS ARP N350406.777 W0835759.361 86588.9
DG4257 FRKN FRANKLIN CORS ARP N351130.686 W0832341.746 99412.6
DH4146 GABR BLUE RIDGE CORS ARP N345151.920 W0841937.609 108474.4
DE8228 HAYW HAYWOOD CORS ARP N353135.396 W0825530.127 116929.6
DG7400 NCMA MARSHALL CORS ARP N354847.313 W0824122.673 132975.5
DM6192 P779 PARI_OBS_NC_2008 CORS ARP N351206.964 W0825220.902 136226.8
DG5311 NCSW SWANNANOA CORS ARP N353546.038 W0822524.229 159403.5
DH7115 KYCB CUMBERLAND SE CC CORS ARP N365754.602 W0825951.977 163350.9
DH3776 VABG BIG STONE GAP VA CORS ARP N365120.625 W0824536.800 169416.7
NEAREST NGS PUBLISHED CONTROL POINT
FC0085 1432 N355055. W0841019. 2044.9
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
Here's a map with my location in the center and OPUS-RS's 250km radius showing all of the stations in my area. Does anyone have any info or ideas on why OPUS-RS refuses to use TDOT stations?
First off, verify that your raw XYZ position in the RINEX file is correct. OPUS-RS uses that raw position to select CORS stations. If it is you are most likely collecting data too soon after start up. I like to get my minimum constellation and then some and start a new session. Years past before I had experience in some those cases I have edited the RINEX file XYZ with the OPUS solution XYZ and resubmitted.
Second, use "Options" and request the 9 nearest TN CORS. Your return message should give you some insight. Request again and select the next 9 to give you a better idea. If you continually work in the same area you may want to set a profile with 4-5 requested CORS, allowing OPUS-RS to fill in.
Third, check on NGS for data availabilty on those dates. I have found that requesting only 1 CORS in the right location solves polygon problems. I pick a reliable, not always the closest in that direction.
I note that the farthest CORS in your solution is only 169 Km away versus allowable 250 Km.
Send me your 8/25 RINEX file.
Paul in PA
Tennessee didn't set up the Obamacare exchanges, so the feds have blacklisted them.
I ask the same thing about TxDot sites a few years ago.
The answer I received was that the sites were not collecting usable data consistent with what was required to use for OPUS solutions.
I have seen where many of the local antenna have been located at all district and TxDot facilities and some are obstructed by canopy and/or horizon limits.
I've been using the FTP downloads to process for my own control points.
The data stream is locked from public RTK use.
:-S
I Tried TN17 And Data Was Not Available At Your Obs. Time
The first hour of 8/25. Check on all the stations as the TN system may have been down at that time.
Paul in PA
I don't have your email, but I've tossed the files onto DropBox.
This one was collected with a Trimble 4000ssi with TRM22020.00+GP antenna.
08/25/2013 file
This is the one collected the same evening also with the Trimble equipment a mile or so down the road that will not return a solution unless I force OPUS-RS to use closer stations then I think it doesn't like the some of the station data.
https://dl.dropboxusercontent.com/u/109211806/06482370.obs
These two are from late yesterday collected with a Topcon Hiper SR.
https://dl.dropboxusercontent.com/u/109211806/log1352x.13o
https://dl.dropboxusercontent.com/u/109211806/log1353a.13o
Typically I will start the unit and allow them to acquire satellites for a few minutes until I'm pretty sure that it has found all available birds then I start collecting the data. I've used the same procedure for years collecting Fast Static sessions with reliable results but something about my procedures or the TDOT stations is not sitting well with OPUS-RS.
Thanks for any insight you can provide.
Looks like partly a CORS problem.
Paul in PA
I have the same problem with OPUS. I find I get better results downloading the TDOT sites from CORS, and breaking them down myself.
Stephen Ward, Poor Solution Returned With TN CORS
For the file you sent me I deleted the first 2 1/2 minutes to get clear C1 ans P2 observations. I renamed it to 0648236v.13o per convention and submitted to OPUS-RS.
"FILE: 0648236v.13o OP1387490229222
6030 ************** WARNING ***********************
6030 One or both of the standard deviations associated with
6030 horizontal coordinates is greater than 5 cm, and/or the
6030 standard deviation associated with the vertical coordinate
6030 is greater than 10 cm. This means that the vectors used to
6030 determine your position did not agree as well as expected.
6030 Often this is the result of problems with the adopted coordinates
6030 at one or more of the reference stations selected by OPUS-RS.
6030 If a problem reference station can be identified, it can
6030 be excluded with the Exclude feature on the OPUS Options
6030 page.
6030
NGS OPUS-RS SOLUTION REPORT
========================
All computed coordinate accuracies are listed as 1-sigma RMS values.
For additional information: http://www.ngs.noaa.gov/OPUS/about.jsp#accuracy
USER: lplopresti@enter.net DATE: December 19, 2013
RINEX FILE: 0648236v.13o TIME: 22:23:55 UTC
SOFTWARE: rsgps 1.37 RS82.prl 1.89 START: 2013/08/24 21:37:30
EPHEMERIS: igs17546.eph [precise] STOP: 2013/08/24 23:21:30
NAV FILE: brdc2360.13n OBS USED: 5766 / 5964 : 97%
ANT NAME: TRM22020.00+GP NONE QUALITY IND. 30.26/ 13.29
ARP HEIGHT: 1.738 NORMALIZED RMS: 0.666
REF FRAME: NAD_83(2011)(EPOCH:2010.0000) IGS08 (EPOCH:2013.64640)
X: 533364.657(m) 0.089(m) 533363.868(m) 0.089(m)
Y: -5148087.599(m) 0.213(m) -5148086.142(m) 0.213(m)
Z: 3715263.288(m) 0.226(m) 3715263.167(m) 0.226(m)
LAT: 35 51 16.74130 0.056(m) WOW! 35 51 16.76721 0.056(m)
E LON: 275 54 53.97460 0.066(m) 275 54 53.94931 0.066(m)
W LON: 84 5 6.02540 0.066(m) WOW! 84 5 6.05069 0.066(m)
EL HGT: 223.941(m) 0.312(m) 222.630(m) 0.312(m)
ORTHO HGT: 254.545(m) 0.312(m) [NAVD88 (Computed using GEOID12A)]
UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 16) SPC (4100 TN)
Northing (Y) [meters] 3971751.452 170480.805
Easting (X) [meters] 763238.573 772959.157
Convergence [degrees] 1.70838292 1.12111295
Point Scale 1.00045395 0.99994847
Combined Factor 1.00041879 0.99991333
US NATIONAL GRID DESIGNATOR: 16SGE6323871751(NAD 83)
BASE STATIONS USED
PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
DL2078 TN17 TDOT DISTRICT 17 CORS ARP N354848.158 W0840017.535 8567.7
DJ9540 TN15 TDOT DISTRICT 15 CORS ARP N360008.235 W0834613.952 32768.8
DJ9542 TN16 TDOT DISTRICT 16 CORS ARP N355409.802 W0843604.363 46919.8
DJ9536 TN13 TDOT DISTRICT 13 CORS ARP N355637.031 W0831226.416 79850.1
DJ9546 TN23 TDOT DISTRICT 23 CORS ARP N355510.684 W0845957.565 82874.3
DG4257 FRKN FRANKLIN CORS ARP N351130.686 W0832341.746 96574.2
NEAREST NGS PUBLISHED CONTROL POINT
FC0101 EM 67 N355305. W0840554. 3556.9
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 will take another look at the balance of that observation.
I looked and in the second half of your file you have some L1 only observations.
Paul in PA
Stephen Ward, Poor Solution Returned With TN CORS
Thanks Paul,
I've experimented with importing TDOT CORS points into TBC for static networks in the past and noticed that I've had less than good results. I chalked it up to my inexperience with TBC. As a test I once created at network in TBC containing only TDOT CORS points, held one point fixed and let the rest fly, and TBC still flagged several of the baselines as out of tolerance. Once again I blamed my lack of experience with TBC but now I'm wondering if there's more to the story.
Stephen Ward, Poor Solution Returned With TN CORS
"6030 ************** WARNING ***********************
6030 One or both of the standard deviations associated with
6030 horizontal coordinates is greater than 5 cm, and/or the
6030 standard deviation associated with the vertical coordinate
6030 is greater than 10 cm. This means that the vectors used to
6030 determine your position did not agree as well as expected.
6030 Often this is the result of problems with the adopted coordinates
6030 at one or more of the reference stations selected by OPUS-RS.
6030 If a problem reference station can be identified, it can
6030 be excluded with the Exclude feature on the OPUS Options
6030 page.
6030
NGS OPUS-RS SOLUTION REPORT
========================"
I resubmitted the file for extended output and cannot quite figure it out. Almost all TN CORS have high residuals all in the same direction? They should be scattered or one should be so far out of whack that you remove it. I have no clue how to take the information I received.
Paul in PA
Stephen
I took a closer look at the file you sent me and that L1 only data was for PRN 13 and 23 and was sporadic throughout the file, found one incident 7 minutes in. Without a consistent collection of observations ambiguities do not get resolved. Over the weekend I will filter out that data and resubmit.
You can try it yourself with teqc.
Paul in PA
