Hi, after a few first problems i could measure with the rs+.
i use the ntrip sapos-service in germany and want to test the accuracy of the rs+.
i have an reference point with very good coordinates (better +/- 3cm). after testing i can say, that the rs+ with sapos could reach +/- 2cm accuracy in the location coordinates, but in the elevation there is a deviation from more than 0,5m. i know that the elevation is not so easy for gnss but this is too much. in the projekt i use the following coordinate system: ETRS89/UTM zone 32N + DHHN2016 height (EPSG: 25832 + EPSG:7837). Here i send my three measurements on the reference point.
Hi,
i thought so too that this could be the problem. but i checked, and sapos uses
EPSG:25832 and EPSG:7837 (DHHN2016): SAPOS-Daten (geoportal-bw.de)
so the problem should be elsewere.
the elevation coordinate of the reference point is in EPSG:5783 (DHHN92).
there should be maximal 10cm difference between DHHN92 and DHHN2016 Transformation - HOETRA2016 (nrw.de)
i don´t think that this is the problem.
is it possible that the dhhn2016 in the emlid software is not so accurate?
What do you need to know how my environment looks like?
It is possible, but probably not very likely. However, you could check by running a project in WGS84+elipsoid and manually converting through know methods to your system.
Images from the ground would be helpful, but I donât think this is the problem. Your RMS would be larger and your fix not as stable then.
Hi Kseniia,
I think SAPOS uses the GCG2016 to transmits ellipsoidal heights to DHHN2016.
I found the following in one of the SAPOS News:
âThe new official height reference frame DHHN2016 (height status 170) is transmitted in SAPOSÂŽ via RTCM 3.1 as DE_DHHN2016_NH. The necessary transformation information is integrated in the specially provided messages 1021 and 1023 of the RTCM and is given free of charge.â
and
âIf the rover can process the transformation messages 1021 and 1023, an evaluation is only possible after activation in the rover.
If there is no activation in the rover, ellipsoidal heights will continue to be generated above the GRS80 (storage ETRS89, height status 310).â
I understand that if the rover can evaluate these messages, SAPOS can deliver the DHHN2016 heights directly.
If I understand correctly, Reach RS+ gets ellipsoidal heights in ETRS89 from SAPOS. So, it should calculate coordinates in ETRS89/UTM zone 32N + DHHN2016 height fine.
May I ask you to attach a CSV file with points you collected with Reach and a file with known point coordinates in DHHN92? It will help me to take a closer look at the data and check what might be wrong.
all coordinates are in ETRS89/UTM, EPSG:25832, the elevation from the reference points are in DHHN92 and from the collected points in DHHN2016 (there should be a difference from max.10cm).
I did an test with the RS2 on a GPS âControl Pointâ in Stuttgart. The RechView3 Settings were as followed:
HZ: EPSG 25832 (ETRS89 / UTM 32)
VC: EPSG 7837 (DHHN2016)
I did use SAPOS-BW
Unfortunately the control point had only on decimal place in height and had no information about the EPSG.
But the height difference were between +/-5 cm
Atleast here, the height information shouldnât be wrong.
You referred to a SAPOS-BW Homepage, is your SAPOS Profile from Baden-WĂźrttemberg or from Niedersachsen? I am not sure if the horizontal coordinates would be within +/-2cm if you use such a large base for your correction. (In your added table you have a basline of about 3665 m so this shouldnât be the problem)
Is VP_G04_P (Vergleichspunkte) the same as VP3_VP (Testprojekt2), they have atleast very similar coordinates.
And a stupid question in the end. Was your antenna height set with the correct height?
In your table it says 1.886, which means with 65 mm less for the antenna mount point you had the ârodâ at 1,821m? This seems to me a little uncommon with a rod.
1,8 m + 0,065 m = 1,865 m, so your adapter is 2,1 cm? If not this might be a reason for your height difference.
In ReachView 3 it shows you how it sets the antenna height with the offset and the rod length.
This might be a reason.
I canât imagine anything else, except a transformation problem within ReachView
I had similar problems here in Austria. Iâm using Carlson SurvPC and there was the wrong Geoid referenced. There must be used a Geoid with the correct Undulation.
As I can see from the data you sent, there is a difference in the LLH of the known and collected points. So, it looks like the shift appeared before the transformation to DHHN2016.
Is there a chance you can provide the position, raw data, and base correction logs from this survey? It would help me to evaluate the data quality to check if it could cause the shift.
Hi, i changed my RS+ to a RS2, so I canât reach the raw data anymore, sorry. In the beginning of the week I made some last tests on really good reference points in Hessen, here I didnât have any problems with the elevation. Now I think that my reference points in Niedersachsen are not so good and the weather in that campaign where really bad for a single frequency GPS.
During these tests i had a reproducible error which i find very interesting. If I connect the rs + to my cell phone and the NTRIP server while Iâm still in the building and then go out to the reference point in the activated state, I always have a meter error in the right and high quality. That was reproducible. After I established the connection on the point (not in the building), the error was gone.
Could you please clarify how did you collect the point when you face a meter error? If the receiver averaged its position, when was the averaging started?
Also, it would be of help if you can check whether you face the same issue with your Reach RS2 receiver.
