Isn’t that the “I am too busy driving with square wheels, so I can’t be bothered changing to round wheels”-approach? 
Your accuracy will change depending on the local condition, and thus depending on the job-site, so the check-in at 1 benchmark 1 time doesn’t really prove much ?
Thank you so far…
Not a square wheel at all. It was just initial testing. It performed very well as far as I was concerned for my application. We are not land surveyors nor do we intend to do so.
I have been running Trimble Agricultural GPS since 2009 without issue. Recently started testing Emlid RS2 for my application.
We normally run a base in the field we are working in. Technically, we only need height corrections. It is controlling grade of the machinery. Lat/Lon are nice for mapping after but not truly needed during application.
The Trimble system incorportates a benchmark which about the only time you use it is if you are running off a different base station. It will automatically make the difference in base 1 to base 2 match.
Hi @Nordstern,
As Christian said, it seems that the vertical datum from the NTRIP casters and ReachView 3 doesn’t match. Please check that the NTRIP base’s vertical datum is WGS84. I haven’t found if the BKG and SAPOS use non-WGS84 vertical datum, but if so, it may be the cause of the issue.
It’d be great if you can comment if ReachView 3 works fine with EUREF data. The raw base and rover logs from the point may be of help too.
1 Like
Hi @Nordstern, this station is coordinated in ITRF2014 and the survey marker is in ETRS89, this is why you see the difference. From the initial screenshot it looks like not only the verticals are wrong but also horizontals, which points at a datum shift issue.
However, you should not see this error with SAPOS high precision service and it has been tested many times by other users in Germany, so if you keep getting the same error with SAPOS then it is really strange. In that case I’d make a check on a different monument.
1 Like
Thank you for your research. It is planned to make another survey to this point within the next few days. This time with SAPOS HEPS and RTK2go.
3 Likes
According to the geocentric coordinates published by EUREF, ellipsoidal height of WARN00DEU is 50.721 in ETRS89 and 50.741 in ITRF2014.
Furthermore, as ETRS89 is (afaik) the official datum for Germany, wouldn’t it be strange that an NTRIP service for surveyors will send coordinates in another datum realisation ?
Short Info. Today i made another survey. With SAPOS HEPS i was able to archive the right position and height.
RTK2Go was good too (+0,2m). EUREF/IGS WARN00DEU was again at +0,8m.
Unfortunatelly the EMLID Beta Caster did not work for me.
Later this day i will post some more informations.
2 Likes
What were you streaming from Emlid Caster and RTK2GO ?
Hi Nordstern,
have you ever heard about geoidundulation? Ask your surveyor friend.
I had the same problem for a long time, luckily I found the issue is caused in the undulation, what means this is a official correction due to gravity between geoidheight and useheight.
I use Carlson SurvPC and there was the necessity of a correction file.
Good luck
I was mistaken with the Emlid Caster. I thought that it was a correction service (NTRIP). It isn’t, so it couldn’t work.
RTK2Go worked as a NTRIP-Service. I was connected with a station from the Uckermark, nearly 120 km distance.
The geoidundulation is only important if you measure normal heights. In a first step i was hunting for the same ellipsoidal height as the control-point in my city (WGS84/ETRS89). And i succeed. 
Two days at different times in a row a i was able the check the point with a max. difference of 2 cm’s. This time i used the federal SAPOS HEPS.
The next step is to find a combination of android app for my Galaxy Active Tab Pro that can work with a geoid file (GCG2016) to measure NHN2016 heights. Until now, unfortunatelly ReachView 3 isn’t able to do this in my region.
1 Like
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.