I usually get reasonable results from my antique GPS receiver through OPUS static. Even though the SNR on L2 is poor with its squaring process, it usually gives repeatable results at the few cm level. I have a 2.75-hour file now that I knew was in marginal sky visibility, but I really wanted at least 10 cm accuracy from it. OPUS gives me totally useless results, with pk-pk of meters. Natural Resources Canada seems to process only the code and not phase from this file and isn't good either.
Would processing L1 only, which has better SNR than L2, possibly give better results? I've tried the NASA processing site and it says it doesn't do L1-only.
Maybe it's hopeless, but if somebody can run an L1 RINEX against CORS, I'd appreciate seeing what it gives. Post here if willing, and I'll send you a "conversation" message with a link to the RINEX file.
Bill93, post: 370100, member: 87 wrote: Maybe it's hopeless, but if somebody can run an L1 RINEX against CORS, I'd appreciate seeing what it gives. Post here if willing, and I'll send you a "conversation" message with a link to the RINEX file.
What is the distance to the nearest CORS site? If it's under 30km, I'd be willing to give it a try.
Probably about 6 km to IAMN and 25 km to NLIB.
The others OPUS uses for sessions in this area are IAWN, IATA, and IAMQ all further. OPUS sometimes doesn't use IAMN even when it is closest, which puzzles me.
I guess there is no need to go to a conversation. I'll just link the file here.
https://dl.dropboxusercontent.com/u/25124076/HAS31161.16o
Bill, email me the L1/L2 "O" & "N" file.
Paul in PA
Bill93, post: 370100, member: 87 wrote: I usually get reasonable results from my antique GPS receiver through OPUS static. Even though the SNR on L2 is poor with its squaring process, it usually gives repeatable results at the few cm level. I have a 2.75-hour file now that I knew was in marginal sky visibility, but I really wanted at least 10 cm accuracy from it. OPUS gives me totally useless results, with pk-pk of meters. Natural Resources Canada seems to process only the code and not phase from this file and isn't good either.
Would processing L1 only, which has better SNR than L2, possibly give better results? I've tried the NASA processing site and it says it doesn't do L1-only.
Maybe it's hopeless, but if somebody can run an L1 RINEX against CORS, I'd appreciate seeing what it gives. Post here if willing, and I'll send you a "conversation" message with a link to the RINEX file.
Bill,
I am uncertain of your old equipment, but I have had poor results with processing opus fast static for two days in a row, wait a week and retry and it works wonderfully.
To my understanding, Cors uses three data sets of ascending accuracy. The longer you wait, the better the Cors data set to process against is.
summerprophet:
I ran the L1/L2 file soon enough that it used ultra-rapid data, then again when it had rapid data. People usually report, and it fits my experience, that waiting for the final" precise" data makes less than a cm difference. I usually do run them for "precise" results but don't expect that to help this file.
See this link for information about availability, but add a little time for the data to get onward to NGS.
https://igscb.jpl.nasa.gov/components/prods_cb.html
--------------------
Paul:
The original L1/L2 data is at
https://dl.dropboxusercontent.com/u/25124076/HAS31160.16n
https://dl.dropboxusercontent.com/u/25124076/HAS31160.16o
I do not know how to handle the deficiencies in your L2 data. First there is zero, nada, no P2, did you somehow filter it wrong? That ancient receiver should have output P2 data, not C2 of which there is also none.
Secondly, much of the L2 data is not a factor of the L1 data. In general the L1 and L2 output is a factor of the difference in L1/L2 frequencies, i.e. 1.57542 GHz / 1.22760GHz = 1.283333.
Paul in PA
Bill, I get the following NAD83(2011)Epoch 2010.0 coordinates (Lat, Long, EHgt) for your new station, HAS3:
HAS3 42-00-29.606730 91-36-48.213803 245.8288m
These are based upon the following positions for the L1 Phase Centers of the CORS sites NLIB and IAMN
# NAD83(2011)Epoch 2010.0
.UNITS METERS
PH IAMN 42-01-49.08333 091-32-55.55589 230.015 ! ! ! 'IAMN L1 PC
PH NLIB 41-46-17.70039 091-34-29.59180 208.762 ! ! * 'NLIB L1 PC
I didn't use the ellipsoid height of NLIB as control because IAMN is much closer to your site.
Here are the GPS vectors in Star*Net format:
.GPS WEIGHT COVARIANCE
G0 'V2 Day116(0) 18:00 00027012.ssf
G1 IAMN-NLIB -2689.414884 -19109.764033 -21403.303092
G2 5.52737839064812E-007 1.99490543914001E-005 1.60238676472026E-005
G3 3.39128535033550E-007 -4.03338693537351E-007 -1.72925429302287E-005
G0 'V1 Day116(0) 18:46 00027020.ssf
G1 NLIB-HAS3 -2707.161630 17604.886513 19592.036404
G2 1.37271749064709E-006 6.73274287057260E-005 5.42018412371334E-005
G3 2.71738304402986E-006 -2.55301771668861E-006 -5.87904809269646E-005
G0 'V3 Day116(0) 18:46 00027016.ssf
G1 IAMN-HAS3 -5396.567100 -1504.916766 -1811.217513
G2 9.65645217743906E-007 4.26897090668729E-005 3.54005395179912E-005
G3 1.68709753738806E-006 -1.71087200144185E-006 -3.76353874240817E-005
OPUS wouldn't process this, said your receiver was moving around too much.
Just for kicks I used RTKLIB to static process it against IAEL, GPS L1 only, broadcast orbits and an AR validation ratio of 3.
If I do it with L1/L2 it comes out a little better, but not by much.
The key doesn't show up in these images. Green = Fixed, Yellow = Float, Red = Single.
GROUND TRACK
POSITION
VELOCITY
NUMBER OF SATELLITES, AGE OF CORRECTIONS, RATIO FACTOR FOR AMBIGUITY RESOLUTION
Kent McMillan, post: 370113, member: 3 wrote: Bill, I get the following NAD83(2011)Epoch 2010.0 coordinates (Lat, Long, EHgt) for your new station, HAS3:
HAS3 42-00-29.606730 91-36-48.213803 245.8288m
These are based upon the following positions for the L1 Phase Centers of the CORS sites NLIB and IAMN
# NAD83(2011)Epoch 2010.0
.UNITS METERS
PH IAMN 42-01-49.08333 091-32-55.55589 230.015 ! ! ! 'IAMN L1 PC
PH NLIB 41-46-17.70039 091-34-29.59180 208.762 ! ! * 'NLIB L1 PCI didn't use the ellipsoid height of NLIB as control because IAMN is much closer to your site.
BTW, these are the estimated uncertainties (standard errors) of the components of the above position of HAS3 relative to IAMN L1 PC:
AS3 sN=0.009m sE=0.008m sH=0.077m
As a footnote, I think that "obstructed" is a fair adjective to describe the point you occupied with your equipment.
@42.0083277,-91.6134187,3a,75y,177.47h,77.65t/data=!3m7!1e1!3m5!1s29E_onRv1DJrS06VvtJGaQ!2e0!6s%2F%2Fgeo3.ggpht.com%2Fcbk%3Fpanoid%3D29E_onRv1DJrS06VvtJGaQ%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D92.815193%26pitch%3D0!7i13312!8i6656!4m2!3m1!1s0x0:0x0?hl=en"> https://www.google.com/maps/place/42%C2%B00 0'29.6%22N+91%C2%B036'48.2%22W/@42.0083277,-91.6134187,3a,75y,177.47h,77.65t/data=!3m7!1e1!3m5!1s29E_onRv1DJrS06VvtJGaQ!2e0!6s%2F%2Fgeo3.ggpht.com%2Fcbk%3Fpanoid%3D29E_onRv1DJrS06VvtJGaQ%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D92.815193%26pitch%3D0!7i13312!8i6656!4m2!3m1!1s0x0:0x0?hl=en
Thanks, Kent. That result, and especially the uncertainty, are amazing! Yes, I knew I was pushing it and expected a larger uncertainty than that. But it was an important point to test an idea as I'll explain in another thread. The angle of the aerial photo makes it look a little worse than it does from the ground, but indeed there is too much conifer to the east and other obstacles around.
This was RM3 for 2nd order triangulation station NJ0769 HAAS. I'll be submitting a recovery report. The station itself is a foot and a half from the big tree in front of the house on the north side. A probe and metal detector say it is there, but I'd have to move pavers and dig a 15 inches deep hole in their yard to get there and then still have the tree problem. RM2 is inside the drip line for another tree just north of the street and between the lots, pretty much under a lilac bush, and a session on it gave worse OPUS results than RM3.
So I'm really happy with your report.
I'll have to digest the details of your post and that from astrodanco later.
Kent McMillan, post: 370118, member: 3 wrote: these are the estimated uncertainties (standard errors) of the components of the above position
Did you instruct Star*Net to scale the standard errors in arriving at those results? Older Trimble equipment can be a tad optimistic in this regard.
Jim Frame, post: 370138, member: 10 wrote: Did you instruct Star*Net to scale the standard errors in arriving at those results? Older Trimble equipment can be a tad optimistic in this regard.
Yes, that's with a scalar of 10 on both H and V components, which is larger than the value of 6 I ordinarily use.
Here are what Star*Net reports as the residuals of the adjusted vectors between the three control points. Note that I did not hold the ellipsoid height of NLIB L1 PC as a contraint in the adjustment, just the horizontal components of the station coordinates.
Note that IAMN-NLIB is an L1/L2 solution.
Just as an exercise, I calculated the position of HAAS from RM3 (HAS3 above) using the azimuth and distance between the stations as given on the NGS data sheet. The published NAD83(1996) coordinates of HAAS as derived from triangulation only differ by 0.30m from what one would calculate from the NAD83(2011)Epoch 2010.0 coordinates of RM3 as derived above.
Yes, that's about the shift I calculated from your coordinates. The significance or insignificance of that difference is the subject of https://surveyorconnect.com/threads/nad83-harn-to-nad83-2011.326594/&apos ;">another thread.
What tools did you use to process the Rinex file?
did you check the time series for the cors stations?
I disabled some signals and processed in TBC against IAMN and for HAS3 I got
N42å¡00'29,60743"
W91å¡36'48,21281"
245,856
for IAMN I used these published ccords:
| NAD_83 (2011) POSITION (EPOCH 2010.0) |
| Transformed from IGS08 (epoch 2005.0) position in Jan 2014. |
| X = -128244.510 m latitude = 42 01 49.08333 N |
| Y = -4743183.715 m longitude = 091 32 55.55589 W |
| Z = 4248258.393 m ellipsoid height = 230.015 m
Dane Mince, post: 370203, member: 296 wrote: did you check the time series for the cors stations?
Yes, but there were no significant discrepancies. The NAD83 velocities of two CORS sites 28 km distant in Iowa should be nearly identical and they are shown to be in the NGS data sheets for NLIB and IAMN.
The out-of-synch deviations of the station coordinates shown by the short-term time series are in the N components, but are less than 1cm.