Last night (this morning) I ran a Locus unit from 11:30 pm til 08:30 am on my "Base Post". I have done this before to process to the one nearest CORS station some 65 miles away. If I remember right I had less than 1 foot horizontal (and same vertical I think) relative to my base station established from 3 HARN stations surrounding me. I am planning to use 4 CORS stations this time and attempt to constrain to all 4. Next, I plan to do the same with a PM2 unit. I picked last night for the cold weather (damn, 30° is cold) and "quiet" geomagnetic field conditions.

Any thoughts on what to expect? The CORS data for the stations isn't available yet, but I plan to process 8 hours of data and "trim" from there when I get it downloaded.

J.D.

P.S. the other three CORS stations are all probably over 120 miles away.

Unbelievable.

One Locus unit cooked for about 9 hours on 01.325. Downloaded data from 4 CORS stations to process position. Stations are located as follows:
1 W/NW 132.79 Miles
2 S/W 65.90 Miles
3 N/NE 124.27 Miles
4 E/SE 124.48 Miles

There was 8 hours of simultaneous data frpm all receivers processed. The point to be positioned has been observed MANY times in the last year from 3 Airport PACS/HARN points, as well as 8-10 local points established from the same HARNS and checked to CORS by L1/L2 (Not by me). This point is my "Base Station Post" used for all my local area work.

All data was processed as geodetic Lat/Long and ellipsoid and converted to SPC83 (Texas NC Zone 4202) and Ortho.

All 4 CORS were held for a full constrained solution. QA settings for all vectors to pass were: Horizontal - 1 cm + 3ppm, Vertical 1 cm + 3 ppm. My Harn derived position was input for control tie analysis.

Here's the Miscolsure:

East -0.031
Nrth 0.087
Elev 0.075

Not too shabby, huh?

Next session (if solar conditions are good) will be the same scenario with a ProMark 2. I expect better results with 10 channel receiver. (lol)

J.D. Billings, In search of OPIE
Kilgore (Stumpwater), Texas

p.s. all vectors were partial solution

The results of Misclosure are in U.S. Survey Feet

Modified By J.D. Billings on 11/23/2001 at 2:03 PM

Out of curiosity. How did each of the four independent CORS results for position of the station differ from one another.

I am also curious to know what results you get with only one of the CORS held fixed. What variations on the position do you get when you pick on one CORS at a time.

I am really glad that I did not see your post until after your second post. I would not have expected such a wonderful match with what you have already done.

We both know that "You can't do that with L1 receivers!". ;-}

I am also surprised that they were just partial solutions. I never trust partial solutions. Just goes to show you should never say never.

How long will your ProMark2 run on those penlight batteries when the temperature is that cold?

Well, Mr. Geodesist, does what J.D. is doing justify letting the guys with L1 gear use OPUS too?

O.K., I finally got out of the kitchen from canning the last of the rocket fuel hot sauce (peppers this time, not ale) to get me through the winter. When processing the individual CORS stations this morning I didn't do any printouts, so I just re-ran each CORS site individually to solve for my "post". I'll just list them with the control tie analysis "misclosure estimates".

For geography's sake, I'm in Kilgore, Texas (NE TX), station #1 from above post is in Arlington, TX (ARL5), station #2 is in Palestine, TX (PATT), station #3 is in DeQueen Arkansas (DQUA), and station #4 is in Winfield, LA (WNFL). All data was processed with 18 to 25 degree mask to get the lowest residuals. WNFL was a bit tricky. From viewing the raw data files there seemed to be loss of lock quite a few times on sv's in the 10-25° range. My guess is this station is not in an ideal location. All I tweaked was the mask angle for each individual vector, no time trims and no sv exclusions.

Individual results of misclosure estimates are as follows:

ARL5 to POST E 0.918, N 0.131, El 0.615

PATT to POST E 0.151, N 0.305, El 0.526

DQUA to POST E -0.051, N -0.518, El -0.549

WNFL to POST E -0.816, N 0.096, El -0.391


Phil,

Not too cold now. We're expecting temps in the 40-70° range for the next few days. I'm not going to run another all nighter though until solar conditions settle. I don't trust what happens to my sessions for at least 3-4 days after a coronal mass ejection. I want the fairest conditions possible. As for the partial solutions, my guess is the limited number of simultaneously observed sv's. Looking at the residual charts on the vectors in the 120+ mile range, most of the data was 3-4 sv's. I was looking at the residuals more than anything else while processing. Normal residuals on the vector lengths were for the most part around 1.5. The WNFL vector insisted on being above 2 no matter what though. Like I said, I didn't try to trim time and am not sure if it would really make an improvement considering the sv configuration.

