Bill93, post: 370187, member: 87 wrote: Yes, that's about the shift I calculated from your coordinates. The significance or insignificance of that difference is the subject of another thread.
What tools did you use to process the Rinex file?
I used the RinexDates1.8 program developed by Christ Lambrecht et al to backdate the RINEX files to a date that Trimble's WAVE 2.35a processor would recognize. It generated new RINEX files with the same data, but an older date.
Then I processed the backdated RINEX files using Trimble's legacy GPSurvey software (both it and TGO use the WAVE 2.35a processing engine). Some intervention was needed in the form of disabling some SVs with exceptionally noisy contributions.
The vector solutions generated by the Trimble software were imported into Star*Net Pro V6.0. and the three vectors were adjusted, residuals tested, and error propagation performed.
Yuriy Lutsyshyn, post: 370204, member: 2507 wrote: 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
Just out of curiosity, what were the standard errors of that position that TBC estimated relative to IAMN?
Kent McMillan, post: 370226, member: 3 wrote: Just out of curiosity, what were the standard errors of that position that TBC estimated relative to IAMN?
There is no redundant vectors to HAS3 in my project and TBC did not produce accuracy estimation for the point (I could not find it) but it does have the estimation for the vector itself:
Standard Errors
Vector Errors:
s DEasting 0,002 m s NS Fwd Azimuth 0å¡00'00" s DX 0,002 m
s DNorthing 0,002 m s Ellipsoid Dist. 0,002 m s DY 0,010 m
s DElevation 0,013 m s DHeight 0,013 m s DZ 0,009 m
more vector details:
Processed: 01.05.2016 23:49:59
Solution Type: Fixed
Frequency used: L1 only
Horizontal Precision: 0,005 m
Vertical Precision: 0,025 m
RMS: 0,039 m
Ratio: 2,101
Ephemeris used: Broadcast
Antenna Model: US National Geodetic Survey, ant_info.003
Processing Start Time: 25.04.2016 20:45:45 (Local: UTC0hr)
Processing Stop Time: 25.04.2016 23:30:45 (Local: UTC0hr)
Processing Duration: 02:45:00
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.
I'd be happy to try
Yuriy Lutsyshyn, post: 370256, member: 2507 wrote: TBC did not produce accuracy estimation for the point (I could not find it) but it does have the estimation for the vector itself:
Standard Errors
Vector Errors:
s DEasting 0,002 m s NS Fwd Azimuth 0å¡00'00" s DX 0,002 m
s DNorthing 0,002 m s Ellipsoid Dist. 0,002 m s DY 0,010 m
s DElevation 0,013 m s DHeight 0,013 m s DZ 0,009 m
In your experience, do the standard errors of vector components that TBC generates need to be scaled in an adjustment to pass the chi square test? If so, what range of values of scalars is typical?
Out of curiosity, I reran the Star*Net adjustment of the the GPS vectors, omitting NLIB-HAS3 and plotting the estimated 95% confidence ellipse for HAS3 at 1:1 scale to see whether HAS3tbc (the position that Yuriy reported that TBC had generated) was within the area bounded by the ellipse or not. To give an idea of scale: the distance from HAS3 to HAS3tbc is 0.021m with a height difference of 0.007m.
In other words, the discrepancy in the results of the two different processing engines is nominally 2cm horizontal, but is not inconsistent with the uncertainties expected from the WAVE 2.35a baseline solution (after scaling the standard errors).
Kent McMillan, post: 370261, member: 3 wrote: In your experience, do the standard errors of vector components that TBC generates need to be scaled in an adjustment to pass the chi square test? If so, what range of values of scalars is typical?
Thank you for having a better impression about my skills than I actually have, .. here if we check conventionally to gps something like 1/5000 it is already called good for boundary or a survey network for a topo.
Networks for construction projects would require more perfect measurements and perfect adjustment strategy, I have been dealing only with the measurement, so shamefully I do not really know what factor would lead to the pass of the test at given standard errors in this example.
I do struggle with statistics while developing my own rtk app for android, unfortunately error are not Gaussian all the time and understanding nature of correlation is way harder than just take a measurement in the filed.
In this project disabled some more cycle slipped signal portions from some satellites and this time I got
N42å¡00'29,60693"
W91å¡36'48,21336"
245,958
Yuriy Lutsyshyn, post: 370324, member: 2507 wrote: In this project disabled some more cycle slipped signal portions from some satellites and this time I got
N42å¡00'29,60693"
W91å¡36'48,21336"
245,958
Removing the segments of data with lots of cycle slips does shift the solution within 5mm horizontally of what Trimble's old WAVE 2.35a processor generated. The above is the point labeled HAS3tbc2 in the plot below. The 0.109m discrepancy in the Up components of HAS3 and HAStbc2 is not unlikely since the WAVE baseline solution that generated the coordinates of HAS3 had an Up uncertainty of +/-0.172m (95% confidence).
