Yeah I hope there is not something dodgy because I have about 5 surveys to process with this unit! Will run some tests.
I have just looked at the Ellipsoidal heights produced and they look ok weirdly, no humps like in the position data…maybe I’m not quite clear what I am looking at with the output in rtkplot
I wonder if precise orbits and clocks would help here?
looks like I’m a couple of hours late. I was going to explain - the processing E, N, U output is not referenced to an earth-like surface, and so when interpreted incorrectly seems to show distortions that get worse the further you are from the base. Earth curvature is ~80mm@1km, ~700mm@3km and ~1900mm@5km, and seems not to be accounted for in the E,N,U output. The vertical reference for this output type seems to be a horizontal plane only, probably tangential to the ellipsoid at the processing base.
L,L,h will take care of earth curvature approximately, and you are left with the geoid over your job area unaccounted for. I don’t output E,N,U anymore because, although I overcame the distortions, it was much easier to apply a geoid correction to L,L,h output and convert straight to grid coords and orthometric heights.
1 Like
@wsurvey thanks for you comment, thats great to know. I was some 40 km from the base during this so it adds up with your info above. Thanks all for input and comments.
I used LLH.
So then the jury is still out on this? @wsurvey Did you mean to say that this is related to ENU calculations inside the RTKLIB software or that it is related to the choice for ENU output vs. LLH, etc.?
The interesting part is the elevation rises going north and lowers with south direction…
Havenst seen this problem before, not sure where to start throubleshoting other then the obvious to run a test on land. With all satelite system enabled
output choice, which would be calced inside RTKpost. so one and the same i suppose.
1 Like
Alright, I was just seeing if you discovered something like if output will still be messed up even if you pick LLH. But apparently not.
That is a good discussion on height issue with GNSS. Yes on a boat you will follow geoid surface + tide + heave. So high frequency needed to filter the heave + tidal reduction + geoid correction. On such a surface there is a significant geoid slope and much visible tide effect.
Only way to work with geoid/ortho altitude is really to start with Llh, Wsurvey is right.
Hi @Pascal_P, Im not sure what you mean I am afraid.
I work exclusively in the ellipsoid, and only move away from it when all RTK post processing is complete.
Still bundling my way through this, and never really quite grasped why those arcs were apparent in the ‘position’ data. The ellipsoidal heights look OK though.
I think Pascal means that one should start with LLH coordinates on WGS84 ellipsoid like you are. Then apply correction/transformation to get your result closer to real sea level.
Anyhow, I was also going to mention that you have some float in your solution. I would expect on the open sea you should have 100% fix. So maybe that fact is hinting to look for some other problem.
Has anyone taken a crack at processing the raw data provided a few posts back?
I would but I don’t have time right now.
Returns 404 when trying to download, so, nop 
Sorry! I removed the files from dropbox - habit of keeping things clean, probably not the best move in this case though. Will bang them back tomo.
1 Like
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.