Parts of the following discussion hold only where CORS, and stations being positioned using them, do not move relative to one another. This certainly holds for points in and around Texas, Oklahoma,and Louisiana, except for places along the Gulf Coast (like Houston) where subsidence is occuring. In areas like California more complicated proceedures are needed.

The computation of coordinates using GPS carrier phase observations can be considered as a two step operation. Step 1: Compute vectors (ie coordinate differences). Step 2: Use the vectors to compute station coordinates.

To perform Step 1 one uses, in addition to observations, satellite coordinates (orbits) and the coordinates of one station of the station pair for a vector. Coming out of Step 1 will be coordinate differences for each of the vectors computed. These vector coordinate differences are referenced to the coordinate system to which the input satellite coordinates are referenced.

A number of coordinate systems have been used for satellite coordinates the last few years, eg WGS 84, ITRF 97, ITRF00, IGS00. However, one can treat these different coordinate systems, for the purposes of vector computation, as being identical without introducing an error of more than about 3 mm (.01 ft) at most, so long as vectors are no more than 300 km in length. This is the case because what is important about coordinate systems used for satellite coordinates in vector computation is axes orientation and scale. These coordinate systems have scales that agree at the 1 to 2 parts per billion level and orientations that agree at the few milli-arcsecond level. So for the rest of this discussion I will use IGS00 to designate the satellite coordinate system being used.

In step 1 the effect of using coordinates for the fixed station that are referenced to a different coordinate system than IGS00 does introduce error in the computed IGS00 vector coordinate differences. But these errors are not very large. The choices for CORS station coordinates are NAD 83 and ITRF 97 (1997.0). If one uses ITRF 97 (1997.0) coordinates in the vector computations, the error introduced in the computed IGS00 coordinate differences is sub millimeter. For lines 200 kms long using NAD 83 coordinates for the CORS station will result in errors that can be in the 3 to 4 mm range.

The bottom line is that no matter which of the available coordinate systems you use in step 1 and how you mix them you are going to come out with vectors that you can consider as giving coordinate differences referenced to the IGS00 coordinate system that have errors due to coordinate system approximations and mixing that are less than 1 cm.

The important thing in getting the best vector accuracy out of step 1 is to use the best available satellite coordinate information. A study done in 2001 got the following standard errors for the various types of satellite coordinates: broadcast orbit: 270 cm: ultra rapid orbit, 30 to 40 cm; rapid orbit 10 cm; precise orbit. 5 cm. This accuracy improvement between broadcast and precise of more than a factor of 50 shows up in the accuracy of vector coordinate differences for long baselines, and in the ease of fixing integers and amount of data needed.

For step 2 the inputs are the vectors from step1 and the coordinates of the CORS stations to be held fixed in the adjustment. The output will be the coordinates of the station or stations being positioned. These output coordinates will be referenced to the coordinate system to which the coordinates of the CORS stations that are input to step 2 are referenced. Note that it is entirely possible to use CORS station coordinates referenced to one coordinate system in step 1 and a different coordinate system in step 2.

Suppose in step 2 one is going to use vectors from a single CORS station to position another station. Then, if the CORS coordinates are introduced as ITRF97 (1997.0) coord
Modified By Mr Geodesist on 1/13/2002 at 10:23 PM

Thanks Mr.G, we've been waiting all weekend for this promised bit of wisdom. Either I'm learning something as I get older, or you've developed the ability to communicate on a lower level these last few weeks. The latter probably holds true.

You made the point well concerning the "mixing" of coordinate systems. The same point Kent has apparantly been trying to impress upon us for quite some time now. I believe you accurately described the reasoning for my apparant success in the 3 independent multi-CORS sessions to POST, in that the geometry created by the various CORS sites helped mean out some of the error. That was more or less what I was trying to claim to be the case early on in my experiment. I think I used the East Texas shade tree physicist terminology of "squishing the errors to the middle". Do you agree now that regardless of what reference frame or coordinate system is used, that better results may be possible due to geometric placement of the known and unknown points?

I would like to see a very simple, step by step (o.k. detailed) explaination on the use of ITRF system coordinates, as well as getting them into NAD83. No doubt that you Mr. G, or Kent can provide that information in some thing along the lines of "paint by numbers" instructions.

As for precise ephemeris......damn good point. Until I started playing with this little experiment I had no knowledge or understanding of the value of a "way after the fact" precise ephemeris. Now I do have the knowledge of it, and a decent understanding of the value. I also can't see why it should be a problem to have a feature in any processing software to make use of the precise ephemeris. UNFORTUNATELY, there are many of us that do not have this routine available, so we are stuck with broadcast ephemeris. Thence, back to the point of beginning and surrounding myself with multiple CORS stations in hopes of squishing some of the error to the middle.

