Sure, that is all good, but it diverges from the OP’s scenario again. He had a base and a rover and two 2m poles and was doing RTK or PPK, so my comments were related to his identical-height poles, and how, for simplicity, if the poles are the same and the antenna-height settings are the same, that is really all that matters to that use-case.
Understandably it doesn’t relate to other cases where you don’t have a base (L-BAND, NTRIP or PPP, etc.).
I think you accidentally at the start used 2.134m (total of ARP and ARP to APC) not knowing that Emlid Flow would already add 0.134m (ARP to APC) to your “h” (measured height to bottom). So the 0.134m got added again for incorrect 2.268m.
If your pole is 2m, you just needed to use 2m for “h” (point on the ground to the ARP (BOTTOM of receiver). That’s it.
Hi Eric,
Just to summarize: Currently, to change antenna height after the survey, you can export your points to your project (PENZD .csv file) and manually change the height for each point in Excel.
When inserting the antenna height in Emlid Flow, you need to select the distance between the mark and the bottom of the receiver. The antenna offset is 134 mm (for RS2/RS3) and is automatically added by Emlid Flow.
It’s not true that only the relative height distance matters.
What matters for the base station is its own position in space, so the rod height is irrelevant. Well, unless you’re setting it above a surveyed point. It’s logging GPS signals and you can use those logs to correct your rover data, either in real time or post.
The rover is also calculating its position in space. But when you record those positions in the Flow software or in your postprocessing, you’re applying an offset for the rod height to get the elevation of the ground.
OK, but if you start out an exercise by saying that base rod-height is irrelevant, then you are also implying that rover rod-height is irrelevant as well.
i.e. If you did a survey exercise with base and rover on two rods of unknown length, then the resulting elevations would be relative to each other, and not tied to a control-point; “floating” if you will.
BUT if you held those two rods side-by-side and saw that they were of equal length, then yes, you could tie the surveyed elevations to a control point.
(effectively the same as base-shift)
Take it one step further and even if those two rods of unknown length were not the same length, you could enter only the difference in their length as rover antenna-height and leave base antenna-height at zero, and get proper results.
At this point is is more about understanding and less about practicality. But I suppose if, during your travel on the way to a job, someone had relieved you of your poles/rods from the back of your truck; and then you managed to borrow two broomsticks that worked for poles, then you could still be confident about getting your elevations.
(and here is the cue for someone else to talk about plumbing a broomstick)
They’re both irrelevant really! What matters to the base station is the position of its antenna in space.
What matters to the rover is also its antenna position in space. That’s what its calculations are based on. The rod height is only to figure out where the ground is.
There are no relative heights involved. The base station is only collecting signal data from the satellites, and that data is used to correct the signals received by the rover. This is true whether you’re doing RTK or PPK. I think a common misconception is that the error at the base is used to fix the error at the rover.
I use the Pearl Harbor VALR station for my PPK corrections and the antenna height is 0m because it doesn’t matter. Only its position above the ellipsoid is given.
Yes, no disagreement there, but again, we shouldn’t lose sight of the OP’s use-case in these arguments.
OP had a base and a rover; was using two 2-meter poles; and he was inputting antenna-heights. My point was that if antenna height-settings were wrong, but set identically in the base and rover, and if the poles were identical heights, then the results would still be fine.
(so long the height-error is within reason, and not at some wild extreme)
When you say there are no relative heights involved, perhaps you are just considering it in a different context.
When I said it was relative; I meant that when you increase the base antenna-height setting it raises the rover’s coordinate, and when you increase the rover antenna-height setting it lowers the rover’s coordinate; therefore increasing both or decreasing both antenna-height settings at the same time has a net-zero effect. One could even say that the two antenna-height settings are inversely proportional to each other, and that would be their relativity.
I think you’re have a misconception of what the base station is doing. It’s not telling the rover its measured height. The base is just logging signals from the satellites. It knows what signals it should be getting so then errors can be calculated and used to correct the signals going to the rover. Then positions are triangulated using the corrected signals.
The base thinking it’s the wrong height doesn’t get offset by the rover also thinking it’s the wrong height. All it does is place the calculated ground coordinates at the wrong elevation.
Yes, of course the antenna positions are key to the RTK solution, since those are the sensors; and yes, separately some math is done to find the bottom of the rod/pole/marker-height/ground; math that is done based on user-input (antenna-height settings). No disagreement there.
My point though, was from the perspective of the OP (a user) who is faced with inputting antenna-height settings, and what the effects would be on the results, in variations of the OP’s particular case.
I reread this thread and realized no one told the OP the simple solution–
Do postprocessing with the correct settings. The base should have a log which can be used for PPK. So the answer to the OP’s original question is YES you can redo it after the fact. The project file only stores the stop and start times of each point you collect, and the pole height. These are all things you can choose when you postprocess.
The “CSV” file extension stands for Comma Separated Values. CSV files are just text files that can be opened in any text editor. While they can be opened and created in any text editor, the real benefit, editing power, and data analyzes comes when opening a CSV file in a spreadsheet program, like Excel.
The PENZD CSV is a CSV file with the comma separated fields being:
Point #, Easting, Northing, Elevation, Description.
A new line in the CSV text file will be created in the above format for every survey position stored in your survey.
If opened in Excel all the point #, Eastings, Northings, etc. will line up in columns where sorting data and apply formulas becomes quite simple.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.
