As I see it, we have three problems...

First...The Actual SV orbits...This can be overcome by using the precise ephemerides...Where this becomes a point (distance wise) will be studied...Maybe a breakline can be determined where it doesn't matter and where it "must" be applied...I'm thinking that simple statistics can prove where this point will lie on our plane of distances...

Second...The Tropo...I think that this affects the L1 as well as the L1/L2 and it seems evident by our experiments, that raising the mask can negate much of this during long sessions times..Much more can be done by some sort of incorporation of the measured met file in the CORS versus user position. I'd think that some weighted mean could be applied on a station basis, using the SV angle/azimuth and weather data...For instance, if one of the CORS was experiencing a storm, then this could be passed to the other stations, noting that this can cause rather large delays pertaining to this station. This delay can be incorporated into the users solution based on SV angle/azimuth through the storm area....I'm probably making this clear as mud, but I'm thinking that since each CORS is operating 24/7 and that they can correlate the Iono, then the tropo is what is left, and that the station should be able to determine the residual from the measurements..This residual number (from each CORS) and based on the initial position of the user, could be used instead of the modeled file (which is slow to change rate and doesn't accuractly reflect the minute by minute changes....The math might get deep, but hey, that's what computers do well...You'd have to compare the user path to SV and the CORS path to SV to correlate the effects for each SV and somehow pass this to the solution process...