J.D.

J.D.:

Here's just one point about using Precise Orbits. The IGS Rapid Orbits are available within about 17 hours.

The Final Orbits are delayed by about 13 days or so presently and from what I've seen of the Rapid Orbits, for lines under 300 km I'm not sure whether the Finals are worth the wait.

I'll reprocess the L1 vector from MDO1 to PIE1 when the Final Orbits for 1/09/2002 are available and let y'all know what improvements, if any, appeared.

Best regards,
Kent McMillan, RPLS Austin TX
Modified By Kent McMillan on 1/14/2002 at 10:38 AM

Kent

Give me a "quickie lesson" in downloading the IGS Rapid Orbit. One thing I need to know is what format is it in. I'm wondering if I can bring it in as a Rinex "n" file.
Also, does each station use the same downloaded rapid orbit file?

Damn. Another project. Now I have to figure out a way to make my software let me use the better ephemerides, or I'm sidelined when you get OPIE off the ground.

J.D. , stuck in ORGI land

I would agree that the difference between using the Rapid orbits vs using the Precise orbits is seldom going to be worth the wait for vectors 300 km or less in length. I would think that using the Rapid orbits rather than the Ultra rapid orbits would be worthwhile, if for no other reason than the fact that the Ultra rapid orbits are predicted orbits (at least they were the last time I looked which admittedly is not recently) while the Rapid orbits are computed after the fact. With predictions there is always the chance something can happen to a satellite after the predictions are made.

J.D.:

I use the CORS ftp site to download CORS and ephemeris data. Here is the link to 1/12/2002:

CORS Data for 1/12/2002

The file igr1486.sp3.gz contains the IGS Rapid Orbits for day 12, zipped.

You just need one, since the orbits are independent of the CORS points.

The file once unzipped is in so-called sp3 format, which I don't believe is similar enough to the nav files in structure to do you any good if your processor won't handle sp3 or ef18 formats. I'm subject to correction (as always) on that point.

Best regards,
Kent McMillan, RPLS Austin TX

An alternate source for precise ephemerides is NIMA. They produce a precise orbit with currently a 5-day latency.

Daily orbits are available via anonymous ftp at:

ftp://164.214.2.65/pub/gig/pedata

Detailed information about the files and how they compare to IGS orbits is available here:

http://164.214.2.59/GandG/sathtml/

BTW, the navigation message (RINEX files currently given the extension: *.02n) contains the orbital elements needed to compute positions of satellites at particular times, they also contain other information not part of the precise orbit files. These elements include the predicted state of the ionosphere, clock correctors (bias, drift and drift rate) and satellite health.

Most processing packages require a that a navigation message be loaded even when the precise orbit is specified.

HTH,

Don

Documentation about the RINEX navigation message is available in a number of locations, one which popped up on GOOGLE is:

http://www.eng.auburn.edu/~yoonseo/gpswww/documents/rinex2.txt

HTH,

Kent and I have argued this point. I say that if you use multiple stations (CORS or whatever) and process your baselines using NAD-83/WGS/Ect, then the absolute station is 'very close to true'...Kent has argued that the ITFR is much better at estimating the actual errors and produces a better point...
From what you posted, then ITFR is only 'better' with one baseline and not with a true network solution, where the error tends to (apologies to JD) 'squish' to the middle...

Guess Kent owes me lunch, but I'll buy the drinks...(on second thought I better buy the lunch and let him buy the drinks)...

What fun were having with all this!

TM

And thanks Mr. G for the post...Sorta sums up what ORGIE/OPIE has shown..

TM



O.R.G.I. 2 the Multi-State Session to be announced soon.


J.D.

Modified By J.D. Billings on 1/14/2002 at 10:22 PM

TM:

Don't tuck in your napkin just yet!

What Mr. Geodesist wrote was:

One can then apply the coordinate
transformation given by NGS to get NAD 83 coordinates with the same level of error due to coordinate mixing. If one uses NAD 83 coordinates for the CORS station in step 2 and the vectors are 200 km long the result will be NAD 83 coordinates for the station that is being positioned that are in error by about 3 cm. This is the case because the NAD 83 and IGS00 coordinate axes are rotated relative to one another by about 30 milli-arcseconds. In step 2 mixing coordinate systems can have a measurable effect.

There is a numerical example coming that should make the point much better.

Best regards,
Kent McMillan, RPLS Austin TX

