Weird Verticals

[JBrinkworth]

Is it possible that the LS double applies the vertical height offset in the raw data?

Here's what I found...

T2-(HI) 2.0m + 0.025m adaptor
LS-(HI) 4.92 -0.37 (Vert. Height O/S) to obtain a true 4.55' HI

DAY1
1. Set Control Point 100 w/ RTN.
2. Set up T2 on 100 and collected static data while RTK'ing with the LS.
3. Submit Static file 100 to OPUS-S and DPOS. I also chopped up Point 100 into 5 RS files. Everything is pretty tight, really.
4. Export G-File of all vectors to StarNet, hold the post-processed 100 & adjust all vectors.
5. Residuals look good.

DAY2
1. Set up on Control Point 101 (previously shot and adjusted from 100). Same HI's
2. Check into Control Point 100. HZ is very good, but VERT is 0.41' low.
3. Additionally check into other control points and VERTS are low by 0.35'-0.43'
4. Shut down base on 101. Set up the LS for RTN and check into 101. It checks HZ and VERT within 0.02'

POST PROCESS DAY 2
1. Export .CSV file of the day.
2. In the .CSV file, RTN-only shots check both HZ and VERT to previously established points. The points collected via RTK are all still low by 0.35'-0.43'
3. Export G-File of all shots from Day 2. I process all RTN points against their respective CORS base and process RTK points against the T2 data obtained from Point 101.
4. The adjustment of the G-File results in all points low by 0.35'-0.41' even the points collected by RTN. Something's going in in the G-File export function, I think.
5. As an additional check, I submitted an OPUS-S file for the data collected on Point 101 on Day 2. HZ and VERT all checked to what was shot on Day 1.

In review, it appears that the vertical height offset of the LS is being double added to the raw data in the LS. AND it only happened on Day 2, not Day 1. Any ideas would be greatly appreciated.

 

[Shawn Billings]

I don't understand this part:
LS-(HI) 4.92 -0.37 (Vert. Height O/S) to obtain a true 4.55' HI

What do you mean by this? Did you apply this 0.37' offset in someway?

 

[JBrinkworth]

