JBrinkworth
New Member
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.
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.