California Surveyors Forums

O.K. Years ago when I ran crews I had all of them burn 12-20 minutes on points unless they were doing a geodetic map and then it was 1.5 hours with multiple setups. Anyway, we were using Trimble L1/L2 GNSS.

Then I started my own company and went with come inexpensive Ashtech L1 units. They did pretty amazing things considering their cost. I ran 2 bases and tied out points in 4 minutes if it was less than 1000'. I ran experiments and had checks of hundredths (or less) vertically and horizontally (Using GNSS Solutions).

There were limitations (which I won't go into now) and I decided it was time to upgrade a year ago or so to new L1/L2 GNSS units. I did some CORS static sessions and mostly RTK using a virtual base and physical base.

Anyway I recently did a static survey (mostly to test it out than out of necessity) for a project where the greatest distance from the base station was probably 900 feet. We're talking very short baselines. Since I did such short baselines with the L1 only GPS I thought I could do the survey with an L1/L2 GNSS GPS just the same and get a better result. During the survey I set up over a known control point and tied out (static) two other known control points I've tied into dozens of times over a year for a construction project.

However, during the post-processing I noticed that the vertical was way off (even the delta's didn't add up). I then checked the horizontal values (delta’s between the known control points) and the GPS static inverse was within a 0.01' of the value in CAD. The vertical was off by 5.84' to both of the other known control points I checked into. My HI for the base could be a foot off (operator error) but I'm not going to miss it by 5 feet! I thought is could be multipath or something else wrong so I did a couple of things to check it.

1. So then I check the base station to the CORS nearby to see if there was some multipath and it checked with reason. 2. I then submitted it to OPUS and they had the EXACT same elevation for the base station as I did using my post-processing software (I had over 3 hours of data).

3. I thought there might still be something wrong with my unit so I did an experiment where I cooked a 20min vector to a local CORS station with both units on separate occupations using the same tribrach and tripod (just switching out the units to eliminate operator errors). I had an answer with thousandths for both units. I also set up on a known benchmark as a triple check, and it was with a tenth of the published value). This tells me the units are working fine.

The only thing I can think of that would give me bad vertical is the fact that I only cooked vectors to the rover for 4 minutes. It seems like you should be able to do this.

What do you think?
Does difference software handle shorter occupation times better?

The rover was a fixed height and I've eliminated any meter to feet issues and any issues with a unit being bad.

My next experiment is to cook a 4 min vector and a 15 min. vector to the same point and see if I have the same problem.

Thanks,

Since I did such short baselines with the L1 only GPS I thought I could do the survey with an L1/L2 GNSS GPS just the same and get a better result.

L1 fixed is as good as it gets for short (<10 km) vectors, so the L2 and Glonass aren't going to help you any there.

If it were me, I'd first check all the processor settings. Next I'd try turning off the Russian SVs to see if GPS-only works okay. If that doesn't turn up anything, I'd try another processor to see if I get a different result.

.

The operative word is "GOOD DATA". The length of time really does not matter if the data is bad or of poor quality. Are you able to look at the satelite data and edit out cycle slips.

It was very clean but I did block out a couple of spots with "noise". Clear skies and PDOP was low. Not sure what is happening since the error is consistent and the horizontal is tight.

Here are the changes from the entered provisionals.
Station dN dE dZ
4 -0.0005 -0.0000 -5.8822
5 -0.0000 -0.0000 -0.0000
206 0.0004 0.0003 -5.8757

That's pretty consistent! Seems like I've got a setting or a "hidden" offset or something messing with me. What wierd is if I hold two of the points it gives that other one (206) a negative orthometric height. This tells me that something is wrong with the rawdata (I think).

I also switched Geoids in case the one I was using (Geiod09) was corrupted and I got the same answers. I'm going to re-tie these out today using RTK and will be currious to see if everything is -5.88 feet off.

This is a few miles away from VAFB. Any chance that they are doing something to mess me up?

During the survey I set up over a known control point and tied out (static) two other known control points I've tied into dozens of times over a year for a construction project.

How was the elevation on the original control established? Were the subsequent ties done by GPS or were any of the checks done conventionally, as a check of GPS derived positions?

Could it be a tilted-plane issue with a prior real-time calibration? Seems unlikely but I'm just guessing here.

What is the orthometric height and datum for your project control?

The only thing I can think of that would give me bad vertical is the fact that I only cooked vectors to the rover for 4 minutes. It seems like you should be able to do this.

If you are measuring your vectors real time, I would think that 4 minute observation times are more than adequate.

For a smaller project size such as yours, I would think that the geoidal separation would be fairly consistent througout, with differences nowhere near a magnitude of 5.8 feet. I suspect that you could just compare the elipsoid height differences and disregard the geoid model altogether. That would be one less variable in the mix. Or, I could be way off base here, no pun intended!

This was a static survey. I went out again and tied out the same two points with a 4 min obs. and they checked within a couple of hundredths to the historical elevation. One of the techs looked at the static data and apparently the base station was only tracking 4 satellites for half the time. SBAS may have also been a factor. Good thing I always have redundancy in my measurement’s!

Thanks,