HORRIBLE OPUS results

I should add that on the first file I stripped out the galileo and glonass satellites after it would not process, and checked for any comments, less than 4 satellites, etc.

This was a very open site in the desert (Black Rock Playa)

You ran them through RTX and they match together so your set ups were over the same point, your tribrach can't be out of adjustment or something like an out of plumb rod.

I also don't use OPUS much, usually for a check. I wonder how often those types of OPUS results are taken for gospel.?ÿ

Did any of the OPUS numbers match RTX?

?ÿ

Black Rock Playa???

Man-o-man, that brings back some memories!

I spent several years working around Rosebud (just East of the Black Rock) back in the 80s. Do you come in from Winnemucca via the Jungo Road? We had a tent camp at Rosebud (ghost town) for several summers (HOT). Geologists generally stayed in Lovelock and commuted each (long) day.

Loyal

Loyal: right where Burning Man is held every year, stayed in Gerlach, which is probably the most bizarre town I have ever seen. No sign whatsoever of the layout of the festival, just a dry lake bed.
40?ø47'26.16" N 119?ø11'40.09" W

Here are the results (UTM meters), one of the OPUS solutions was very close in elevation to the RTX.

North East Elev
RTX 4513940.050 307828.876 1180.329
RTX 4513940.043 307828.878 1180.332
RTX 4513940.043 307828.883 1180.331
OPUS1 4513940.287 307827.653 1180.326
OPUS2 4513940.478 307827.462 1179.785

That's?ÿ some bad results, did you ever calc the point yourself?

I've never seen that from OPUS, lots of skanky elevations but the horizontal will usually be OK

I did get the data today from the nearby CORS (10 km), I had to have a login to the VRS to get it, and I was given that today to use. Weird that their web page shows a link to data, but a year old. I will process it against that to compare against the RTX. The RTX solution I showed above was transformed from ITRF2014 using HTDP, I am leery of using the Trimble transformation out west.

@john-hamilton

Well John, if it's within 10km of the Black Rock, it AIN'T a "CORS," it must be a RTN network station, because the nearest CORS is about 100km away. Just say'n. If it were me, I'd download a 24 hr. data set on it, and process to several "GOOD" PBO stations in the NGS Network, but that's just me.

Loyal

I disagree, Loyal. I use the "CORS" moniker as a generic term. It is a "Continuously Operating Reference Station" but NOT part of the national CORS network. There was some discussion at the NGS summit this year about terminology, although right now early in the morning I don't remember exactly what was said. There is also a nearby PBO that for some reason stopped collecting in April.

It is part of an RTN. Interesting, though, on the RTN page the coordinate is labeled as NAD83/94(HARN).

Posted by: @john-hamilton

Thanks John.

I have always "preferred" to identify only Continuously Operating Reference Stations that are part of the NGS Network (NCN?) as CORS. If for no other reason than the simple fact that the NGS "CORSs" coordinates are expressed in the same reference frame/Datum.

Loyal?ÿ

I haven't used OPUS this week, but when I do I routinely get way better results than that from much shorter data sets without any fiddling.?ÿ?ÿ

Last time I saw "bad results" (good RMS, high % of obs used, most ambiguities fixed, but high peak-to-peak values) was in the far NE US close to Canada, OPUS was using some US and some Canadian CORS, but they had ITRF for the US and NAD83 (unknowingly) for the Canadian CORS. After I brought that to their attention they fixed it. So that may be a problem here, but the results are not consistently off the same amount. I will wait a few days for the precise and try again. If I still get the same results I will bring it to NGS's attention (or they might read this thread).

If you don't mind sharing, what was the date and 3 CORSs used in the OPUS solution??ÿ Also, number of fixed ambiguities and %

Gene: I will send you the OPUS solutions by email.

@john-hamilton

I'm sure you will get much better results now that the rapid orbits are available.  I've seen some really high peak-to-peak values for solutions using the ultra-rapid orbits, but not as high as your results. 

As a side note, I looked at the short term time series for the 5 CORSs used and noticed all have an approx. 1 cm shift in the easting starting on day 187.  That coincides with the Northridge earthquakes.

John, have you tried taking a really long overlapping observation from the 'private' CORS and adding it into an OPUS Project with your observations, then hand picking some surrounding NGS CORS (preferably UNAVCO)??ÿ

You could initially leave the 'private' CORS unconstrained, then re-adjust with it constrained to the computed value. I suspect (or perhaps happen to know) that the network position for that CORS was computed with OPUS Projects, so it should shake in to the same coordinates anyway.

🙂

Here is an update that may be of interest...