The Iono...This seems to be at the crux of the L1 versus L1/L2 on long baselines...Why can't each CORS, which can determine the Iono correction directly (by double differencing) pass this result to the total solution of the users point. Let's assume three CORS which, when processed against each other determine the Iono correction for each station...They could then pass this correction to the user, who's software would do a modeled 'on the fly' Iono correction based on the relation of their Lat/Long to each CORS...Basically, I'm saying that each CORS passes some parameters to the user, who's unit builds a matrix of 'best fit' solutions for it's initial fix...
Better yet...With the advances of the CODE fix(and it's resolution), Why not use this to double difference against the L1 solution to provide a modified Iono Free solution...


TM

TM,

That all sounds great, if your software handles L2. Many of us here are L1 only , both receivers and software.

JD

All the above was applied to the L1 only solution.The mention of L1/L2 was to propose what we can do with L1 to try and model what the L2 does...All receivers (L1 only) also can use the code solution (it's usually the first pass in the processing solution, although it never displays that it calculated the code position)..
Using the precise eph works on L1 only 'as is' after you import the file..

Maybe my post rambled to much and got confusing. I know that a couple of Kent's have lost me on the ITFR stuff..I try to keep up with him, but sometimes I just can't peddle fast enough..

TM
Modified By Trimble Man on 12/19/2001 at 4:21 AM

TM,

AS doesn't currently support the precise eph. from what I understand...see brian's post back there somewhere...a few days ago.

Jimbo

TM:

Using ITRF in this exercise is nothing all that complicated.

Step One - Get ITRF97 coordinates of CORS points from data sheets.

Step Two - Substitute ITRF97 coordinates in vector processor (ECEF or lat/long)

Step Three - Process CORS-POST vectors using precise ephemeris.

Step Four - Adjust CORS-POST vectors and marvel at improvement in precision.

Step Five - Choose method to convert/transform ITRF97 position of POST to NADwhatever and convert.

Step Six - Examine answer.

Step Seven (optional) - Drop McMillan a note saying "you're right, that wasn't hard, even for an Oklahoman, and made a significant improvement."

Best regards,
Kent McMillan, RPLS Austin TX


Modified By Kent McMillan on 12/19/2001 at 9:32 AM

Kent,

TM isn't alone, I'm still trying to find the peddles myself.

Step 5 is one of those programs in the geodetic kit on the NGS site right ?????

Jimbo

Jimbo:

Transforming the ITRF97 position of the point sought (POST in thise case) into NAD83 (1997.0) could be done several ways. Since I'm unfamiliar with the utilities in the Ashtech software, I don't know what method would be easiest for Locus and PM2 users.

One way, however, is by a 7-parameter transformation (deltaX,Y,Z; rotX,Y,Z; and scale). In ECEF coordinates, it is a straightforward 3D Helmert transformation. It seems to me that John Hamilton was looking for some freeware to do this and found some on a University of Pennsylvania College of Engineering website.

Another way is to find a programmed solution that will apply the rotations that define the relation between NAD83 (1997.0) and ITRF97 to the vectors. In otherwords, change the raw GPS vectors from ITRF to NAD83. The rotations about the X,Y, and Z axes are published by NGS.

Another way (and the one that I plan to use) is just to bring the CORS-POST vectors into Star*Net-GPS for adjustment. I'll use the NAD83(1997.0) lats. and longs. of the CORS points as fixed conditions and let Star*Net solve the rotations and scalar to be applied to the ITRF97 vectors to get a best fit.

The rotations are applied to the vectors before they are adjusted, so the residuals are reduced by the systematic errors of the difference in reference frames. I would expect the scalar to be 1.00000000 since there is no significant scale difference between the ITRF and NAD83 reference frames. However, unmodelled ionospheric and tropospheric effects may result in systematic scale errors in the vectors that are best accounted for by letting their scale vary in the adjustment.

Best regards,
Kent McMillan, RPLS Austin TX

Kent,

I haven't run it but on the NGS site from my understanding of the program description their HTDP program should do the coordinate transformation....

From the NGS webpage description:

....The software also enables users to update geodetic positions and/or geodetic observations to a user-specified date. Because HTDP supports these activities for coordinates in the North American Datum of 1983 (NAD_83) as well as in all official realizations of the International Terrestrial Reference Frame (ITRF), this software may be used to transform geodetic coordinates between any pair of these reference frames in a manner that rigorously addresses differences among the definitions of their respective velocity fields. ..........

They have a download version and an on-line interactive version.....

Still peddling,

Jimbo

I kinda asked the same question a couple of weeks ago myself. I did try to use the HTDP program, but didn't make it past the data entry. Wasn't exactly sure what date to use for the start date. Actually wasn't too sure about anything.

My tricycle needs training wheels too.

J.D.

I compared the ITRF and the NAD83 on several sessions...No difference in the correlation of these points...Which makes me believe, that ITFR isn't better, only different....
Kent....Go slow and please use small words for us Okies and explain how using ITRF will reduce our adjustment errors....
Guess I just don't get it...We are trying to reach NAD-83 coordinates for POST.... I'm adjusting purely in geodetic, then converting to NAD-83..(at the last moment)....

TM- I need training wheels on my desk at this point...

for those of us recently overexposed to high intensity laser....

Man this is good stuff. I almost feel guilty, like I'm cheating the institutions of higher learning...naaahh

My son just came in the room..His question? Why do you have all these manuals open, a dictionary on your desk, three yellow pads with scribbling, while there is COLD BEER in the refrig....
Guess I have to agree with him and go ofline, so he can download the latest song, while I upload a cold beverage...
TM- This stuff SHOULD qualify as continuing education.....!!!!!

Okay, here's a shot at trying to explain why ITRF coordinates should give smaller residuals in the adjustment. The effect isn't huge, but should be measurable.

I haven't calculated the differences between the ITRF and NAD83 reference frames at J.D.'s station POST, but I'd expect one system to be rotated (neglecting signs) by approximately:
0.014 seconds about the North axis,
0.019 seconds about the East axis,
and
0.006 seconds about the Up axis.

The 0.006" rotation around the Up axis is equivalent to using coordinate systems with bearing bases that differ by that amount. Insignificant over short distances, small but measurable effects as lines get longer. In effect, the ITRF GPS vectors have a bearing bias of 0.006" or so with respect to NAD83.
This is not a cause of heartburn at 200km since the residual horizontal error resulting from the rotation about the Up axis is only going to be on the order of 6mm or so.

On the other hand, the fact that ITRF is "tilted" with respect to NAD83 at POST by 0.014" - 0.019" introduces a residual in the vertical on the order of 14mm to 18mm over vectors 200km in length.

TM: Did I understand that reprocessing your vectors in ITRF and adjusting them to the ITRF coordinates of the CORS did not give you smaller residuals at POST???

Best regards,
Kent McMillan, RPLS Austin TX

What is the difference in WGS84 and ITRF? Are they the same thing?
Thank you for your consideration Mr. Kent

http://www.ngs.noaa.gov/CORS/metadata1/

Light????

I spent a couple of hours pondering that site last week (or week before?) and now you sent me back to it again. Phil, you're a hard taskmaster.

I'm still wondering how much difference there is in the "current" positions of the CORS sites I used and their published NAD83 coordinates stated to have been transformed from ITRF96 values to NAD83 in April-July of 2000.

I suppose I'll have to go back again to the HTDP program and keep plugging til I make it spit out some "current" numbers, if that is the proper procedure.

By the way, the "independent" dual frequency positioning on POST is scheduled for Thursday a.m. after Christmas. Hopefully we'll have a successful session to process to my same 5 "benchmark" CORS stations, as well as submit to OPUS. Then, surely we'll have some acceptable coordinates to compare my L1 only results to. Hopefully before the new year I'll have some numbers.

J.D.