J.D.




p.s. I'm really impressed with how Ashtech Solutions handles the Rinex file conversion. The whole thing was painless.

Modified By J.D. Billings on 11/24/2001 at 1:35 AM

It appears that the first solution (networked) hit very close more to compensating error of closure than to a good baseline solution...

The results showing each baseline appeared to be much more error than I've ever seen on long L1 baselines..
JD mentioned that some baselines only had 3-4 SV's, which is probably why the high variance in position...
I've done several tests much like this and had better results using;
12 Degree mask (get more SV's) and edit out select noisy SV's and cut time where necessary.

On these long baselines, my results have been better having more SV's rather than more time. With a high mask, you'll almost going to insure that you will not have many common SV's in the solution.....

Trying lowering the mask and reprocess. Cut SV's that are noisy and edit the timeline to suit...I'd bet the results get much better. I'd expect them to not exceed 2-3 tenths at most...

JD- When you say partial solution, do you mean non-fixed (float's) or something Ashtech specific?

Reckon the manufactures will send you a check for R&D?

TM

I would bet that you would get the same results using only an hour of data. You could try and cut up the data giving you multiple sessions (separate baselines) and see where this leads.... Maybe take the first and last hour of each session, giving you two redundant vectors on each baseline...

Another note- I've found that on the long baselines, it's critical to have good data on the front end of the session, so I always look for noise at the start when editing a session. Guess when it comp's a bad fix, the processor can never completely recover..

ARL5 looks like it picked the wrong integer when complete..and I'd bet the same thing happened with WNFL...
The other two are well within my experience of long baseline results...

Also got to thinking (also dangerous for me)...I would have thought the network would have 'blown' up with the amount of variance in the first set of solutions you provided......Wasn't your apriori way outa whack? I would also think that it would show up in the histogram and on the error ellipses...

Still cool to try and break the rules...

TM

I ran adjustment again, this time excluding vectors between CORS stations, holding only those 4 vectors from CORS stations to "Base Post". Didn't make much change in the misclosure: E -0.044, N 0.080, El 0.074

I've tried trimming time here and there but it seems to need the full 8 hours to get these results. I'd be glad to send the file to someone with much more ability than I have, if they'd like to play with it.

J.D.

I'd like to see what TGO can do with it...I'll also post results (they should be the nearly the same, excepting any edits of the raw data)..

TM
I have pkzip, ect, so however you want to bundle them up...

.....did you get them?


J.D.

You say you think the solution is due to compensating errors? Since the data was all simultaneous on all stations, and processed together, wouldn't it be reasonable to assume the least squares adjustment was made properly by a damn good processing engine? I have a hard time considering the use of the word "closure" when comparing vectors derived in a simultaneous session. Seems to me the data would be weighted differently than if it were from different sessions.
Also, consider the direction and magnitude of the positional errors. Notice the station to the East (WNFL) and the station to the West (ARL5) had the greatest error in Eastings? Wouldn't that be expected considering satellite trajectory? And the station to the South (PATT) and station to the North (DQUA) has the greater errors in Northings. Isn't that fairly normal anyway?
As for setting a low mask angle, I didn't think it proper using L1 only, especially considering the range I was dealing with. As a matter of fact, several of the vectors were "float" until they were masked at 18-20°.

Hey, I'm just grabbing at straws here. I laughingly told Shawn I was expecting no more than 3 cm horizontal and vertical. Go figure. Until I understand the ramifications of "partial solutions" though, I won't be doing any single point control positioning. Have to study the software more first.

J.D.

stay with me here and maybe we can re-invent this wheel too. (lol)

I was referring to what the position would have been had you only used one of the baselines..versus the total outcome..

Error misclosure is tough to compare when you have several hundred miles of baselines, since it sorta gives a warped picture of actual error in the measurements... In years past, I'd have been very happy to get within a foot after measuring several hundred miles (and wearing out several chains in the process)....

I'll have to think about the errors in easting and northing...I've never noticed a predominate direction based on SV geometry..

You mention that several vectors were float until you raised the mask. Does this mean that you got 'fixed' solutions on all the lines?..

I usually use 15 degrees as my starting point, but have never had any luck getting into the 20 degree range, even with short lines...This is probably regional more than anything..

I'm sure the files are there, but my e-mail is at the office and my better half has ordained today to be Christmas tree and house lights day, so she plans on keeping me up the ladder, as it were..

TM

We're not re-inventing the wheel, just changing the rim size...I remember the first car that broke the 10 second quarter mile..Physics said it would be impossible..So never say never...
Modified By Trimble Man on 11/25/2001 at 8:13 AM

I guess I'm just having trouble grasping the concept of compensating errors in the context of this type solution. Seems to me that all vectors used in the simultaneous solution are necessary to the solution, thus not considering error sources in individual vectors.

J.D.

Whew, I had to put the reading glasses on over the coke bottle bottoms to make sure you weren't saying you remembered "the first wheel".

Hi,

Just like to say that I am finding this fascinating stuff...I too am interested in this long-baseline-to-CORS processing issue. I have done a number of similar tests, unfortunately though I am situated right on top of one reference station, making me a long way from any others...having seen the baseline lengths you are observing however, I see now that this needn't necessarily be a problem!

I am having a little trouble with the units though..(I am afraid we Brits gave up the foot and the mile a little while ago :-) )...am I right in thinking that the post-adjustment elevation misclosure was 0.075 of a foot, ie about 23mm? If so, I am stunned...and would be fascinated to see if you can replicate this. I will also be very interested in any results you may have for similar tests done woth Promark 2's.

Keep up the interesting posts....

A "partial" solution is still a fixed solution, it just indicates that the processor did not fix ALL of the biases. There's no reason to consider these unreliable as long as other QA indicators are OK.

I left the angle mask at 13 degrees for all solutions and editing SV's out or edited partial data from the sets...

Each of these pairs below is holding only the fixed station mentioned...I'll post the fully constrained results tomorrow night...

From ARL5 to JD (named the point after you)
6835851.532
3100684.665
403.624
317.453

From Dqua to JD
6835851.589
3100684.665
403.623
317.452

From WNFL to JD
6835851.343
3100685.179
403.620
317.449

From Patt to JD
6835851.421
3100685.069
403.616
317.445

As a side note, all the dual frequency lines past and were fixed iono free solutions...
The error of closure on Arl-Dqa-Patt was horiz 0.019, Vert 0.068 and the PPM was 0.112...

JD...This was the worst data set I've ever seen..Your data was very smooth, but both Pratt and WNG had more cycle slips than I've ever seen...Wonder what's up at those two CORS (Continually Operating Reference Slips!)...


We'll...How did I do? Great way to spend an evening, and I will spend some more time with these data sets...Good stuff to experiment with...

TM- In the Zone

and PS- Everything is reported in FEET, not meters....

Deral,

Your numbers so far are along the right lines. Our numbers differ by as much as much as a foot, one way or another. I'm not sure if you noticed last night (I responded to Kent on the main board) that I added Houston (HOUS) to the mix. It changed my final adjustment a hundreth or so, but nothing sunstantial. I did find that if I left PATT out of the solution (after adding HOUS), my vertical position moved away from the expected results. Leaving PATT in, maybe since it is the closest station, may be necessary for modeling. That, I'm not sure of.

You mentioned the dual frequency lines as fixed iono free solutions. Remember, I'm processing L1 only and my version of Ashtech Solutions can not process L2. That's what is really making this interesting to me.

Glad you noticed how clean Ashtech Locus data is. Notice how the carrier phase data looks line a fine toothed saw? Notice how the carrier phase data from the CORS stations looks like a buck-toothed jack-o-lantern? Sorry, got carried away with never ending East Texas analogies.

Nice of you to put the data in SPC83 Zone 4202 and using USSF. Makes it easier to compare numbers. From looking at your data, I assume you're taking advantage of the L2 stuff. At least as far as your verticals relate to one another.

Also, I guess you did get the message that station POST (JD) is ARP defined, and the Locus unit .125m vertical.

I look forward to your adjustment results. It'll be fun to compare those numbers.

J.D., Stumpwater R&D, OPIE Division



Modified By J.D. Billings on 11/27/2001 at 2:00 AM

I saw the HOUS and actually did download the RINEX for it also..Just didn't use it, since it took over 6 hours to edit the other data...Boy, the CORS were a serious mess..

I only used the dual between the CORS to validate their positions and to give me some quality assurance of the 'fit' for Point JD...Most of the L1 lines weren't all that good (surely because of the length), but the four coordinates for JD came pretty close to one another, so usually this means that I'm very close..

TM

I'll play a little more tonight..Expecting snow and sleet from what the weatherman said...Bah Humbug!

PS- I ignored the rod heights and just concentrated on the horizontal..So this will be off whatever the difference is..I used 0.00 for all antenna heights and choose true vertical as the measurement..
Modified By Trimble Man on 11/27/2001 at 7:15 AM

..and a nasty looking forcast at that. I am afraid that you and your fellow Okies have let us down. Someone failed to repair the strand of barbed wire on the Oklahoma and Kansas boundary and allowed our Northern friends to forward us their leftovers. I suppose they're managing their resources of nasty weather, not unlike the annual lake draw-down prior to the rainy season.

When I first posted some of my results, you had me worried when you said they were considerably out of range of what you would normally see. But, your processed individual vectors seem to have near the same magnitude of difference relative to the "target" position as mine, although some in different direction.

So, you are reporting the L1 height of my POST? The ARP would me 0.125m below the L1 antenna if that is the case. I am interested in how closely your verticals managed to fall within such a tight range of less than 0.01 USSF.

I really need some training in the use of AS2.5 software to better analyze the data. A hard copy manual with more detailed explanations of data analysis would be very handy for starters.

I look forward to your next response.

J.D., OPIE-1-CANOPIE, Stumpwater R&D

Not to draw any conclusions, but all of the CORS sites you're having problems with use yellow boxes (4000 series). ;>()
Modified By Brian Ewing, PLS on 11/27/2001 at 2:05 PM

This was the best site (for clean data) of them all...What brand is at this site?

TM

HOUS is also a yellowbox 4000.

BTW, CORS is 45.90% Trimble, 42.21% Ashtech and 11.89% Leica.
Modified By Brian Ewing, PLS on 11/27/2001 at 3:19 PM

Holding HOUS only to point JD...

6835851.436
3100685.304
403.609
317.439

Fixing all CORS and loading Geoid Model (which showed alot of vertical error in the solutions)

6835851.541
3100684.934
403.805
317.633

Okay JD...What's the coordinate that has been previously established on this point?

PS- I didn't have any vertical control in the network at all, so the elevation is purely based on the geoid model..

After all this editing and processing, I wouldn't be comfortable with any of the results for control work (ie, establishing a geodetic coordinate on point JD)...I would be okay using it for local work and as a tie to the NSRS, as long as the metadata was supplied so other users would know that this was a weak solution...

I'm going to experiment using some of the other lines (the shortest) and only L1's to see what can be done...and how good this might achieve...

BTW- I did look at the error ellipses between the CORS and they looked fine (but this was using L1/L2 data)..

Snowed in today, so I'm going in to work late and staying late......

TM-Ain't we got fun

My base station "POST" was originally determined from several City control points (City of Kilgore, Tx) that were established by Joey Stanger of Tyler, Tx. Over the course of several months, we continued to refine station POST by ties to another network in a nearby city (White Oak, Tx) and to local area airport HARN (PAC) points. No matter what was tied to (with exception of vertical at Henderson, Tx SAC point), all ties were well within spec of L1 equipment. We have "squished" this point around so many times within 3 cm horizontal and vertical that we decided to just pick one to call good. We have also tied in points observed by others and still hit within "spec". Station "POST" iteslf is a 2-1/2" iron pipe buried 3-1/2 feet in very stable soil with 3 bags of sackrete. The POST extends 5-1/2 feet above ground with a 5/8x11 thread on top. We've found the best mask angle for station POST is 20° due to surrounding obstructions. Position for POST is the ARP.

Here's my coordinates. State Plane 1983, Texas North Central Zone 4202, elevation is Orthometric, Values in U.S. Survey Feet.

Harn Derived:

N 6835851.505
E 3100685.732
Elev (ARP) 402.979 (Elev L1 Antenna 403.389)

CORS Derived:

N 6835851.420
E 3100685.734
Elev (ARP) 402.907 (Elev L1 Antenna 403.317)

For the CORS observation I held the verticals from the data sheets for the ellipsiod height for L1 phase center data "NAD 83 Position (Epoch 1997)". No other vertical information was added. Geoid 99 was used to obtain ortho elevation.

So, how'd I do?

J.D.

There are several differences in the way we processed and adjusted and the way that you did. I am like you, I wouldn't suspect the different softwares to be the source of very much difference and have dismissed this temprorarily as a culprit.

One possibility is that you washed the data too much. You obviously know what you are doing and so we have temporarily dismissed this as well.

The other possibility is the inclusion of the L2 data from station to station. This could be messing up the adjustment because of the difference in accuracy (or error estimates) between the L1 and L1/L2 baselines.

I don't know how long it might take you to try this, but is it possible for you to turn off the L2 between CORS stations and process/adjust using only L1. We think this might allow the adjustment software to come up with a better adjustment based on the error estimates it comes up with between the constrained points. If you are up to it, please give it a shot.

Shawn Billings

P.S. Thanks a lot for the "ain't we got fun" blurb. Now I have that song stuck in my head.

Is there anyway that you can beg/borrow/steal an L1/L2 receiver and get an OPUS fix on this point? If you can, then get 4 hours if possible...You mentioned that is was HARN derived (Is this an actual HARN point?)

The obstruction at POST didn't appear to cause any suspect troubles..I did fix several cycle slips in the POST data, but it wasn't all that much.

I didn't really edit out to many fragments, but I did kill several noisy SV's that appeared noisy in both files...

The L2 data from station to station was only used in the final fully constrained process, not in the individual solutions...I turned off all the lines when getting the single solutions...Plus since these are outside lines (and they fit together well), then it wouldn't make any difference in the shifting of the points..

Looks like my northing matches pretty well, but the easting is consistently missing by a half foot and better....with the ellipsoid about the same...

Have we learned anything yet? Guess I'd surmise that IT'S darn tough to do L1 only long baselines....The error ellipses to POST were at the several tenth level (which to me, means the software is trying to tell us that there is some pretty big uncertainty in the point)..

TM- Ain't we got fun (just for Shawn)...

Shawn...I'm also very curious why the big difference in the final solution, but I've never attempted to do this long of baselines with L1...

My thoughts would be its in the software. The reason being I doubt if AS and Trimble use the exact same algoritihms and coded equations to produce the results.

At NORMAL L1 distances the differences in the two methods are virtually nonexistent. With L1 STETCHED to extremes, as in this case, the differences in the algorithims appear.

The question is do the error ellipses overlap ? If they do wouldn't the most likely position be in the overlapped area ??

???????

Jimbo
Modified By James Webb on 11/28/2001 at 12:38 PM

Jimbo,

I believe you see what our thinking is here regarding the L1 only.

"The question is do the error ellipses overlap ? If they do wouldn't the most likely position be in the overlapped area ??"

That's the reason I had Shawn mention the L1 only processing. I'm merely guessing at the math here, but I could imagine that using L1 only, for all vectors regardless of whether L2 is available, would force the software to analyze and weight all data uncertainties accordingly ...using nothing but the "low octane" data to create the least square solutions. I'm just guessing though.

Trimbo,


Like I said, POST is my base station derived, or should I say determined, by me from observations on various local control points and from 2 Primary Airport Control Stations and 1 Secondary Airport Control Station. This is the reason for my use of the phrase "HARN derived". Was that a misleading statement? I apologize for any confusion there, it certainly wasn't intended as I thought I was clear in describing the origination of station POST (my personal base station point).

Have we learned anything yet? Let me run this little experiment 2 more times and compare results and I'll answer that. I find the comparison of my original coordinates to my CORS coordinates rather amazing. Just speaking of final adjusted coordinates anyway.

As for doing a dual frequency session for OPUS solution, that's been on my list for a year now. If for no other reason just to have a bit tighter control on "POST". I'll pursue that with a bit more vigor.

Along the lines of the OPUS discussion, how would the results vary between say an "in-house" solution using the same 5 CORS stations used in my L1 experiment and the results from OPUS? I am very curious about that.

J.D.

p.s. Deral, you can keep that nasty white stuff on your side of the Red. Not that bad here...yet. They're now saying our liquid stuff (and plenty of it right now) could start to "set up" in the morning. I'd doubt that Jimbo would want us to send any resiude from your package his way either.

So right you are. yesterday it went down to 64°. Right now it's 75°.

We already had winter about a week ago. It went into the thirties. The long sleeves came out for that day. But now since they are put away again, ya'll will just hafta keep that cool mass of air, sent from the Canadian Suburbs, away from us.

Thanks,

Jimbo

PS: I'm not sure about the L1 vs L1/L2 stuff. Just logically it seems that if a point is given coordinates, and then you are given an error ellipse. Then another program calculates the same point,different coordinates, and its ellipse is whatever by whatever, and those two ellipses overlap, then wouldn't the probability be that the point's true coordinates are in the overlapping area, both numbers are correct within the tolerance of the error calculated.

And possibly the L1/L2 solution would provide a smaller error area intersecting with the possibly larger L1 error area.

Jimbo

PPS: Somebody that can add 1+1 better jump in cuz the math is getting way over my head !!

43?????

Here's a thought for long L1 vector processing experiments. Why not use all CORS data with L2 disabled? That is, solve the position of a CORS point in relation to the nearest others and then compare the position to the essentially exact published value.

By using older data, the curious could pick and choose quiet iono days and use precise orbits. Naturally, ITRF coordinates would be available on all points also.

Best regards,
Kent McMillan, RPLS Austin TX

O.K.

I just brought up my file and did a bit of re-processing. Held ARL5 and DQUA fixed. Solved for PATT and WNFL. Data was originally entered from data sheets for L1 phase center, NAD83 Position (Epoch 1997.0) Transformed from ITRF97 (epoch 1997.0) position in July 2000. I used Lat, Lon and ellipsoid height. Is that the data you consider proper?

Anyway, doing nothing but tweaking the mask angles and processing the entire 8 hours of data, I get the following misclosures:

PATT Lat 0.015m Lon -0.078m El -0.091m

WNFL Lat 0.021m Lon -0.043m El -0.235m

Makes me wonder why my first attempt to my Base POST resulted in maximum 3 cm difference an any direction. What can I deduce from this if I find the same quality results on three different nights? And why did you suggest solving the position of a CORS station anyway. What, winter ain't enough for ya. You gotta make things more difficult. I'm goin out in the rain and screwing a Locus on the POST...can't sleep now anyway....

J.D.

"screwing a Locus on the POST"....Now I bet that's something that Bill Martin never envisioned seeing on this forum when he started it up......b

Just don't bring it to Bill M's attention. I just went out and "un-screwed" it from the post. It downloaded fine so I suppose I didn't lose the respect of the receiver in the morning. (lol)

J.D.

You guys are beginning to scare me.

I hope you will not be expecting any compensation for therapy sessions.

"Hello, my name is Bill Martin, and I am a GPSaholic"

Welcome to the club.

Bill

Was any Stumpwater Brew ingested prior to this deed?

TM

What does this do to the warranty?

ROFLMAO

.

You went there.


Trying to have a serious discussion on...what was it again? And you had to bring up livestock. I don't know about sheep and regional demographics, but one does have to be handy at times no matter where you are from.

Shawn

J.D.:

For the best results with L1 data, I'd think that you'd want to use the ITRF97 positions for the "known" CORS points and compare the ITRF97 position of the CORS to be solved to the published values. Using ITRF coordinates gives a slight improvement that is inconsequential for ordinary land survey vector lengths (<20km) but significant for CORS-to-CORS distances. Likewise the precise ephemerides, if the Ashtech software will accomodate them.

The point of both refinements is trying to eliminate small systematic errors so that what remains represents the errors due mainly to using only L1 data.

The reason I suggested using CORS data is that a person has got a whole historical archive of data available, with precise orbits (if their software can use them), and "real" control coordinates for absolute comparison of results.

It would be particularly interesting to find the scatter of a significant number of nights' data (>10, for sure) to get a measure of precision.

Likewise, a person could do the same for a significant number of nights during periods of unsettled ionosphere to see how much L1 nighttime observations are degraded by those conditions.

Best regards,
Kent McMillan, RPLS Austin TX

JD, I'll have to agree about downloading. Getting INTO the Locus was always the hard part for me...As for me, I gave up chasing when I opened my new Red Ball knee-high's and found two, thats right, two Locus in there last Christmas...Now, for the good news...You know that Z-Surveyors have an easier interface, more capability, and are way more sexy looking than a Locus....And even better, Z-xtremes have a longer lasting battery and an ENTER button....hope this thread dies soon, cause I'm just getting started...
Modified By Robert Bills on 11/29/2001 at 7:38 PM

Kent,

So you are suggesting I try it again with the ITRF97 Position for the CORS stations? Sounds reasonable, and no really big problem. If I do this, after adjustment can I easily convert the ITRF97 position to NAD83. Please explain. I will reprocess and try it.

Thanks


Robert,

You'll soon get your wish, "hope this thread dies soon", as OPIE experiment No. 1 will soon be superceeded by OPIE experiment No. 2. The next 9 hours of Locus data from 2001.333 0700 UTC-1600 UTC is already safely downloaded to a new file in Ashtech Solutions patiently awaiting the corresponding time segments from the friendly CORS stations. I feel a sequel in the makin'.

J.D.

My eye surgery has finally been scheduled for this coming Monday. I sure hope I won't be in a position on Tuesday of requesting a braille version of Ashtech Solutions. At this stage I'm not worried about me, I just wish the surgeon luck.

J.D.

Laser? Mom just had it for a cataract and wished she had done it 5 years ago...
Now she can tell if the garage door is up or down before she pulls into the garage...

TM

Hate to see ya surveying with a seeing eye Shawn...Heard their hard to train and keep leaving spots on the carpet...



PS- Shoot the data to me again if you want...Don't have any big plans this weekend and I'd like to take another shot at it!

Your friend from the Experimental NGS Oklahoma Branch
Modified By Trimble Man on 11/29/2001 at 8:26 PM

J.D.:

Isn't the question what sort of positioning accuracy could be accomplished with an L1 version of OPUS?

What the present version of OPUS does is to compute the ITRF vectors using the ITRF positions of the CORS points and then transform them into the NAD83 reference frame by applying the rotations about the three axes that relate the two frames.

Depending upon how your processing software works, you have various options for obtaining the NAD83 position of a point positioned in ITRF in relation to CORS points. For the purposes of your experiment, though, I'd think that the actual NAD83 position of the "unknown" CORS antenna is immaterial since the ITRF position is published.

What interests me are:

(1) what are the residuals from the independent vectors?,

(2) what is the repeatibility of the position from night to night?, and

(3) what is the best way to estimate uncertainty from just one night's work?

By the way, I'd be interested to process any of your data in RINEX format to know whether the Texas version of the Trimble vector processor in GPSurvey gives the same results as that sold by them in the region-that-shall-remain-nameless above the Red River.

If several of us are to work upon the problem, probably what is needed is to choose a particular set of CORS points for the test.

Best regards,
Kent McMillan, RPLS Austin TX

Let's go over my game plan again. I'm using the 4-5 CORS stations in an attempt to position an "unknown" point. My base station point in my yard, affectionately called "the POST". This is the point being solved for. How do I get this point from ITRF to NAD 83 once I've used ITRF coordinates to process and adjust?
I'd be glad to send you the data from the first observation as well as the 01.333 observation session if you would like to tinker with it.

Thanks

J.D.

I'd be interested in running the files also. I also wonder if the computer hardware can make a difference ???

I can zip and unzip from e-mails or
you can post them directly thru FTP to

ftp://pob
Put that in your address line of the web browser, at least in IE, and then just copy and paste.

Jimbo

J.D.:

I think that the conversion of the ITRF position of your station POST to NAD83 really depends as a practical matter upon how your software is configured. Otherwise the number crunching can be a problem.

The way that I would do it would be to:

(1) process the CORS-to-POST vectors using the ITRF positions of the CORS points.

(2) adjust the various vectors to find the ITRF position of POST, and use those residuals in estimating the precision of the positioning, then

(3) because I use Star*Net-GPS, I'd readjust the ITRF vectors in Star*Net-GPS letting the software find the transformation parameters (scale and rotations about the N,E, and Up axes) to be applied to all of the vectors to give a best fit (in least squares sense) solution for the NAD83 position of POST.

A cleaner solution would be to just rotate the ITRF vectors into NAD83 and then adjust them with the NAD83 positions of the CORS points. I don't do that myself because I don't want to do it longhand and don't have a software aid to do it.

The problem is that if you don't transform the vectors out of the ITRF reference frame, the fact that ITRF is slightly rotated with respect to NAD83 introduces residuals in your solution for POST that would look like instrumental errors but which are not. In other words, the ITRF vectors have small "index" errors that are systematic in effect if the vectors are treated as if they are in NAD83 without making the transformation.

Best regards and good luck with the laser surgery,
Kent McMillan, RPLS Austin TX

Thanks for the info on ITRF conversion. I played a bit with the HTDP conversion program by inputting the ITRF97 position of one of the CORS sites and attempted to process it to the NAD83 position. Not knowing the exact dates (or epochs) to tell the software I just used the month and 15th and year from the published data sheet. Actually converted to positions within 2 or 3 cm by running that way. I remember you having this discussion concerning ITRF with Mr. G (or was it Dave D...or both) a few weeks/months ago. I can understand the concept of the shift due to plate techtonics, etc., and see the potential for shifts. But, would this not affect dual frequency positioning as well, considering an attempt to adjust to all 5 CORS sites. Does OPUS take these shifts into consideration when doing adjustments? I don't remember the format OPUS uses, whether they process to the nearest 2, or 3 CORS sites.

I know you're correct when you suggest the ITRF rotation can cause systematic errors. I would like to find a way to reduce those errors, and hope the Central Texas OPIE R&D Division will be able to devise a plan.

Thanks

J.D., Stumpwater OPIE R&D

J.D.:

The way that I have understood NGS to have described OPUS as working is that it uses the best ITRFxx coordinates for the CORS points (time-dependent predictions) and processes the vectors using those coordinates.

Then, when it is time to derive the NAD83 position of the point sought, the ITRFxx vectors (the ECEF coordinate differences) are all transformed into NAD83 vectors by applying the small rotations about the three axes to them that define the relation between NAD83 and ITRFxx. The NAD83 vectors are then added to the NAD83 coordinates of the CORS points to get independent derivations of the position of the point sought.

The scatter of the different positions that would be independently calculated from the several CORS vectors is used in OPUS to calculate the uncertainty of the final adjusted coordinates for the unknown point.

Best regards,
Kent McMillan, RPLS Austin TX

Kent,

With all that in mind, do "normal" users of the CORS network routinely consider these adjustments? Heck, for that matter, do "normal" users of the CORS network consider ties to multiple CORS stations? I know the major concern here is distance related (concerning shift), but wouldn't the same problems affect my work if I were using any receiver, L1 only or L1/L2 regarding the shift? Is there sufficient software, like HTDP, available on the NGS website to piece this together?

Sorry for all the questions (I'm really not sorry), just trying to justify my computed coordinates (and apparant successful repeat).

J.D.
An Abnormal (or Paranormal) CORS user
Stumpwater R&D

J.D.,

I'm no longer a "normal" CORS user, but frequently use OPUS and CORS data to reinforce a survey. I do have the luxury of using L1/L2 receivers whenever I like, but do some work with L1 only. The only significant difference is the dual-frequency equipment allowing an iono-free solution (and shorter observation times).

Best Regards,
Brian

J.D.:

I rotate my vectors to transform them into NAD83. It doesn't make a very big difference, but is noticeable over distances of 40 miles and more.

If NGS were to offer an L1 version of OPUS, all of the finicky stuff (ITRF coordinates, transformation of vectors into NAD83, et cet.) would be done automatically. No additional labor would be required. The only reason why I suggested making those refinements in your tests was so that the actual accuracy of the final positioning wouldn't be degraded by correctable systematic errors.

Best regards,
Kent McMillan, RPLS Austin TX

I really appreciate your suggestions. I'll have to take the time to understand the rotation factors to get from ITRF to NAD83. I have no doubts about your procedures. You obviously have a very good understanding of the details. I hope that with a few years experience in gps theory and practice (at least more than my current 15 months) I'll have a better handle on it all.

Right now, I believe that doing L1 observations (lengthy observations) within the confines of the geometric figure created by several CORS stations, using the NAD83 coordinates of the CORS stations, will result in very good quality NAD83 coordinates of the new station. My second test would seem to qualify this statement at this time. A third test, under the same conditions and constraints, is in the plans. Also, a dual frequency position, hopefully both CORS and OPUS derived, is planned for later this month. That should give me "target coordinates" for my "POST". That way we can compare the L1 CORS derived positions to something of maybe a bit higher integrity, at least as far as the CORS network. At the moment, my base coordinates used for comparison were derived by our own L1 obs. to various local area control tied to HARN. Probably some difference between local HARN and CORS anyway.

I am really interested in information on making the proper ITRF to NAD 83 rotations, but not sure if it would be all hand comps. I think you may have indicated that it was. Seriuosly, I'm not arguing any of your points (just arguing with myself, and unfortunately have begun to catch myself arguing back), just trying to figure how to apply the proper adjustments.

J.D., the Rookie formerly known as Stumpwater R&D

J.D.:

I don't consider calculating the vector transformations from ITRF to NAD83 to be easy hand calculations. As a matter of practicality, I think that one really needs software to do them. There are other really important things to save the mental energy for.

Best regards,
Kent McMillan, RPLS Austin TX

takin' it to the streets

Doowacky doo doowacky hey hey

The Richmeister, making the copies...

Gonna take back that spot on the archives. sooner or later!

SUCCESS!

BUMP

Just covering my 6.

One more time will do it.

This is a great read. I hope many more will come from it.