Over the past few weeks, I have been inundated with calls from experienced users who are setting up GPS bases on sites and blowing the process. [ See also ]
There is a common misconception that you can put any coordinate in the base and have it work well.
These misconceptions are promulgated by manufacturers who hide automatic localizations behind a magic ‘setup’ curtain. A user can push a few buttons, configure a job at a site and sometimes end up with good coordinates, but they have NO IDEA what is going on in the background. While the underlying true base position and the automatically generated projection and ‘calibration’ can be viewed, most button pressers have no idea what is going on, where to look for the configuration and the magic site calibration ends up existing ONLY in the data collector of the ignorant button pusher.
If you are going to use RTK GPS, you need to explicitly understand what is happening when you configure a base.
I thought that I would write a detailed description of my thoughts on base configuration, but have re-read the Carlson User Manual and found it to be excellent. I have decided to make a few additional notes over the next few days here on the blog.
You can download a PDF copy of the User Manual using this link: [ SurvCE User Manual ] or from the Carlson Website. The Base Configuration section starts on page 146, is not too difficult of a read, and is an excellent resource.
Let me add these thoughts:
- When you configure the Base, your goal is to tell the GNSS base what the actual coordinates for the electrical phase center of the GNSS antenna are, including the actual ellipsoid elevation.This is done by telling SurvCE the position of the Ground Mark. (The point on the ground under the GPS head.)If you specify a projected Grid Coordinate, then SurvCE will convert it to the equvalent Lat/Lon/Height.If you specify the Orthometric Height, SurvCE applies the GEOID and computes an Ellipsoid Elevation.
Since you have provided the Ground Mark elevation, SurvCE will add the rod height HI (either slant or vertical) and the L1 offset (determined by the antenna model ) which sets the offset from the bottom (or measure up mark) to the electrical phase center of the antenna.
You give SurvCE the Ground Mark position and SurvCE computes the electrical phase center of the GNSS antenna on top of the pole and sends this Phase Center position to the receiver with a command to ‘Be a Base’ and broadcast corrections.
This Phase Center position HAS to be within 100 feet X,Y and Z of the TRUE geodetic location. The Phase Center elevation HAS to be ELLIPSOID so you HAVE to load and use a GEOID file if you are going to enter orthometric heights.
If the position is in error by more than 100 feet then Rovers which are using the Base for corrections probably will not be able to fix, or will fix extremely slowly. Bad base initializations also can have the effect of making the base appear to ‘hang’ — it just can’t compute correctors for the signals that it is receiving to broadcast.
Even the difference of the Geoid height (typically 30 to 60 feet) will severely hinder the rover’s ability to fix.
- I am not going to sugar coat the following statement: “If you are initializing your Base with an Orthometric height then you are crazy.” This is a cardinal sin and it cannot be forgiven.Let me give you an example. Pretend that you are at this location:
Lat: 40 44 10.22058 State Plane Northing (UT C NAD83): 7437104.68825
Lon: 111 51 34.19263 State Plane Easting: 1540786.56835
Ellipsoid Height: 1306.483 M (4,286.353 ft)
Orthometric Height: 1323.212 M (4,341.238 ft)
You might incorrectly configure your receiver as shown:
In the screen shot above, the orthometric height is entered as an ellipsoid height. This results in a 55 foot bust in the broadcast position of the base. This will significantly slow down a Rover’s ability to fix.In addition it will result in bad orthometric heights as the distance from the Base to the Rover increases.(The reason the ‘Orthometric’ option is grayed out is no GEOID is loaded or available.) - An important statement in the User Manual is: “When you are starting a new job (no information in the raw RW5 file yet), always use the options in From New Position.”
That sums it up: if you are starting a new job or series of jobs, always use the ‘From New Position’ tab. If you have coordinates for the base that are accurate, then go ahead and use them using the ‘Enter Lat/Lon’ or ‘Grid System Coordinates’ button.
Otherwise use the ‘Read GPS’ method of getting an approximate position. (You can always set the base at a random position, Read GPS and then do a localization on the Rover.)If you are reoccupying a base point that you have occupied before, then use the ‘From Known Position’ tab. The most common button is then ‘Read From File’. - The Carlson User Manual says that ‘Read GPS’ will return a position that is accurate in the range of 10 to 100 meters. On modern GPS/GNSS receivers, if the receiver has been turned on and tracking satellites for 5 minutes (and is located in the USA), a read GPS will return coordinates that is within 0.3 meters (1 foot) of the TRUE IGS08 framed location.The IGS08 framed position will be within a couple of meters of the NAD83 position that you probably want.
I am working on a follow-up post
- Configuring a base at a random point near your control at a job
- Using a single point calibration to match control on the control point (with the random base)
- Setting up the Base on the second day at this job
So more on this in a later post. ==> [ See also ]
M
Pingback: Setting Up a Base with Local Coordinates | ashgps
My issue has been going back on a Base Point that I have previously used and in the process have sent it to OPUS. Now when I return to the Base Point I have OPUS based State Plane Coordinates and Elevation but no RAW DATA to match, so I can not use the Ref File as this is in a Local Bastard Coordinates. What is the Proper way to set up?
Hi Dave, I think there are two things that happen in this work flow:
1. You translate the first day’s project to the OPUS derived position using ‘COGO: Transformation’ using the first day’s base point as the base of translation and the hand entered OPUS solution as the destination for the translation.
2. Now you can use the translated first day’s project as the Control File for the 2nd day’s work. When you go to setup the base, choose the Control File and the hand entered OPUS Base Position. This will translate the OPUS Base position back to DMS.s Lat/Lon/Ellipsoid.
I can work up an exact FAQ showing all the steps if needed.
Thanks, Mark
Hi ! Your article is very interesting ! My question is … i am from Greece and our official coord system is GGRS87 . I am working with GPS RTK BASE-ROVER . I have known accurate trigonometrical points and accurate orthometric elevations measured with leveling machine , rods etc . So why i have to load a Geoid file for correct elevations ?
Because GPS elevations without a GEOID are ellipsoid elevations. The ellipsoid is gravity free, you need to model gravity to match orthometric leveling runs. If your job is only 500 meters long, then it won’t make much difference.
Thank you very much for your instant answer .!!!
I am working in a highway construction 12 km long.
As i know all the geoid models fits to GRS80 because they calculate the the (N) differrent between Geoid model and ellipsoid . The coord system in Greece , GGRS87 use a moved ellipsoid with dx , dy , dz . There isnt a global geoid model to fits in this .
Plus when i set up my base with orthometric elevation but (without geoid file) ,
all the corrections that i receive to my Rover are coming from the correct elevation like N=0 , h=H .
and i have 2-3cm accurancy around 5-6 sq.km.
But i am trying to find out the proper way scientificaly….
Thank you again….!!!!
Your base expects to have the correct ellipsoid height entered. If you enter an orthometric height then the base position is in error by the geoid separation. This will make the rover more difficult to fix. It is the same as entering a horizontal base position that is in error by the geoid offset.
So, always set the base with the ellipoid elevation. Anything else is an error.
If you want to assume the geoid is flat over your job, then use a single point vertical calibration on the rover to offset the rover height by the geoid separation.
Where I am at, there is a 3 meter difference between my office and locations 10 KM to the east. So if i use your method, my elevation will be in error by 3 meters, 10 KM distant. Even west of my office, in the center of the salt flats, the geoid difference is significant.
I suggest that you find (perhaps with an online tool) the separation value at 1 KM spacing intervals along your project. If all of the separations are the same by your accuracy expectations, the you don’t need a geoid. Otherwise you do need a geoid.
I am working also with Carlson survce and i am happy for this..!
I knew this that you say that if you enter orthometric elevation as ellipsoid is difficult to fix and all these but i thouth that this happen only if you enter ellipsoid coors φ,λ as the example of carlson saws not when you enter grid system coords as i use .
The strange that i do the same for many years in different sites and citys , so now i try to find out out how happen this with the oposite way because it works……hahah
Just by courious , in which ellispoid , and projection and datum you are working..?
My name is Haris Alexandrakis and thank again for all your knowledge!!!
I work in the appropriate state plane zone (which for my location is Utah Central NAD83). We work in decimal US Survey Feet (1 meter * 3937 / 1200 = 1 sFt).
You must be careful, Carlson SurvCE will warn you if the base horizontal position is in error by more than ~300 meters. However it will (errantly) allow you to set an elevation that is in error by 2000 meters (or more.)