Ok, we all know Phils' favorite phrase.

And I recently (I think it was last week) had a thought. Here goes...

I'm planning on running a couple L1L2 receivers in a remote location, too far from the "local" CORS for the accuracy I want to acheive with L1 only. Lets say I use 4 CORS sites to surround my remote sites.

First off, I'll set up the project in either AS or GNSS with data from the CORS I plan on using. I plan on observing my points from say 10am to 4pm local time, tomorrow.
Now, were I to download todays CORS data for the same reference frame as my planned observations on tomorrow, get the sites correct and process just the CORS to the CORS and make sure everything is just dandy and my data from my receivers is ready to just "drop in" the project after the sessions on tomorrow, of course I'll need the CORS data for that reference frame as well, then lets say the day after tomorrow I acquire the same reference frame of CORS data for that date and add it to the project. Process and adjust it all as normal.

I just flunked for a run on sentence.

Q1: Given I will be using fixed height poles, the redundancy gig won't save me with a busted antenna height. However, would the CORS to CORS data from the day before, day of and day after skew or enhance the overall solution as being repeat vectors?

Q2: scenario outlined, using the same time frame of my observations on the day before, day of and day after would use a similar constellation, and I should think any multipath/site problems of the individual CORS would be similar. Now, given that, would it be more advantageous to use a different time frame for the CORS data acquired for the day before and day after?

Thanks,
Dangerous Dave
Modified By Dave Huff on 10/16/2009 at 9:19 AM

1) take some of that setup time and instead set yourself on a traverse point or two and get some OPUS RS data..one day before, one day after, different times.

2) study the time series for movement on your local CORS to see if they are wandering.

3) use fixed height poles and check them anyway with a tape, ease your weary mind.

4) The only variable on a CORS "should" be space weather. If you have multipath noise they flubbed up the installation.

5) see #1 but this time don't forget your straw for the Bud Light.

CORs to CORS solutions the day before and after will do little if anything to improve your observations. 6 hours of OPUS should get all you need on the day observation. Get the extended output OPUS report and analyze it.

4 sites does not fit with OPUS solutions, Use 3, 6 or 9 or try OPUS-RS. You would have to break your 6 hour observations into at least 4 1.5 hour files.

In either Solutions your results are usually better if you exclude the CORS to CORS vectors. If you insist on doing it yourself, hold only 1 CORS fixed at a time and then mean out your site position, hold it fixed and check the tie variances to each CORS. In essence that is what OPUS-RS does when it lets all positions free in the LS adjsustment. That is one way to use 4 CORS.

If you only have 4 CORS you trust, submit to A, B & C and then to A, B & D. In extented output take your site position as calculated from A, B, C & D and mean them out. You can limit an OPUS-RS to 4 sites if you like.

On could possibly save a few minutes on observation day by taking 1 hour CORS files from any day, starting your project, setting all 4 as control sites per the published positions. You can then delete the 1 hours observations leaving your control sites siiting there for your field data. When you download field data you will not yet have the CORS data but the ontrol Sites will be sitting there on our map view just waiting.

Published site positions are meaned from more CORS to CORs vectors than you ever want to deal with, so don't try to invent a better wheel. Just get the wheels you have available turning in the right direction.

Paul in PA

Dave,

Do you plan on collecting enough data for static OPUS?

It is actually Leon LaDuke who gets credit for the phrase. He was from the great state of Louisiana as I recall. I hear his drawl as I ponder his words.

"There's three words that guarantee accuracy with any measurement, Son. Redundancy! Redundancy! Redundancy!"

When I first met him in Quang Tri Province in Vietnam in 1971 he had six years in country. He had lots of other words of wisdom for us.

"Don't tell me this survey is correct, Boys. Tell me that you are ready to bet your life on it!"

You can blame him for me being here today. Were it not for lessons learned my bones would be rotting on the side of a hill in western Quang Tri Province.

Did you look at my OPUS reports from San Luis Reservoir? I used a ZMax, ProMark500, and a ProFlex500 on the same point on different days.

There are three OPUS points and a NGS height modernization monument in the GNSS Solutions project we did. That project includes lots of redundant vectors measured with combinations of ZMax, ProMark3, ProMark500, and ProFlex500 receivers.

There is some RTK work using the new Magellan ULink radios and some ProMark3 RTK work with the little radios. We took ProMark3 RTK shots on a hiking trail. The next day Jeannine mapped the trail with a ProMark3 while I used a MobileMapper 6 to map the same trail.

All of the project files, photos, and some videos are on my new projects ftp site. See the comment section in my profile.


Did you hear Leon's words in the NGS webinars?

The stakeout reports for the ProMark500 and ProMark3 RTK work have been added to the projects ftp site. Look in the CarlsonSurvey folder.
Modified By Phil Stevenson on 10/16/2009 at 12:53 PM