This has been a remarkable education, both into the realm of the unknown and into the bowels of our software..and into the darker side of the Navstar system....

First, let me post final final coordinates for the first experiment, then some conclusions...
All values are in US Feet...

Fixed WNFL Only..
Post
N 6835851.546 (0.04)
E 3100685.760 (0.03)
El 404.101 (1.122)

Fixed ARL5 Only..
Post
N 6835851.514 (0.01)
E 3100685.512 (0.022)
El 403.627 (0.648)

Fixed DQUA Only..
Post
N 6835851.634 (0.13)
E 3100685.583 (0.15)
El 403.586 (0.607)

Fixed Patt Only..
Post
N 6835851.425 (0.08)
E 3100685.578 (0.015)
El 403.353 (0.37)

Fixed Patt,WNFL,ARL5,DQUA..
Post
N 6835851.507 (0.002)
E 3100685.614 (0.12)
El 403.618 (0.639)

What did I do differently? Raised the mask much higher as JD did..Why? After lot's of searching, reading and calculating, I determined that on these long baselines that the tropo was a significant factor (which is why I didn't use the humid Houston station at all)...
I usually try and keep the mask much lower (these were all at 18 degrees), but I also usually process lines that meet the spec's for the equipment, not these humongosaurus type lines...

I also was very careful to maintain at least 5 SV's (or more) and didn't worry about whether it was a fixed solution. My software didn't fix any but the CORS to CORS stations (and that was using the dual frequency to process)...all the rest reported floats..

I did process between the CORS (as a check on the session data itself. Satisfied that these were okay, then any error would be attributed to the lines to POST only, which is what started this whole exercise in the first place...

What fun we're having.....

I'll post the math later, for those interested in the calculation of the tropo error (at least what got me pointed in the right direction)...JD was right about the mask, and I'm thinking that this explains why the mask is so important on the longer lines...The higher mask (looking at the mission planning) has a downside in that our vertical starts to unravel a bit, which is why it tended to jump around. Don't think it had anything to do with the geoid model, but more with our SV constellation strength..

TM

Trimbo

I still think you'll get better results with HOUS in the mix. But I can't guarantee that. Just my personal observation from processing all three sessions.

Also, you never did tell me if you accounted for the 0.125m (0.41') height of the Locus L1 antenna above the ARP. I think I sent you that info in an email with the Test 1 file. If you are reporting the vertical of "POST" as to the L1 antenna, then we can cut 0.41 foot and say your vertical is 403.208 feet. That's now within 0.356 of the mean of my three observations.

Just wanted to remind you that my reported numbers for POST are all related to the ARP, not the antenna.

Also, you said something about processing the L2 stuff. Did you not try to process the entire project with L1 only?

I'm glad you follow my thinking about leaving all vectors in the processing, including CORS to CORS. Even though the CORS coords are held fixed, I'm just thinking the software evaluates the differences between the solved vectors and the computed vectors (from the fixed coords) and uses that info for weighting the various vectors into the unknown. In this case POST.

Also, thanks for pointing out the troposphere effects. I failed to include that in my reasoning for the higher (and different for each vector) mask angles. Kinda got stuck on the ionosphere.

Interesting project. Glad you guys are part of it.

Thanks

J.D.

Processed all baselines using the precise eph's from JPL...and fixed elevation error using wrong ARP for POST

Fixed Pratt,ARL5,DQUA,WNFL
N 6835851.515 (0.01)
E 3100685.560 (0.17)
El 402.990 (0.01)

Fixed WNFL Only...
N 6835851.501 (0.004)
E 3100685.623 (0.10)
El 402.920 (0.05)

Fixed ARL5 Only..
N6835851.490 (0.01)
E 3100685.504 (0.22)
El 402.889 (0.09)

Fixed Dqua Only..
N 6835851.593 (0.09)
E 3100685.605 (.12)
El 402.729 (0.25)

Fixed Patt Only..
N 6835851.490 (.01)
E 3100685.653 (0.08)
El 402.893 (0.08)

JD...When each of these solutions was done, the only point fixed was the one noted...The entire network is calculated based upon that one coordinate..Interestingly, the shift at the CORS was very minimal (as it should be since these are L1/L2 lines on the perimeter)..

When processing the vectors using the precise ephemeride it really took a bite out of the RefVar and dropped all the RMS by about half...for example

ARL5-Patt
Ratio RefVar RMS
10.5 3.769 0.028
10.6 1.416 0.013

WNFL-JD
Ratio Refvar RMS
0 220.245 0.049
0 161.782 0.045

Top is before precise, bottom is with precise eph...

I've got some idea's (yes, some are probably half cooked) on the solution for long baseline tropospheric re-correlation.....

More Later...It may be Sunday, but I'm ready for a brew at this point....

TM

JD...And thanks for starting this...I've really learned alot about my software (and yours) in this process...

!

Got any more yellow pads and lead..I'm about out!
TM

Naah,

I've been writin on my desk. Kinda hard to get it on the copy machine though.

Opus Discussion Page


Links to some other info are on this page also.

Jimbo
Modified By James Webb on 12/16/2001 at 8:08 PM

It would be interesting to reprocess the vectors that Deral did, but using the current ITRF positions for the CORS points as well as precise orbits. Unless I'm sleeping through the picture show (always a possibility), a significant part of the small descrepancies that Deral reported for the individual vectors is simply due to the rotation of the ITRF reference frame with respect to NAD83, a systematic error that is readily eliminated by using ITRF coordinates for the CORS points.

The peak-to-peak differences of the individual ITRF vectors could be used, following NGS's methodology, to derive uncertainty estimates for the position of POST based upon all CORS-to-POST vectors.

Best regards,
Kent McMillan, RPLS Austin TX

Would you agree that once I get a dual frequency position (CORS and OPUS) on the POST, we'll have something to actually make comparisons to. At the moment it seems that all three of my sessions are pretty much in the acceptable range of L1 as far as repeatability. Deral's numbers, especially horizontal, are right in the mix. I think we are now on the way of at least proving that L1 only can produce some fairly good results, although we do lack the ability (or at least I do) of quality analysis for these types of vectors.

As for the ITRF shift/rotation, it would definately be in order, given the L1 only results are of sufficient quality to make the ITRF changes noticable.

J.D.

p.s. please keep in mind, I'm only processing L1 from the CORS. In my little world there's no other frequency. (yet)


pps When considering Deral's coordinates, I'm still looking at the fully constrained coordinates. Not the individual vectors. I'm still stuck on the full constraint from all CORS in the solution as being my final target.

Modified By J.D. Billings on 12/17/2001 at 1:03 AM

J.D.:

For reasons that I touched on in other posts, it seems to me that the best test would be to process dual-frequency data in either OPUS or commercial software to derive the ITRF position of POST at the Stumpwater Proving Ground. That would be the value to use in comparing the ITRF positions obtained using only L1 solutions from various CORS points.

I'll be quite interested to learn the results.

Best regards,
Kent McMillan, RPLS Austin TX