The antenna height was mistakenly set at 2.268m when it should have been 2.134m. I checked in my base settings and it was set correctly to 2.134m with a measured height of 2m so I don’t know why or how my GCPs were recorded with an antenna height of 2.268m?
Is there a way to edit / correct the antenna height of all my GCPs in my survey project after the fact?
Eric,
Yes and no.
On the device, no. Or at least not easy.
I would export your points to a PENZD CSV (from Flow360) and manually alter the height (Z) values for each point in Excel. Just make sure to save back in .csv format. Then you can import them into a new project on the same Datum and move on.
Depending on how many points you have, you could just run a formula down the side (to subtract your discrepancy of 0.134m), then paste the values across to the Elevation column. You only want the Point/Name, Easting, Northing, Elevation, Description and/or Code fields.
Hope this helps.
Joel
Hi @joelbladen, thanks for your response. Seems easy enough to fix. I need to learn what the difference between a PENZD CSV file and a standard CSV is and when to use a PENZD type.
Do you have any idea what may have caused the antenna height to be set at 2.268? I guess it was me just not paying close enough attention. Something I will have to check from now on. Since it’s not possible to set the antenna height in the Survey section of Emlid Flow it can only be changed in the Base Settings menu of the Receivers section. Based on the picture in my original post, I thought I had the measured height set to 2m, but apparently not.
In any case, thanks again!
Eric,
Antenna height can be changed on the fly while you are surveying. You just have to be careful that you remember to change it back.
While surveying, you will see on the bottom of the map (with the current Averaging, Easting, Northing, etc), a little box that should show your height (in my case, usually 1.8 or 2.0). Just tap that, enter in the new antenna height, and setout or pickup will reflect the change, until you change it again.
Joel
Edit: As for why the 2.268, not certain. Conveniently, it is 2m plus two of the ARP (2 x 0.134). Perhaps just user error.
Yep, sounds like 2.134 was input but the system knows by the receiver which ARP is applied automatically so it was doubled. If a standard 2m rod was used then the base height looks correct but the antenna height reported in the point data is the rover. Were the points higher or lower than expected?
hi @michaelL & @joelbladen, I went back to the site yesterday and used the stakeout function to find all of my GCP locations. Then I re-recorded them in a new survey project making sure my pole height was set to 2m and the antenna height was 2.134. All of the new GCP points were within 1-4 cm of the original ones.
Next I subtracted .134m from the original GCP elevations. The interesting thing is the difference between the new elevations and the original “uncorrected” ones is smaller than the difference between the new elevations and the “corrected” ones. In other words, subtracting .134m made the problem worse, assuming the new elevations are correct.
So I got to thinking, if the software subtracts the antenna height to get to the ground level and my original antenna height was set too high, I would actually need to add .134m to get the correct elevation using the original readings. I know it’s counterintuitive, but does this make any sense? My thinking is that if the too high antenna height was subtracted from the calculation, the ground elevation is actually higher than what the receiver thought?
Maybe my logic is incorrect, but I just wanted to run it past you for confirmation or disapproval?
Here are my figures:
Elevation Recorded on day 2 with pole height set to 2m & antenna height set to 2.134: 1422.508
Elevation Recorded on day 1 with pole height set to 2.134m & antenna height of 2.268: 1422.345
Elevation with .134m subtracted from original reading: 1422.211
Elevation with .134m added to original reading: 1422.479
In the future I am doubly going to make sure my pole height is set to 2m so my antenna height will be 2.134 to avoid this confusion!
Eric, it might sound counter intuitive, but it kind of depends on where you are adding or subtracting the difference.
In this instance, the reference is the ARP, which is the top of pole (bottom of Reach). All calculations are based on this point. So when you subtract the 0.134 from the pole height, it should conversely increase the ground height by the same. I probably should have clarified the subtraction part from before.
Joel
Hi @timd1971, I do have two 2m survey poles, one for my base and one for my rover. The problem occurred when I entered the wrong pole height of 2.134m into Emlid Flow, when I should have entered 2m. The base settings were correctly set at 2m in the Receiver section of Emlid Flow, but I must have entered the wrong height into the survey project when I created it.
The good news is now I know better and I won’t make the same mistake again!
A thought for those doing PPK or RTK without tilt-compensation:
All that matters for height is the difference in heights.
(antenna to ground-marker height of base and of rover)
So if you chose fixed-length 2-meter poles for base and rover, the height-settings could be left at zero and zero.
(or any arbitrary number, so long as the numbers are set the same)
e.g.
+2-meters -2-meters = 0-meters
+2.134-meters -2.134-meters = 0-meters
It won’t make any difference to your results.
Hi @ceith
It does matter if you are targeting your gcps and tagging them in photogrammetry software with the coordinate. You need the coordinate to be on the ground.
Maybe I’m missing something then.
Say that base and rover were on 2m poles and height was set to zero for both. How would your PPK/RTK solution be any different than if you set 2m for both?
Your gcp would be 2m off vertically. The target is laying on the ground and that is the elevation you need. If you didn’t use an antenna height, the reported coordinate would be 2m above your target. Make sense? If you are using an rtk drone as the rover, your entire surface would be off 2m in vertical.
Example:
Both receivers laying flat on ground. Antenna heights are set at 0m. Emlid Flow reports RTK fix at an elevation of 0m
Now, raise up rover 2m above ground; and Emlid Flow reports RTK fix at an elevation of +2m
Now, raise up base 2m above ground; and Emlid Flow reports RTK fix at an elevation of 0m.
Bring the rover down to ground, and Emlid Flow reports RTK fix at an elevation of -2m
Bring the base back down to ground and Emlid Flow reports RTK fix at an elevation of 0m
I think that illustrates the simplicity of operating with base and rover poles that are identical height. Then the height-settings can be left at zero, at 2, whatever - so long as they are the same.
I understand what you are getting at. I’m just saying that it doesn’t work out if your rover is a drone.
Precisely.
If you apply a “0” height for the antenna height, the software is computing an elevation at the ARP (bottom of the receiver).
When you apply a rod height of 2.0 m to the bottom of the ARP, the software computes the elevation to the bottom of the rod (ground height)
The only way to convince yourself of this is to occupy an NGS passive control mark, apply both “0” and your rod height to the ARP for two separate observations and see for yourself.
The exercise we’re talking about is to help understand the relativity between base and rover antenna-heights, and to move toward the understanding that base antenna-height and rover antenna-height do not matter separately, and that only the difference between them matters.
With that in mind, I think it is a bit distracting to suggest involving a known-point in the exercise. Any place should do.
The OP had been using two 2m survey poles (see post #8), and I just wanted to point out that if you always operate with same-height poles for base and rover, that your antenna-height settings don’t need to be re-set, so long as the antenna-height settings match between base and rover.
(except when using RS3’s tilt-compensation, where an accurate rover-height is critical)
Another example:
Use two 2m poles one day; use two 2.4m poles the next day, and antenna-height settings can remain the same for both days. So if you forgot to change it, or if they are both set to zero, no need to worry.
This might be the case to conceptually understand how the RTK system works, but to then ignore other factors about it I believe is counter productive.
If you utilise a CORS Network as your base, yes, the LLH/ENZ being propagated will be in reference to the antenna height and your rover will then to the calculation and correction for where you are in LLH/ENZ. Then applying a pole height further calculates the position on Earth, not a point above it. Oftentimes, CORS stations are on top of buildings, on poles in a paddock, etc. but you could also do the same with your own base. When you come back a day, month or even years later, you will never be in the same place in space. If you do not know for certain your position, it could have shifted (in Australia, it is about 7cm per Year from WGS84).
If you ignore a known point as your base (such as a State Control Benchmark tied to a State/National Datum or a secondary point of your own), then there is literally, without certainty, no certainty that your survey at the time could be legally traceable or checked against for possible errors in the system at the time of Survey.
As for Eric (OP), I think he has already seen two components of the system where it pays to check your own work.