Modified By Kent McMillan on 1/15/2002 at 2:03 AM

Mr. G also said:

"If the solution for a station such as POST is done using multiple vectors from CORS located in different directions the adjustment will tend to cancel out the errors and one would expect to get somewhat better answers for the station being positioned than 3 mjght be expected."

I may be mistaken, but could this be a part of the "argument".

Proper procedure or not, I think this is what we've discovered with O.R.G.I.
From a purist's standpoint, this procedure is obviously heresey, but the question remains "can it be cleaned up?".

j.d.

J.D.:

My response was specifically to TM's statement that:

From what you posted, then ITRF is only 'better' with one baseline and not with a true network solution, where the error tends to (apologies to JD) 'squish' to the middle...

which is I think plainly wrong. A solution that is free of the bias between NAD83 and ITRFxx (i.e. IGS00 vectors adjusted in ITRF97(1997.0) coordinates rather than NAD83) will always be better from the standpoints of:

(a) actual accuracy of the solution and
(b) more realistic estimation of uncertainty from the residuals.

You will agree I hope that least squares adjustments tend as a general rule to work less well with observations that have systematic errors than those with just random errors.

Best regards,
Kent McMillan, RPLS Austin TX
Modified By Kent McMillan on 1/15/2002 at 11:38 AM

Agreed, I think. I got caught up in a "Jim Frame / so-and-so wrote" moment and couldn't resist.

J.D.

(just kidding, Jim)

J.D.:

Jim Frame may well be the dark hand behind much of what has been going on, the odd word or phrase stopping the flow of the action as dead as a pretzel in the presidential gullet. Jim is always lurking, waiting for that moment when ... out come the italics and ... WHAMMO!

I have often suspected that Jim Frame is actually the system administrator. Otherwise, how can I explain some of the quotes attributed to me that he has produced?

Best regards,
Kent McMillan, RPLS Austin TX

Gee Jim, what did you ever do to McMillan? ;>}