I got data from a continuously operating reference station (I didn't say CORS ;-)) that is 13 km to the south for the same 5 hour period as one of the sessions. Sent it to OPUS, processed just fine. Resubmitted my data file for the same period, got the same crappy results. Now I am worried that something is up with my receiver (R10), although RTX processed the three sessions just fine. And I processed some 15 minute static sessions using those files and they were fine as well. And processed two sessions from my base to the RTN station, also fine.

I again resubmitted my data file and this time manually picked the same 3 CORS that were used to process the RTN station...made no difference, still very high peak-to-peak

Maybe there is some sort of force field emanating from the ghost of Burning Man

After I posted the other OPUS problem that I had Bill Stone (NGS SW region advisor) asked me for my rinex, and he noticed that about half of the satellites were missing L2 data.?ÿ Mark Shenewerk suggested that I should use the +C2 switch when converting from Trimble raw to rinex. I did, and that worked and fixed the problem. Lesson learned, use the +C2 switch on all conversions from the R10.?ÿ

?ÿ

Here is the teqc tip-of-the-week (sure miss those since Lou Estey retired) about the +C2 and other options....

?ÿ

This week's tip: the '+C2', '+L5', "+L6', '+L7', '+L8', and '+all' options

Some of you are using these options and are getting the general idea: they are
merely shortcuts for adding specific observables when reading raw data, usually
for translation, but can be used in other instances (e.g. with the '-O.sum .'
option).  The alternative to using these options and adding observables is to
list all the observables you want with the '-O.obs' option.

Background: The default behaviour of teqc for reading raw data formats for
translation (and other uses) automatically establishes observables for the
legacy GPS, GLONASS, and SBAS signals:

GPS and SBAS L1C/A, or GLONASS G1SA: RINEX L1 C1 S1 observables
GPS L1P(Y), or GLONASS G1HA: RINEX L1 P1 S1 observables
GPS L2P(Y), or GLONASS G2HA: RINEX L2 P2 S2 observables

(Exactly which observable list you get is tuned, in most cases, to the specific
format that is being read.)

Later, when Galileo came around, you got RINEX L1, C1, and S1 for the Galileo
E2-L1-E1 signal, for free.

The options '+C2', '+L5', "+L6', '+L7', and '+L8' are a shortcut for adding,
if you want or need them, extra phase, pseudorange, and SNR observables in
standard RINEX 2.11:

+C2: include RINEX C2 observable for GPS L2C, or GLONASS G2SA
+L5: include RINEX L5, C5, and S5 observables for GPS and SBAS L5, or Galileo E5a
+L6: include RINEX L6, C6, and S6 observables for Galileo E6
+L7: include RINEX L7, C7, and S7 observables for Galileo E5b
+L8: include RINEX L8, C8, and S8 observables for Galileo E5a+b

And if you want to use teqc's "extended" 2.11 for other constellations (e.g.
Beidou, QZSS) or other signals (e.g. GLONASS G3 or GPS L1C which will be on
Block III), see  http://postal.unavco.org/pipermail/teqc/2013/001492.html 

The option '+all' is a further shorthand for '+C2 +L5 +L6 +L7 +L8'.

You should only consider using these when reading raw data.  If you are reading
a RINEX observation file, teqc gets the necessary observable list from the
RINEX obs file header.

So what about Doppler observables with the '+C2', '+L5', "+L6', '+L7', '+L8', or '+all'
options?  The Doppler observables are not included.  More about that next week.

There is a small complication revolving around '+C2', or including the C2 observable
with the '-O.obs' option, and whether or not the '+L2C_L2' or '-L2C_L2' options
work as you expect; see 2009 Aug 3 entry in
 http://www.unavco.org/software/data-processing/teqc/log/log.html 

     - using '+C2' or '-O.obs' with C2: '+L2C_L2' and '-L2C_L2' are ignored; the
       L2 (and S2, D2) are based on L2(L2C) if present, based on L2(P2) otherwise

     - using '-C2' and '-O.obs' w/o C2: '+L2C_L2' or '-L2C_L2' takes effect, allowing
       pure L2(L2C) or pure L2(P2), respectively; default would continue to be -L2C_L2,
       i.e. RINEX L2 (and S2, D2) based on L2(P2)

One other little detail: Suppose you want to explicitly include or exclude only
Beidou PRN 2.  You can't use '+C2' or '-C2' because these options mean include or
exclude the L2C or G2SA pseudorange.  So if you ever need to include or exclude only
Beidou PRN 2, use '+C02' or '-C02', respectively.  (All the SV filters by SV id
work with 1 or 2 digits of the id.)

I am not as savvy as I should be with Static/Rinex file editing. I am glad you posted this and all the comments. I would like to know if you guys educated yourself through trial and error, or does the NGS, or the like, publish papers or articles that go in depth on how to read, understand, edit Rinex/raw GNSS files?

-Thanks