My rover pole reads 4.92 all the way down (to compensate for Trimble's MT1000). But, the LS on this rod measures 4.55. Here is a picture of it.

By the way, I am working with another crew on this job and they localized to the adjusted data from Day 1. They confirmed that everything checked. Seems like the problem is coming from Day 2. However, I didn't change my workflow.

I should mention that I used this same antenna height setup for both days.

 

[Shawn Billings]

ok. I think I get it. The pole you're using shows 1.5m, but when you measure from the pole tip to the bottom of the LS, you actually measure 4.55 feet.

Let me do a little testing and I'll get back to you unless one of the other guys has an answer for you sooner.

 

[JBrinkworth]

You got it!

Thanks.

 

[Adam]

I usually start out like you JB, setting a point on the network, then setting my base on that point. I also will switch between my t2 base and a network quite frequently as a check and haven't seen any issues between the two. I am curious what the comparison would have been without post processing day one.

 

[Matt Johnson]

I checked and found the bug is that antenna height offset is not being applied after the LS is rebooted unless it is updated so that was why all your points on the 2nd day were low. We should be able to fix this in the next version of J-Field but in the meantime if you want to fix your points from the second day you would need to adjust their current antenna height down by the 0.37' offset. To do this:

From the Points screen select the

(Additional Actions) icon and then choose "Multi-select actions"

Select your survey points from the 2nd day and then choose "Edit selected objects" from the Additions Actions menu again:

Change the Antenna Height to 4.18 (Existing 4.55' - 0.37' Offset) and press Apply.

The antenna height stored with the points will be wrong but this will correct the coordinates.

 

[JBrinkworth]

I checked and found the bug is that antenna height offset is not being applied after the LS is rebooted unless it is updated so that was why all your points on the 2nd day were low.

Thanks for checking into this.

I wonder why it applied the AHO on the first day, but not the second? I actually started a new job on Day 2 with imported, adjusted points. After Day 2, I did update all software before exporting the day's work. Does this come into play at all?

1. Would you mind to expand on the comment I quoted above? I am still unclear on what is actually going on.
2. Until the bug is fixed, would it be best practice to input the height as 4.55 and leave the AHO at 0.00?

I am very grateful to those who give of their time on this site...not only for this issue, but all of the others as well. I know that if I have a concern, it will be addressed by competent surveyors.

Thanks!

 

[JBrinkworth]

I usually start out like you JB, setting a point on the network, then setting my base on that point. I also will switch between my t2 base and a network quite frequently as a check and haven't seen any issues between the two. I am curious what the comparison would have been without post processing day one.

Adam, here is what everything looked like before Day 1 adjustment, after Day 1 adjustment and after Day 2 adjustment.

Before Adjustment
POINT ELEV
100 820.50
101 819.34
102 816.66
117 821.16
121 818.00

After Adjustment
POINT ELEV
100 820.43
101 819.29
102 816.61
117 821.07
121 817.93

Not much going on here, relatively about the same.

Day 1 Data-->
Relative Error Ellipses (FeetUS) -- Confidence Region = 95%
From To Semi-Major Axis Semi-Minor Axis Vertical
100 101 0.008120 0.006008 0.014573
100 102 0.007853 0.005609 0.010365
100 117 0.017215 0.011453 0.026591
100 121 0.013025 0.006840 0.021321

Adjusted Observations and Residuals-Adjusted GPS Vector Observations (FeetUS)
From Component Residual StdErr StdRes
To
100 Delta-N -0.0009 0.0058 0.1
101 Delta-E -0.0041 0.0048 0.8
Delta-U 0.0070 0.0114 0.6

100 Delta-N -0.0004 0.0059 0.1
102 Delta-E 0.0008 0.0039 0.2
Delta-U 0.0014 0.0087 0.2

100 Delta-N -0.0000 0.0067 0.0
117 Delta-E 0.0000 0.0051 0.0
Delta-U -0.0000 0.0136 0.0

100 Delta-N -0.0000 0.0102 0.0
120 Delta-E -0.0000 0.0067 0.0
Delta-U -0.0000 0.0172 0.0


Day 2 Data added to network from Point 101 -->
Adjusted Observations and Residuals-Adjusted GPS Vector Observations (FeetUS)
From Component Residual StdErr StdRes
To
101 Delta-N 0.0040 0.0038 1.1
100 Delta-E -0.0282 0.0038 7.4*
Delta-U 0.2902 0.0132 21.9*

101 Delta-N -0.0013 0.0052 0.3
117 Delta-E 0.0024 0.0042 0.6
Delta-U 0.1195 0.0122 9.8*

101 Delta-N -0.0136 0.0047 2.9
121 Delta-E -0.0099 0.0042 2.4
Delta-U 0.1069 0.0109 9.8*

 

[Adam]

Looks good, I wasn't aware of the bug.


Matt, if you re enter rod height and the offset after reboot does that still happen?

 

[Shawn Billings]

Day 2 Data added to network from Point 101 -->
Adjusted Observations and Residuals-Adjusted GPS Vector Observations (FeetUS)
From Component Residual StdErr StdRes
To
101 Delta-N 0.0040 0.0038 1.1
100 Delta-E -0.0282 0.0038 7.4*
Delta-U 0.2902 0.0132 21.9*

101 Delta-N -0.0013 0.0052 0.3
117 Delta-E 0.0024 0.0042 0.6
Delta-U 0.1195 0.0122 9.8*

101 Delta-N -0.0136 0.0047 2.9
121 Delta-E -0.0099 0.0042 2.4
Delta-U 0.1069 0.0109 9.8*

Was this after editing the antenna heights as Matt suggested above? 101-117 and 101-121 look good. 101-100 looks pretty rough at 0.29'. The Standard Residual flags indicates the error estimates for vertical were overly optimistic, compared to what was observed in the residuals.

 

[JBrinkworth]

Was this after editing the antenna heights as Matt suggested above? 101-117 and 101-121 look good. 101-100 looks pretty rough at 0.29'. The Standard Residual flags indicates the error estimates for vertical were overly optimistic, compared to what was observed in the residuals.

No. I haven't run the new points yet. That is the data from the elevations being 0.37' low. Once I fix Day 2, I will add to the adjustment and post the results.

 

[Shawn Billings]

Ok. So the residuals are probably from the observation to the adjusted value, since it's a tenth... I was thinking it might be the residual between the two observations. A tenth wouldn't be too bad in that case.

 

[Matt Johnson]

Thanks for checking into this.

I wonder why it applied the AHO on the first day, but not the second? I actually started a new job on Day 2 with imported, adjusted points. After Day 2, I did update all software before exporting the day's work. Does this come into play at all?

1. Would you mind to expand on the comment I quoted above? I am still unclear on what is actually going on.
2. Until the bug is fixed, would it be best practice to input the height as 4.55 and leave the AHO at 0.00?

I am very grateful to those who give of their time on this site...not only for this issue, but all of the others as well. I know that if I have a concern, it will be addressed by competent surveyors.

Thanks!

It was a bug with it not being applied after rebooting, nothing to do with installing an update. It has been fixed in today's testing version of J-Field. Until you get the next version of J-Field it will be better to just enter 4.55' for the antenna height as you stated.

Surveyed points are stored in the database with WGS84 (ITRF 2008) coordinates. The coordinate of the point on the ground is stored in the database, not the ARP coordinate. When exporting coordinates and g-files the value of antenna height stored in the database is not used in calculation the coordinates. When the antenna height is changed as I show above, the coordinate on the ground is recalculated and updated in the database by applying the change in height from the previous antenna height that was stored in the database.

 

[Matt Johnson]

Looks good, I wasn't aware of the bug.


Matt, if you re enter rod height and the offset after reboot does that still happen?

I just figured out the bug yesterday after seeing this post. Only when the antenna height offset was modified after rebooting was it being applied. Changing profiles also caused it to be applied from what I saw.

 

[Shawn Billings]

I just figured out the bug yesterday after seeing this post. Only when the antenna height offset was modified after rebooting was it being applied. Changing profiles also caused it to be applied from what I saw.

That makes sense. It just isn't reading the value on boot up unless it is edited.

 

[JBrinkworth]

After making the changes that Matt suggested, I've attached the residuals of the adjusted vectors from both Point 100 and 101. I think this looks MUCH better!

Thanks everyone!

 

[Shawn Billings]

That's beautiful. Looks like you've got some great field procedures to produce such low residuals. What was your recording method for this?

1Hz, 2Hz, 5Hz
Verification?
Validation?
Number of Epochs?

Whatever you're doing, keep it up.

 

[JBrinkworth]

Thanks.

This site is completely open and flat, coming in around 100 acres. So that helped!

2Hz
Verify w/ V6 Reset
Confidence Level @ 10
Consistency @ 5
Validate w/ @ least 2 engines
120 Epochs in the AM and PM before shutting down the base.

As for the base (Points 100 and 101 of this survey), I usually submit the whole static file plus 5-8 'chopped up' RS files of the static file to OPUS. The OPUS-RS extended report provides a covariance matrix that can be put into StarNet. Each OPUS-RS point is used to calculate a vector to calculate a final, adjusted point.

For the vectors, I export the Gfile and adjust around the adjusted base point.


Actually, the workflow for adjusting the heck out of a base point was taken from one of Kent's posts linked below.

http://surveyorconnect.com/threads/adjusting-opus-rs-static-positions.216517/

 

[Matt Johnson]

Today's update fixes the antenna height offset bug.