I do not have a CORS account or NTRIP so I generally use AUSpos after a 3-4hr log.
RS2 Base, RS2 Rover for GCP. both running v 28beta1 and RV3 v7.1 (post survey updated to 28.4)
I have an excel to calc the adjustment required AUSpos v the base log/manual LLH
BUT…
After a recent test where I surveyed 5 PM’s, I get an elevation variance virtually equal to the Ant Phase Center of 0.134m. To make the Z approximate the PM’s I have to subtract 134mm from the “Ellips + Ant Height” figure in the Survey.CSV
But this then is not the Z from the ‘here-shot observation’ please see excel screen shots
I suspect I am interpreting how the survey CSV treats the terms Ellipsoid, Ant Height with respect to the APC.
Or my excel is simply flawed. Where am I going wrong?
Secondly
I use Teodrone to Geotag the images. The process asks for the Base height and must be to the APC. Am I correct in submitting Auspos Ellip figure + Ant measured height + 134mm??? in this case Auspos ellspoid 99.088m + 1.817 + 0.134 =101.039
I’m looking forward to your Excel spreadsheets with all these calculations. It helps analyze this data better.
There can be two cases. When you set the AUSPOS preset in the logging tab, there is a toggle Use antenna height. If you switch it on, you obtain ellipsoidal height of the surface point. If you switch off, you obtain the ellipsoidal height of the antenna reference point.
In the first case, you need to input in the Height tab ellipsoidal height 99.088 m from AUSPOS. ReachView 3 adds measured antenna height 1.817 and 0.134 APC offset, and finally calculates Base ellipsoidal height.
In the second case, you don’t need to add measured antenna height cause it’s already included in the AUSPOS ellipsoidal height value. You can input zero in the Height tab. APC offset is added automatically as well as in the previous case. Please note that it will be quite hard to use this point again since it’s in the air not on the surface.
I’d recommend you record the ellipsoidal height of the surface point since it can be fixed on the Earth’s surface. You can use it once more for the new flights or recalculation if something went wrong.
I will always want to find the ground mark point, for the reasons you mentioned such as a later visit.
You say input the Auspos height but this is not known on a new site/log. Do you mean the the 2-5min height observation when setting up on a new random spot?
Is the 2-5min observation height the raw height i.e the air (gps sensor plane)? OR is it the ground =air - Ant height - APC?
Is the RINEX header height value the ground or air?
In the test data supplied, to be clear, all points were over PMs for confirmation purposes.
Ideally I am trying to see the/your maths use to correct my RS2 Base to the PM 78754 (GDA94 MGA56 -32.3766691, 152.503661 AHD 71.681 Ellip 99.149) using the Auspos report.
And
theRS2 Rover shots to the PMs in the spreadsheet (listed in green, bottom centre “PM/SS, Aeropoint or Historical”)
Note the Auspos 3hr log over PM78754 has a height variance of -0.061m
Super Ideally Emlid Studio would do most of this without my spreadsheet
Im in Australia hence the time diff in replies, sorry
Troy
No, let me explain my suggestion a bit. I didn’t consider that you could start with the survey without waiting for the end of recording the log for AUSPOS. In this case, you can set the base position with the averaging in single. Then, after you obtain the result from AUSPOS, you need to apply the base coordinates and calculate the shift for all the surveyed points.
If you average in a single mode, the base will have a relative accuracy. The same will be if you take it from the RINEX header. It means that the elevation accuracy is a meter-level. When you replace it with the precise coordinates from AUSPOS and calculate the base shift, you’ll be able to obtain the absolute accuracy of the dataset.
Alternatively, you can average the base position in a FIX. However, it requires an NTRIP subscription and an Internet connection. Hence it may be unavailable in some mapping areas.
I realize it can be a very useful feature But your spreadsheet corrects RTK coordinates, while Emlid Studio is mostly a PPK software. I’ll discuss your case with the team to find out whether we have plans of implementing any similar feature in our roadmap.
Hi Kirill,
Thanks for getting back. I am going away for a week BUT I definitely NEED to get this sorted out so I’ll get back to you.
What Im trying to solve is pretty basic and regardless of brand, people correct gcp every day. Thats all Im trying to do, get my maths right.
With the data I supplied, pretend none of them are PM’s. Imagine I base log, wander and take gcp. Send the log to Auspos and then need to correct the gcp. No NTRIP or CORS involved. Correcting X&Y is ok. It’s just the Z that is tricking me.
Could you simply write the ‘formula’ to correct Auspos pdf report Ellips / AHD using an RS2 please.
To check the maths on the Z, the answers are in the spreadsheet “PM/SS, Aeropoint or Historical” and the base was setup on the PM in the image attached.
Thank you for your patience! It took a bit more time to check the data from your spreadsheet.
I analyzed it and want to specify some essential moments. What exactly is tricking you in the corrected heights of GCPs? As I see in the Variance: Emlid RS2(postadj) - Aero table, the deviation doesn’t exceed 16 millimeters.
Regarding the correct calculation formula, I’d better suggest taking a look at the whole workflow from scratch. Perform the following steps:
When initiating the base mode, set the antenna height. It allows measuring the ground point height
When you set the logging for AUSPOS, switch on the toggle Use antenna height. It performs the same measuring of the ground point height
Take the base elevation from the output CSV file. If you apply GDA94 / MGA zone 56 + AHD height, you obtain the base elevation converted to the projected coordinate system
Calculate the difference between this base elevation and the height from paragraph 4.3 in the AUSPOS report (MGA Grid, GRS80 Ellipsoid, GDA94). It is the unknown shift
Apply this shift to the elevations taken by the rover
This way you don’t have to do complicated calculations with ellipsoidal heights, AUSPOS geoid, APC, ARP, and so on. I hope it can make your workflow and calculations much easier.
Thanks for the new workflow suggestion Kirill. I think it is your dot point #3 that solves it. In the past, for base height i use the raw figure from my tape measure (grnd to arp)… not the one from the csv.
Is there a way to show what settings were used in the Base unit? such as “use antenna height”, Auspos default. This would be helpful for later fault finding and repeat surveys.
Thanks for the quick reply Kirill,
Do you think I have missed something in your suggested work flow that causes me to subtract the arp & apc in order to get the correct ground mark? I don’t mind doing it but if there is a better way- less chance for error, I would like to know.
Thanks again
Troy
But your spreadsheet corrects RTK coordinates, while Emlid Studio is mostly a PPK software. I’ll discuss your case with the team to find out whether we have plans of implementing any similar feature in our roadmap.
