Activity Feed › Discussion Forums › Strictly Surveying › My Least squares adjustment needs fixin’
-
My Least squares adjustment needs fixin’
Posted by bc-surveyor on April 13, 2022 at 2:04 amI’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.
jhframe replied 2 years, 4 months ago 18 Members · 46 Replies -
46 Replies
-
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.
-
Posted by: @bc-surveyor
I set the instrument parameters as per s6 specs.
What are the S6 specs 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.
-
Posted by: @bc-surveyor
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
Posted by: @bc-surveyorI 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.
Posted by: @bc-surveyorSo 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.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman -
I agree with Rover about using TBC for all the adjustments.
-
Posted by: @mightymoe
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.
-
Posted by: @rover83Posted by: @bc-surveyor
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
Posted by: @bc-surveyorI 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.
Posted by: @bc-surveyorSo 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.
-
IMO, your horizontal centering errors could be tightened to 0.001m, and your vertical centering loosened to maybe 0.004m. That simple thing might be enough to normalize your statistics.
I have found that Measure ups are a real weak point. Get several guys to measure the same measure up independently and you are going to get a surprisingly large range of results. Half a centimeter, maybe more, is totally reasonable. One thing about doing a lot of LS adjustments is that it educates you about what your errors actually are.
With regards to holding the GPS points fixed – as others have said in different ways – those coordinates are not perfect. I understand that, nevertheless, project management considerations may oblige you to hold them fixed. But that just means that their error must be distributed into the measurements. Doing so means that you may have to dial up the error settings of those measurements unnaturally to get statistics to “pass” chi-square. My favorite way of dealing with that is to mess with the centering errors.
Also – the vertical component of a GPS determined coordinate is always the weakest. A couple of tenths of a foot in each point is very possible. Better can be done but it isn’t guaranteed at all.
-
StarNet, generally, strokes my ego better. Wow that??s a great survey Dave! Wonderful statistics! You are obviously the greatest surveyor on earth! I go back 5 years later and don??t match myself that well, not bad but it points out how accurate I really am.
TBC will nag me about loose sets which is handy. Really easy to disable a bad set of angles. I take 4 sets, then look at the individual statistics, and if I have a loose set I tap Round+, that way I have an extra set to dump, I can dump 2 if need be and still have 3 left. This happens mainly on Forest traverses with steep loose ground.
I can make TBC happy but it??s more like your mother, okay if you think that??s good enough I guess it??ll be fine.
I use TBC exclusively at this point.
In the case at hand I would hold one point fixed and adjust my survey within itself, using only 1 point name per point. See how that matches the other given control coordinate values.
-
@norman-oklahoma
I still employ the Trimble tent pole.
Personal thing. Tapes are ok, but when it lands in the middle of the .01, I just spin and win. The pointy tip also ensures the location is a precise one and not subject to which random person is flailing away on the BM or Cap or whatever.
to each their own.
-
Posted by: @jitterboogie
I still employ the Trimble tent pole.
There are methods that will tighten up the spread in measurements, but there are none than will eliminate it. The tent pole is one. Leica has a measure down hook. There is the 2 meter fixed height rod. All these will beat the box tape measure up hands down. But 2mm is at the very limits of achievability even for these methods. Plus you have to consider just what the dumb end of the tent pole is founded on.
-
Posted by: @norman-oklahoma
2mm is at the very limits of achievability
For my GPSonBM sessions I measured 3 places around the ground plane, using the Trimble pole, at the start and at the end of he session, and was disappointed if all 6 measurements did not round to the same1 mm increment.
I did not try to compensate for the dimple in the disk, so was probably a half mm off. NGS did compensate for the dimple on the GSVS runs.
. -
The important function when processing and adjusting in TBC is the undo button.
Log in to reply.