It's just a bit of friendly CA/TX needling. I hold him to a pretty high standard, though, so on the rare occassion that I catch something amiss in one of his posts, I'm apt to comment upon it. (Assuming I can understand it, of course; I still haven't figured out a convenient way to translate ITRF to NAD83...)

Jim:

The neatest method would be simply to transform the IGS00 vectors to NAD83(1997.0) and then adjust them using the NAD83(xx) positions as constraints. This is how OPUS handles the problem I believe.

Can the Ashtech software output the raw GPS vectors in ASCII format and import ASCII format?

It shouldn't be too much of a trick to write a simple program to transform GPS vectors in Star*Net's ASCII format to NAD83 using the NGS rotations. The covariances wouldn't change a bit of course. All that would change would be the DX, DY, and DZ values.

Surely some other reader can offer the fairly simple algorithms to do the transformation for those interested.

Best regards,
Kent McMillan, RPLS Austin
Far Southeastern California
Modified By Kent McMillan on 1/16/2002 at 3:38 AM

For J.D.

You asked for a simple explanation of how to use the ITRF system. So here is what to do if you are positioning POST and want to end up with NAD 83 State Plane coordinates without any errors from mixing coordinate systems.
(a) Proceed exactly as you did in your original computations except in both steps 1 and 2 discussed above input the NGS ITRF97 (1997.0) coordinates of the CORS stations rather than the NAD 83 coordinates as you did in your original computations.
(b) In both steps tell the program you are inputing WGS 84 coordinates. This will make sure the software won't screw you up by making undesired coordinate transformations internally.
(c) Doing (a) and (b) you will get out ITRF97 (1997.0) coordinates for POST. The software will tell you they are WGS 84 coordinates but they are not, they are ITRF97 (1997.0) coordinates.
(d) These ITRF97 (1997.0) coordinates for POST will then need to be run through software that will convert the ITRF97 (1997.0) latitude, longitude, and ellipsoid height to NAD 83 latitude, longitude, and ellipsoid height using the six transformation parameters given on the NGS web site.
(e) If you want to compare State Plane coordinates you would of course then need to convert NAD 83 latitude and longitude to State Plane coordinates.

If you don't have transformation software there is still a quick way to compare the accuracy of using the above approach to the original approach of using NAD 83 coordinates in steps (1) and (2). You have the OPUS results for POST. OPUS gives both ITRF97 (1997.0) coordinates and NAD 83 coordinates.
Difference your original NAD 83 latitudes, longitudes and ellipsoid heights from the OPUS NAD 83 latitudes, longitudes and ellipsoid heights. Now difference your ITRF97 (1997.0) latitudes, longitudes and ellipsoid heights from the OPUS ITRF97 (1997.0) latitudes, longitudes and ellipsoid heights. These latter differences are the same as you would have gotten if you had first converted your POST ITRF97 (1997.0) coordinates to NAD 83 coordinates and then differenced them from the OPUS NAD 83 coordinates. So, by comparing the two sets of differences, you can tell how much the use of ITRF has changed your answers without actually having to perform a coordinate transformation. What you get out initially, of course, are latitude and longitude differences in arc seconds. To get a close approximation to what the State Plane coordinate differences would have been convert angle differences to linear differences using the approximations .001 arc second of latitude equal 3 cm and .001 arc second of longitude equal 2.8 cm. Then a linear difference in latitude is approximately equal to a difference in State Plane north and a linear distance in longitude is approximately equal to a difference in State Plane east.

Think I'll sidestep settling this momentus question. The following things are certain. If you use the same coordinate system for satellite and ground station coordinates throughout computations you will get better results than if you mix coordinates systems. If you mix coordinate systems the larger the differences between the coordinate systems the larger the error will be. If the error from using vectors from a single CORS station are large enough to be considered significant it is possible to reduce these errors by using vectors from multiple CORS stations in different directions from the station being positioned. The amount of error reduction will depend on the specific station geometry in each case. Whether the amount of error reduction in any instance due to using multiple CORS is enough to make the remaining error suffficiently small to be ignored is a matter I leave to the combatents.

Mr. Geodesist:

Didn't you get the enchiladas that I sent via Fedex to assure your impartiality in settling this question? Or were you really wanting kolaches?

Actually, I realize that the point I have been urging is greatly influenced by the arrangement of CORS points in Texas. This means that the sort of "balanced" CORS ties that should tend to cancel errors due to mestizo coordinate systems are not possible in many parts of the state. So it seems to me that finding a way to remove the effects of coordinate system mixing is needed to get the best results from "lopsided" station-to-CORS geometry.

To help you with this related question, I'm going to ask my staff to ship some real salsa picante to you as soon as possible.

Best regards at lunchtime,
Kent McMillan RPLS Austin TX
Modified By Kent McMillan on 1/16/2002 at 3:41 PM

in your behaviour. Bribery should be totally out of the question.

Now, we do need to have a "get together" somewhere in the next few months to hash this out. At $1.25/lb, according to the latest from the Cajun Kitchen Research Department, a crawfish boil is in order. I'll even do all the cookin'.

Bribery.....who'd a thunk it.


j.d. dissapointed in stumpwater

J.D.:

Bribery is such a harsh word. Salsa picante and enchiladas are just two of the necessary food groups that are not so readily available in the eastern US. Without eating a balanced diet, how is Mr. G, a professional geodesist and former Texan, supposed to muster the energy to unlighten us poor old land surveyors? I haven't even mentioned lunch from the Dixie Chicken, have I?

Actually, what is needed is some ITRF Ale. Can you put the Stumpwater Brewing Company to work on the problem? A bit like IPA, only vary the proportions by about 1ppb.

Best regards from your overworked colleague,
Kent McMillan, RPLS Austin TX

The Stumpwater Brewery will be up and running on Saturday. The special of the day will be ORGI2001 Pale Ale. Fresh grain was received today as well as fresh yeast, so brew day is a comin'.

Now, the real question is: Are you ready for ITFR/OPIE/2002???????

When we get the ORGI 2 data together, in other words a whole slew of L1 units 8 hour sessions, are you ready to do your ITFR and precise ephemeris magic?????

J.D.

J.D.:

The ITRF and precise orbits aren't any trick at all. I'd be interested in processing some of the longer vectors to see what differences can be had with the Rapid Orbits.

I'll have to ask my assistant, D. McPaulk, how he modeled some of the bluebox antennas in his processing software. Possibly the system administrator, Jim McFrame, may have some information on this as well.

Best regards,
Kent Millan, RPLS Austin TX

should be no problemo. For those of us using fixed position base stations all you'd need is the antenna vertical offset from ARP. The others from tripod stations (which I will supply possibly 2 myself) can be computed for you.

How many vectors are you up for processing?

I still think we can Co-op a system for L1 users if NGS can't help. We're fixin' to find out.

J.D.

J.D.:

Are you saying that the Locus receiver's antenna has zero phase center variation?

I would have thought that the phase center would vary by at least 1cm as the altitude angle of the satellite source varies. But it is entirely possible that I've been sleeping through developments in GPS antennas at the far end of the spectrum from the geodetic-grade choke ring antennas.

Best regards,
Kent McMillan, RPLS Phase Center TX

The PM2 calibration data can be found here; I didn't see anything pertaining to the Locus antenna.

As for getting the data into TGO, I made a half-hearted effort some months ago to do this on my own, but met with repeated failures and postponed the project. (Ashtech Solutions is so much more user-friendly that TGO hasn't seen much use around here lately.)

I've since learned that Trimble tech support will add a new antenna to the requisite file, but I haven't gotten around to requesting the PM2 addition.

Jim:

I'm still running GPSurvey 2.35, which has an antenna editor that can create phase center variation models.. Which antenna does the PM2 use?

Best regards,
Kent McMillan, RPLS Austin TX

ASH 110454 PROANTENNA L1

It's the one detailed at the bottom of the link I posted (below the table of antenna models).

Drop 2.35 and jump up to TGO...It is so much better (by a factor of 100)...I didn't think so at first, but after this experiment, then I can confirm it...I had trouble at first (but I've been using TM's software since TrimBP)

I used JD's offset for the ARP in my calculations...Can't remember what it was now, but it made the vertical much better (at least closer to the known position)...

How can we get NGS to model this antenna? Maybe just ask?....I think that they are following this experiment as well....

Jim listed ASH 110454 as the antenna.. Is this what JD has? Jim?

Reconverted a project (JD) and followed Mr. G's suggestions...Only moved post by a couple of mm's...Cant' prove if they are better or worse...I tend to agress with JD about the network function...If you have a good triangulation amongst the baselines, then you'll tend to get a good answer...

My summation is that 'Squishing is Good'... It tends to model the systematic errors in any system and we still have LS to catch the random errors...

I don't understand you when saying that LS can better model the random over the systematic...Systematic (with a well conditioned network) will tend to level out and be properly weighted...Random , we know will show up as outliers...


TM- Still having fun!

T.M.

Try 0.125m for vertical offset in the Locus Unit. This distance seems to work for the L1 antenna down to the ARP.

Jim was referring to the ProMark 2 antenna. That's next on the post as soon as we do a bit more vertical comparisons.

J.D.

p.s. Incidentally, I ran a 8+ hour session Thursday on the POST from 1000 to 1800 CDT. The SV configuration was pure crap most of the day, although space weather was very decent. I decided to download the CORS sites today nust to look at "common sv's" and attempt processing. The first 3 hours had enough to get a rough position, the remaining 5 hours had from zero to 3 common sv's for the mega vectors. Make a note.....need more satellites.....

TM:

Jim Frame has lent me his italics. When you wrote:

I don't understand you when saying that LS can better model the random over the systematic...Systematic (with a well conditioned network) will tend to level out and be properly weighted...Random , we know will show up as outliers...

Did you really mean to say that you actually think that the method of least squares is better suited to the adjustment of unmodelled systematic errors than random errors of known distribution (i.e. drawn from a normally distributed population having a particular standard error)?

If you did, then plainly you are mistaken. The idea that random errors will show up as outliers can only be described as sheer fantasy. Is any of this stuff evidence of the long term effects of listening to heavy metal? :)

Best regards,
Kent McMillan, RPLS Austin TX
Modified By Kent McMillan on 1/19/2002 at 11:40 PM

It's darn hard sometimes to put in words what the mind knows..Guess I slipped (I was thinking mostly of blunders) and glad you caught it (partially)..
Correct me if I'm wrong (and I know you will) but;

Random errors are generally small and compensating (positive and negative)..The LS package deals with this appropriately..

Systematic errors (rod that is 1.98 meters instead of the 2.0 that you put in the download) cannot be caught by the LS package (unless you mix a 2.00 rod with a 1.98 rod and then it should show up)...Another systematic error would be to orientate the antenna always south instead of north...Of course, never orientating them would create random errors....

You are very correct that random will NOT show up as outliers and I stand corrected on that point...

Again...I was really thinking about blunders showing up as outliers...(of course, they should really never get to the adjustment) Sorry for any confusion created by my first statement...

TM

PS- You should really look at upgrading to TGO...It kicks the heck out of 2.35..I didn't think so either at first, but I am believer now....

PSS- Was that more lucid and can I now change the CD to something more palatable?
Modified By Trimble Man on 1/20/2002 at 4:19 PM

TM:

Yes, that sounded a whole lot better. We'll have to discuss the merits of the TGO upgrade ... but probably not on this board. LOL !

Best regards,
Kent McMillan, RPLS Downbeat TX

eom
Modified By Kent McMillan on 1/20/2002 at 6:12 PM