CORS Question

If you want to "prove" the points are correct each control point should be occupied at least twice. Including the base point. I don't know the limitations of the PM3's, but I might try to do a rotation of some kind. It makes it tough with just 2 units. If there were anyway to add a unit or more to the process it would speed things up.

Having a Cors site within 23 miles is great. If you want OPUS you will want one unit to sit for at least 4 hours. If you process it yourself that won't be necessary.

I wouldn't leave one unit on one point all day and process it. I realize that you get better OPUS results with a longer set-up, but what you really want is good results between the control points and "proof" that those results are good. There is just no way to be sure that the unit was over the point, or that the HI was measured correctly without doing them twice. If nothing else I would at least "break" the base setup and collect two sessions. And you also can't use it tie the short legs with the other receiver if it sits in one spot all day.

I would think that if you split that one long session into two using different receivers you would then have a stronger network to adjust, otherwise you are hinging everything against one solution, that would also depend on how long you are there. I think L1 would give sufficient results with two four hour sessions, but I am not an expert at L1 only.

I am with mighty moe on this. I would try to use more than two at a time. I always like to leave two units on the same points and move the third unit. Doing this, most points get "burned" twice, if not more. On the last session, I havethem break set-up and burned one more time so that all the points are covered twice. This usually creates a very good network.

I know I really have not anwsered any of your guestions, but this is a plan for a control network with 4 untis.

I really just wanted to show off my hatching skills...

Jimmy,

If you are using GNSS Solutions to process your data, you could use the VRS Data Processing tool. This is like a OPUS solution processed in the GNSS Solutions software. It would allow you to compute a position for comparison purposes and provide residuals.

Brett

Thanks for all the replies.

Unfortunately, the crew is down there with only the two receivers. We occupied the fur maim control points yesterday with shorter sessions, but when i tried to process the data, I could tell right away that the sessions needed to be longer. The crew is used to having the Hipers there, and doing shorter sessions because we usually use the OPUS results for the seed coordinates. (We rarely do very big sites.)

The baselines between the receivers on site would solve, but not the longer baselines from the CORS sites would not process due to the short observations.

The PM3 units are L1 only. Unfortunately, we can't use OPUS on this job.

I am running GNSS Solutions 3.60.1 . Is that VRS Option in that version? I only have the L1 version, available for free download from their FTP site.

Thanks,
Jimmy

You will find that the limit of the PM3s as they are considered short range units and extend to less than 10mi from a control point such as a CORS station. I try not to exceed 5mi for consistent mm results.

When I began using them and still, the nearest CORS stations are 40+ miles away. They get me in the ball park. About 2± meters using one on points that were run 5yrs ago.

I have not checked in the last few years since the firmware has been improved and the results may be better now against OPUS.

This I know because last summer it was checked and run thru OPUS by someone I contracted that had a Trimble unit and he ran a couple of 2hr sessions on different stations I had set around the county.

I would recommend downloading data for several CORS stations and not rely upon data from just one station. That will give you more info when you run thru GNSS and you should get very tight results.

The software that OPUS offers uses systematic choices to optimize your data for best results.

Yes, the VRS feature would be available in version 3.60.1. There is a new version available, 3.70.5 as well if you want to download. I recently downloaded it using FileZilla and the download took less than 5 minutes.

For more information on the VRS feature refer to Chapter 14 on page 231 in the reference manual. You can download the reference manual here: ftp://ftp.ashtech.com/Land%20Survey/GNSS%20Solutions/manuals/GNSSSolutions_RM_D_en.pdf

I hope this helps.

Brett

I am looking at the "Compute VRS" function in GNSS Solutions. I had never played with it until the other day. It looks like it may give some functionality useful in a situation like this.

I also discovered in working with it that Ashtech "broke" it in the current released version, 3.70.5 so I just re-installed the previous 3.60.1 version and it works great in there from what I can tell.

I don't know much about it yet but it downloads CORS data from the sites you choose around your project area and computes a VRS point near your site to process against.

Don't Use VRS in GNSS Solutions 3.70.5

Mark Silver posted on another surveyor site 2 days ago that VRS is broken in the latest version, use the older one.

https://rpls.com/groups/forums/viewtopic/2/94/1277121?post_id=2748010#p2748010

I would use VRS for the first days short observations, then check it against the second days longer observations without VRS from 3 CORS. However like OPUS-RS it is better to be surrounded by your CORS than have them all to one side.

I learned early on (less that 1 month with only 2 PM2s) that 3 L1 receivers were required to get confidence in long distance observations from CORS to an L1 network. As a minimum 3 static network points for 2 hours is the starting point. Work as many points as you can and finish off the day 1 hour static on the first 3 points, 2 hours if you are anal. Given that you should be able to match VRS. Be cautious in the jumping around phase, you don't want to waste too much time accumulating vectors with too short a duration. Good communication between multiple crew members.

Paul in PA

Thanks again for the replies.

I tried the VRS processing option, and it really tightened up the points we had. We were trying to use pairs of points to use a stype of small route survey for a long, narrow access road.

The post processing results from the VRS matched pretty good with processing from the CORS site that was 23 miles away. We were actually pretty lucky. We had four CORS sites under 50 miles.

I am starting to like the GNSS Solutions more and more. I still need ot figire ot the elevation issue I have had on a few jobs, but I have a few checks that I do until I figure that one out.

Thanks again,
Jimmy

Jimmy ? CORS Question

Actually both methods are CORS solutions. You say you have 4 CORS nearby, which ones did VRS choose? Use the same 3 for your own post processing. Also verify the current position NGS publishes against the list in Solutions. There is a pdf on updating CORS you should read. With that you are comparing MacIntoshes to Romes.

Paul in PA

Jimmy ? CORS Question

Paul,

Thanks for the reply. I believe that the PDF that you are referring to is from the Ashtech ftp site. I believe that I have that downloaded and printed out. I will double check, though. I did use the published coordinates on the NGS data sheet for the control positions.

Thanks,
Jimmy

> I have a crew working on a site, and they are about 23 miles from the nearest CORS station. They are occupying a series of points using a pair of PM3 units in static mode. They are basically going to occupy one point all day, at least several hours, and move the other unit to the the three other points that we want GPS coords on.
>
> My thoughts are that if the initial "base" sits there for a couple of hours, and they move the other units around on the points, I can process my site "base" against the CORS, actually I have three all about the same distance from the site, maybe a little farther, and establish the base, and then process the other points against that point.
>
> Is my procedure what you would recommend? I generally would have sent the Hipers with them also, but I had to have them here for another job.
>
> I am fairly new to the processing against the CORS sites. I usually use the OPUS for my "seed coords"
>
> Thanks in advance,
> Jimmy

i have a suggestion and poll for the others, combined. considering you have only two single freq setups on a project, set one on station at each end of your project and do not move them. this gives you what i consider two bases rather than one base and one rover. the benefit from a static standpoint is that more data collection time is better, (generally).

another benefit would be higher odds of closing/high quality vectors both locally and from CORS stations.

if you absolutely HAD to occupy the other stations in the future, do that on another day. if not, do your terrestrial measurements and rotate/translate/scale only after the traverse is run.

in other words, i would rather know i had fewer 'quality' vectors than more vectors that could be questionable. Henri Ayers, of Leica fame, once asked us in a training, paraphrased; you have a scenario project with two buckets of data. in one very large bucket, there is good data with a few bits of bad data. the other bucket has much less data, but all of it is good. which would you use? sage words from a well respected authority

thanks, in advance, for your opinions. i look forward to knowing what some of you might think.

going to take my bride out for a big bowl of Pho. will check in later