I've started trying to setup a control network on a corridor project. Im using a Trimble S6 and a 3 R10's.
For my GPS measurements I have 2 points on either end I was supplied coordinates for that need to be held (they tie somewhat decently between each other around 0.01m HZ and 0.03m vert). I've been supplied data where there were bases setup on each CP while doing static observations to numerous traverse hubs along the corridor. I've broken up the GPS observations and everything seems to be tieing pretty well between each other. I also have some old levelling data to those hubs that verifies there elevations are pretty good (the levelling closure wasn't the greatest (0.02m) but its a check for now, it will be redone). So i'm fairly confident in my static observations. Just enough to be satisfied there's no major blunder but it needs refining.
I started a traverse at the west end and made it to the middle of the project (1800m away). So the problem I'm seeing is my LSA is steadily dropping my elevations lower as the traverse goes on. Where I've stopped my traverse for now, I'm seeing and 0.11m (0.36') discrepancy in elevations.
?ÿ
My traverse checks into several GPSed hubs along the way and the elevations from the traverse drop as it heads East. If I look at my .csv from my data collector the elevation of my closing shot is only 14mm off the static elevation of the closing point. When I break up observations between common points of the traverse they are tieing to within 1-3mm. So that tells me its not an instrument issue or a blunder but something the LSA program is doing, maybe a setting I missed.?ÿ
?ÿ
One thing I noticed is when the LSA software imports the data its bringing in azimuths to the points I've tied without setting a back sight. When I used Leica in the past it would bring in the data as I'm setup at a point, back sighting a point and then the HCR to each point.
?ÿ
I called customer support of StarNet and they couldn't figure it out. I was hoping someone here is a StarNet or LSA wizard and can see something obvious I've made a mistake on.
?ÿ
As of right now I'm holding the HZ of my west and east traverse point and the vertical of my west. And holding everything on my far east CP (from which the static is being measured)
?ÿ
The chi squared values are ok beside the zeniths.
?ÿ
Of coarse there will be many more redundant measurements made, but I'd like to figure out what is going on first.
It looks like your combining the GPS and the Traverse in one adjustment. Seperate them out. I think the GPS is putting a slope in the elevations.
We need to see what you have set for your a priori instrumental errors.?ÿ See the 50 second mark of this video (instrument tab of the Project Options dialogue).?ÿ
The DM data lines are directions, not necessarily azimuths. What is important there is the difference between the various DM readings, from which the program calculates angles.?ÿ
@gary_g?ÿ
StarNet PRO is quite capable of adjusting GPS vectors and terrestrial traverse data simultaneously. Nevertheless the OP may wish to separate out the two until he has things figured out.?ÿ
How far are your traverse distances and are you considering curvature and refraction? At say a good balance bs and fs they can cancel each other out at say 300 ft or so but you are traveling a good distance and it can not cancel itself. The other thing is are you performing multiple rounds direct and reverse. And have you compensated the instrument prior to running the traverse. I am one who always trouble shoots by going back to the basics first those little things we neglect on small jobs because we don??t see them. But when we start moving a fair distance and forget to take those little things into consideration the systematically slip up on us. Now the above answer is very valid as well ?ÿthat check your traverse without holding the gps and see how it compares to the leveling to see if there is some type of slope. ?ÿIf you have some steep vertical sites a non correctly tilted prism could get you started in the wrong direction. Hope this helps in someway. Just pulling out some quick thoughts from the old dusty basement upstairs lol. ?ÿ
Rather than hold anything, set all the std. errors for the control point to a tenth, and see if the measurements are tight but the control point coordinates are not as tight. When you figure that out you'll know what to hold.
?ÿ
Thanks for all the replies so far.
The gps observations are all actually not affecting the conventional ties because they are not linked together yet with the same point numbers. There are currently no common ties between the two sets.
?ÿ
I set the instrument parameters as per s6 specs.
?ÿ
The instrument was calibrated at the start of both days. If I manually check my vertical angles if F1/f2 they add up very closely to 360. Also, I know the instrument is half way decent because like I said the .CSV file that is pulled from the data collector with out any least squares adjustment agrees quite closely with the static coordinate for elevation. This is telling me it's the LSA that's causing the issue.
Im letting the elevation float for now, so it's not being constrained other then the initial point I'm back sighting. The horizontal I will dive into more and tweak without holding the second point as fixed when it comes time to nailing that down.
?ÿ
?ÿ
?ÿ
?ÿ
I set the instrument parameters as per s6 specs.
What are the S6 specs for centering errors?
My apologies, I wasn't near my computer at the time to grab?ÿ a screenshot of my settings. I use 2mm for centering errors.
?ÿ
So I created a separate job using my local coordinates (same orthometric elevations though) and set it up in local vs UTM11. Low and behold, that was the issue. My traverse closes to 18mm to my static observation coordinate. So obviously I want to merge my GPS data with my conventional data. Any ideas why using a coordinate system is causing this? Even when I turn all my GPS observations off in the other job I get the same results, with the closing point being 0.11m lower.
?ÿ
You mention that there's .03m in the vertical between GPS control points (GEO1 and GEO37?). Where did the .03m number come from?
That is a large number which could make your verticals messy. I would figure that out before doing anything.?ÿ
.01m in the horizontal isn't all that great either.?ÿ
Does .03m in vertical mean in heights? For your GPS processing I wouldn't apply any Geoid model. That would happen after the Lat, Long, Height numbers are finalized.?ÿ
I can't say for sure, but if you use all your information and tighten up the main control points it may "fix" your issues. Holding points with that much error to begin with will make a LS adjustment messy.?ÿ
The gps observations are all actually not affecting the conventional ties because they are not linked together yet with the same point numbers. There are currently no common ties between the two sets
I have 2 points on either end I was supplied coordinates for that need to be held (they tie somewhat decently between each other around 0.01m HZ and 0.03m vert)
If you absolutely have to hold those two endpoints that disagree by 0.03m, just be aware that it's going to inflate the vertical standard errors of the adjusted coordinates. That 0.01m in the horizontal probably won't burn you too much, but that depends on the traverse.
My preferred approach would be to hold one or both GNSS reference stations fixed and use all the GNSS and TS observations in the adjustment.
If you HAVE to hold those endpoints fixed, you can do that and let the reference stations float in the adjustment.
Looks like you have the default standard errors sorted out pretty well, but I have always doubled the standard error of the zenith/vertical angle for total station work. If the instrument is a 1-second instrument per the datasheet, I use 2" for the zenith angle in my adjustment. The vertical is never as tight as the horizontal.
So I created a separate job using my local coordinates (same orthometric elevations though) and set it up in local vs UTM11. Low and behold, that was the issue. My traverse closes to 18mm to my static observation coordinate. So obviously I want to merge my GPS data with my conventional data. Any ideas why using a coordinate system is causing this?
UTM projections can have a lot of distortion, which makes adjustment of terrestrial data in grid dicey unless you are applying a unique scale factor at each station and/or each measurement.
Depending on where the project is located in the UTM projection - and the project specs - you're may need to either scale your GNSS observations to get to ground, or scale your TS observations to get to grid.
Out of curiosity - you're using Trimble gear but not processing in TBC? That would make this a bit easier. As much as I like StarNet, the interface isn't quite as intuitive and QC tends to take a lot longer. TBC makes grid-to-ground a lot easier as well.
?ÿ
I agree with Rover about using TBC for all the adjustments.?ÿ
You mention that there's .03m in the vertical between GPS control points (GEO1 and GEO37?). Where did the .03m number come from?
That is a large number which could make your verticals messy. I would figure that out before doing anything.?ÿ
.01m in the horizontal isn't all that great either.?ÿ
Does .03m in vertical mean in heights? For your GPS processing I wouldn't apply any Geoid model. That would happen after the Lat, Long, Height numbers are finalized.?ÿ
I can't say for sure, but if you use all your information and tighten up the main control points it may "fix" your issues. Holding points with that much error to begin with will make a LS adjustment messy.?ÿ
So the error in my conventional doesn't change when I turn off all GPS observations. I'm also not using observations between held control points. I turned them momentarily on just to see the difference between observed coordinates and held.
The gps observations are all actually not affecting the conventional ties because they are not linked together yet with the same point numbers. There are currently no common ties between the two sets
I have 2 points on either end I was supplied coordinates for that need to be held (they tie somewhat decently between each other around 0.01m HZ and 0.03m vert)
If you absolutely have to hold those two endpoints that disagree by 0.03m, just be aware that it's going to inflate the vertical standard errors of the adjusted coordinates. That 0.01m in the horizontal probably won't burn you too much, but that depends on the traverse.
My preferred approach would be to hold one or both GNSS reference stations fixed and use all the GNSS and TS observations in the adjustment.
If you HAVE to hold those endpoints fixed, you can do that and let the reference stations float in the adjustment.
Looks like you have the default standard errors sorted out pretty well, but I have always doubled the standard error of the zenith/vertical angle for total station work. If the instrument is a 1-second instrument per the datasheet, I use 2" for the zenith angle in my adjustment. The vertical is never as tight as the horizontal.
So I created a separate job using my local coordinates (same orthometric elevations though) and set it up in local vs UTM11. Low and behold, that was the issue. My traverse closes to 18mm to my static observation coordinate. So obviously I want to merge my GPS data with my conventional data. Any ideas why using a coordinate system is causing this?
UTM projections can have a lot of distortion, which makes adjustment of terrestrial data in grid dicey unless you are applying a unique scale factor at each station and/or each measurement.
Depending on where the project is located in the UTM projection - and the project specs - you're may need to either scale your GNSS observations to get to ground, or scale your TS observations to get to grid.
Out of curiosity - you're using Trimble gear but not processing in TBC? That would make this a bit easier. As much as I like StarNet, the interface isn't quite as intuitive and QC tends to take a lot longer. TBC makes grid-to-ground a lot easier as well.
?ÿ
That makes sense about doubling the vertical angular error. I will make that adjustment. Thanks.
And I totally agree about not wanting to hold either endpoint. The problem is the project has already started and things have already been built. That being said, I will make enough observations where I can confidently say the control is off and take that issue up with my boss when I have all my ducks in a row.
?ÿ
That's interesting when you say I should scale my ts observations to get to grid. I've never done that before, how would I go about doing that other then manually scaling every distance? Note that I'm really only see errors vertically. My horizontal is checking out within reason.
?ÿ
Starnet is usually pretty trouble free and i prefer it to TBC for LSA. If I absolutely have to, I'll switch to TBC but I'd rather figure out what's going on vs throwing in the towel just yet.
