Emlid Store Blog Docs
Contacts

RS+ first Test. Problems with elevation measurement

Reach / Reach RS+ / RS2 Getting started
#1

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.

Testprojekt
Testprojekt1688×192 75.9 KB

Has anobody an idea what i can do and where the problem could be?

#3

Are you sure the NTRIP and reference point is within the same system?

What does your environment look like?

#4

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?

#5

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.

#6

Ok,
it’s a really good idea running a wgs84 project. I have a ell.elevation (GRS80) from the reference point, 229.632m.

I will try this tomorrow. Thank you!

The reference Point is concreted in a street. The point is Fix!

Has anyone experience with the DHHN2016 in the emlid software?

#7

Problem: My NTRIP is in ETRS89, I can’t run a WGS84 Project with my NTRIP. Without NTRIP the elevation would be too bad.

#8

Hi Florian,

Could you please clarify whether SAPOS transmits ellipsoidal heights in ETRS89?

#9

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.

2016-12-13_Neuer Raumbezug 2016 im SAPOS NRW.pdf (107.9 KB)

Sorry for my English.

#10

Hi Florian,

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.

#11

Hi,
I could not load a csv file in the community. I hope the screenshots will do it.

here is the list of my reference points:

Vergleichspunkte
Vergleichspunkte694×274 59.2 KB

here are the reference points and the collected points:

Testprojekt2
Testprojekt23666×456 412 KB

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).

#12

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? :smiley:
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.

#13

Hi Marius,
to your Questions:

  1. I use SAPOS-Nds
  2. VP3_VP an VP_G04_3 are identical
  3. I have the „rod“ every time at 1,80m, I also use an adapter to mount the RS+, 1,886m is what the software makes from it

Any idea?

#14

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

#15

Hi Florian,

Thank you for the data! I’ll take a closer look at the coordinates and write you back.

#16

Yes, the adapter is 21,5mm.

image
image750×1334 104 KB

#17

Hi Florian,

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.

Hope this will help you.

#18

Hi Florian,

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.

#19

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.

#20

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.

1 Like