Ok, I have this project that I have been contracted to do. It is pretty simple and straight forward. I am given a list of coordinates by a client that they want staked out. The project is an environmental cleanup, and the points are for limits of excavation. It really is a pretty simple job.
I went out and ran some static control on Tuesday. I created a "box" around the project site, the best I could, and observed the four points for a minimum of four hours. The idea was to use two OPUS points for control to get on TN NAD83 coordinate system. I observed the four points using two Hiper Lite receivers, and two Promark3 receivers with the Ashtech 110454 antenna. The units were placed on 2 meter rods with bipods.
Here is a diagram of my control loop:
I submitted the two files downloaded from the Hiper Lite Units to OPUS. The resulting Coordinates were:
Point 29
Northing: 392,990.851
Easting: 818976.275
Ortho: 307.607
Point 30
Northing: 391,129.854
Easting: 819,804.381
Ortho: 300.725
I used Point 30 as control in my processing procedures (it is the closest point central to the excavation areas), and ran the coordinates through GNSS Solutions (latest version) and Topcon Tools demo (latest version from Hayes Instruments website). I used Geoid12A.
The resulting coordinates were:
As you can see, the horizontal looks pretty darn good. The problem I am having is with the elevations. The coordinate listed above are from the SECOND time I ran the files through the processing procedure. The first time, the elevations were all over the place. The horizontal locations were in line with these results.
Looking at point 31, there is almost a 2 meter bust in the elevation. This is at least the second time that GNSS solutions has done this, the first time being back on the spring of 2011, which I posted about then.
On this particular project, elevations are not needed, but I expect better results from this equipment, and the software. I personally observed these points, and invested in the 2 meter rods and bipods to help eliminate potential sources of error in rod heights.
On the Hiper units, the first time I downloaded the files, I used PCCDU to download them, as I needed to get the configuration files off of the units, and converted the files to rinex using Topcon Tools Demo v7.5. The second time I downloaded the data from the receivers, I used TRU and converted the files using Topcon Tools Demo v8.2.
The Promark files were copied off of the sd card using a card reader, and them imported into GNSS Solutions using the download files option.
The first round of post processing resulted in the following elevations:
Point 30
Control 300.725
Point 31
GNSS Solutions: 282.57
Topcon Tools: 295.72
Point 29
GNSS Solutions: 301.07
Topcon Tools: 307.607
Point 32
GNSS Solutions: 294.71
Topcon Tools: 301.302
During the first round of post processing using Topcon Tools v7.5, I used point 29 as vertical control as a check, so I expected a few hundreths of difference in elevation, but not the difference that I saw in the results.
I need some help to wrap my head around what is going on here. I have always felt like I was fairly competent in GPS post processing, but this has me stumped. The issue back in 2011 could have really messed me up if the error had not been caught. On this particular project it is a non-issue, but I do use the GPS Units quite a bit to establish control, and transfer elevations.
Please help me figure out what in the heck is going on here. I have downloaded and plan to read the NGS papers on establishing vertical control using GPS. What gets me is that this appears to be a random issue, and it is almost an even 2 meter bust.
I have the horizontal positions staked, and all is good for the client. The task at hand now is for me to figure out what is going on for my own quality control procedures.
Thanks
Which points were control points (OPUS Points)?
One long static session might be OK for OPUS, but I would have used multiple sessions and moved my receivers around in each session in order to get a good LS solution which would have also more likely identified any antenna height bust.
Your HiPers are L1/L2 I believe, and your ProMarks are L1 only. I'd be very sure they dance well together.
One more suggestion is to reprocess using a different Geoid like 09 and see what happens.
Just my $0.02 worth.
a couple guesses...
drop back and check your gnss solutions. look for version3.80.8 it is more robust than some older ones. import your cors and hold them as the control stations. process vectors to your four stations on site. process among your four stations. check the loops from there.
when you finally do your adjustment, hold n,e,u on only one cors first. check for a problem. none? adjust again holding n,e,u on three or more cors. in other words, maybe the lsa is confusing type I and type II errors, an undetected something slipping through the tests.
alternatively, export the RINEX and see if the arp heights were changed from what was actually used. stranger things have happened
check your email jimmy
GNSS Solutions has a bug with slant heights
I haven't nailed it down exactly, but Solutions is crap with HI's particularly with slant heights. I noticed you mentioned that the PM3's were on fixed poles. But I'm guessing maybe your Hipers were not.
You'll have to start a completely new project because it seems to keep artifacts. But try starting a new project, this time, manually convert any slant heights to vertical (basically knock a tenth of a foot off the Hiper slant heights) and see if the results don't come out better.
Solutions has some neat features, but I'm finding it to be very cranky and buggy, to the point of serious distrust. Now that Trimble has bought Ashtech out, I don't see it being fixed either. Paint me Pessimistic.
It could be that the 2 meter bust is a antenna height that was not recognized??? I have been seeing the .4' diff. in the GNSS and the Topcon almost every time I use OPUS. I have no answer. We do a lot of flood certs. and tie into the water surface after calling the dam at Pickwick.
Thanks for the quick replies.
I am away from my desk at the moment, but will probably put the data in a public dropbox folder for anyone that wants to play round with the data.
ALL the receivers were on 2 meter rods.
I assume you are using the same Geoid Model?
Are you absolutely sure you entered the rod height correctly on the one that is 2 meters off? As for 0.40' , that sounds like it could be confusion over where exactly the software thinks you are measuring on the HIs. For example, The old version of Solutions did not take into account the vertical offset between the top of the 2 meter rod and the phase center of the GPS. You had to look that up add it to your 2 meter HI. I know that Topcon processing does take this into account. I'm not sure if GNSS solutions does or does not, but it could be the source of your 0.4' error.
Two thoughts came to my mind when reading your post:
1) Does your copy of GNSS Solutions provide for L2 processing? I think you need a dongle (software unlock) to do dual frequency processing.
2) Two meter difference on 31 - sounds like somehow the rod height is being calculated as zero instead of 2 meters.
Al
Thanks for all the replies.
When I open the occupations tab, all the rod heights show 6.562 ft. My GNSS Solutions does not allow for L1/L2 processing, only L1.
I plan on providing a link to the files so anyone that wants to give it a try. I am hoping that someone can help me figure out what in the world is going on.
I just thought about something. Topcon Tools provides an option to export L1 data only when exporting the rinex file. I might try that and reprocess.
I am open to any suggestions to figure this out. I will dig back into this when I get back in the office in the morning.
Thanks again, I appreciate it.
Link to Rinex Files
Point 31
https://dl.dropboxusercontent.com/u/75831523/00011551.13O
Point 32
https://dl.dropboxusercontent.com/u/75831523/00021551.13O
Point 29
https://dl.dropboxusercontent.com/u/75831523/base155r.13O
Point 30
https://dl.dropboxusercontent.com/u/75831523/rove155r.13O
I hope these links work. This is the first time I have tried sharing a file through the public folder on Dropbox.
Thanks again for any and all help.
Link to Rinex Files
Jim,
I processed your data with Topcon Tools v8.2 and the verticals agree with the OPUS and TTools results.
When comparing your verticals above GNSS vs. TTools, they all miss by a factor close to 6.56' or 2m. Looks like the antenna heights are NOT working correctly in your GNSS Solutions software.
I have NOT used GNSS in years. But you can download a newer version of Topcon Tools. It will still process up to 5 points in demo mode.
Lee Green
Link to Rinex Files
i'm with lee on this one. similar results here
I used Trimble Business Center 2
Geoid: EGM2008-1'
CS: US State Plane 1983
Datum: NAD 1983 (Conus)
Zone: Tennessee 4100
30 held as starting and got this
29 392990,826 818976,276 307,625
30 391129,854 819804,381 300,725 (fixed N,E,El)
31 391372,760 819508,879 295,728
32 392812,478 819898,270 301,296
TN45 372024,877 876710,919 300,266 (calculated)
ant model for 32, 30 I used ProAntennaL1 not sure if this is the one matches the one you used.
I downloand rinex for TN45 and calculated it, could not find quickly published coords for it an gave up 🙂
SOLVED!!! GNSS Solutions Rod Height/Elevation Issue
The mystery surrounding the rod height/elevation issue has been solved.
There appears to be an issue with the way GNSS Solutions was/is reading the rinex files for the observation by the Topcon Receivers. The way to deal with this issue is listed below:
Select the 'Files' tab. Double-click on the left most column (under the funnel), to the left of the each of the two Hiperlite files, Select the "occupations" tab:
Click the 'Apply to all" button (lower-right), then click on OK. Repeat for both Hiper files.
Reprocess (F5) then Adjust (F7).
For some reason, there is a sporadic issue with the embedded rod height not registering for the observation. I believe that someone mentioned something about the antenna heights not registering. Now we have a way to "force" the antenna height to register before we process data.
I had totally forgotten to mention in my original post, that when I tried to adjust the network, the whole project would not adjust.
Also, as a side note, the issue that Shawn Billings mentioned about the slant heights in GNSS Solutions. If you update the default antenna file that is in GNSS Solutions with the file from NGS, the radius value is missing in the NGS file. You have to make sure that value is entered for whatever antenna you are using. I found this out during my research.
After I created a new project, reimported the data, and used the procedure above, I had results that were within reason for the OPUS and Topcon Tools results.
THANK YOU to everyone that offered suggestions and help. Without your help and suggestions, we would not have been able to figure this out.
Have a great weekend everyone.
SOLVED!!! GNSS Solutions Rod Height/Elevation Issue
:good:
interesting post!
Chr.
