Dimensional Error on test measures. Reach RS+ & Reach M+

[antonio.alter]

Good morning, everyone,

I have seen some strange behaviour on the Emlid system results doing some performance tests. Just a summary, it is measuring a distance of 2m as 1.3m consistently.

System description:

My system is composed of a Reach RS+ base and a Reach M+ rover.

Test setup:

There are two points on a straight line traced on the ground separated by 2 meters and at the same height (levelled ground). Rover is placed on point one and once it gets a fixed position the result (on xyz) is saved. After that the rover is moved to the other point and it is powered off and on again, the resulting coordinates are saved once it gets a fixed position.

When I have the two xyz positions, the distance between points and height is calculated.

For horizontal distance I use the following formula:

H.Distance = square root of( ((x2-x1)^2) + ((y2-y1)^2))

For vertical distance I use the following formula:

V.Distance = z2-z1

I took 4 measurements, and the results were:

1.291m, 1.293m, 1.302m and 1.287m for horizontal and 1.515, 1.512, 1.520 and 1535m.

I repeated the test the following day and the results were similar.

Base configuration:

The base is place about 20/25 meters form the rover so it (the rover) can be connected directly to the base Wi-Fi-hotspot.

At the start of the tests the base is connected to a Wi-Fi network on which it accesses corrections from an NTRIP server. Once it gets a fixed result, on base mode it calculated the average fix position for 10 minutes and I save this position using the “save coordinates to manual button”. Once this process is done the base is disconnected from the Wifi and its hotspot is turned on. This is the base settings:

The base emits corrections using the TCP protocol configured as a server.

Rover configuration:

The rover is connected to the hotspot created by the base and obtains corrections from it using the TCP protocol, configured as a client.

Vairiations of the test:

Since I wasn’t getting the expected results I tried different configurations, such as:

Using a Wi-Fi router to connect base and rover.

Keep the base connected to the NTRIP server.

Changing the elevation mask to 25 and 35 degrees.

Setting up the rovers as static.

Turning GLONASS on and off.

[lipisoftware]

Wgs84 cartesian coordinate system used?
square root of( ((H.Distance)^2) + ((V.Distance)^2)) = 2.00 m cc.

[Gabriel_C (GCG)]

Considering the difference is consistent with the advertised accuracy, I would posit it has to do with your manual calculation and projections.

[kseniia.suzdaltseva]

Hi Antonio,

Agree with Gabriel: the results of different measurements are pretty close, so the issue looks related to how the coordinates are measured.

As I see, you’re working with the Reach Panel web interface. So, you get LLH related to an ellipsoid. Ellipsoids are typically not aligned with local topography. It means you’re measuring the coordinates using different surfaces, and it can cause a shift in horizontal and vertical coordinates.

I’d suggest trying out our newer ReachView 3 app. It supports projected coordinate systems, so you can get coordinates in meters or feet right away. To ensure data quality, you can collect a local benchmark and compare the result with its known position in the same coordinate system.

[EBE111057 (Bryan Enfinger)]

Great answers Gabriel and Kseniia !

Every interested beginner needs a basic course in historical geodesy/navigation to understand what GNSS is all about.

When I started in the surveying profession before college (early 70’s) it just fascinated me how geodetic marks were established via terrestrial triangulation in the US and worldwide starting in the early 1800’'s through the early 1980’s. What sparked my fascinating was the early triangulation networks in the Himalayas established by the British and of course European networks starting in Germany and Switzerland. Just think of the difficulty hauling hundreds, if not thousands of pounds of scientific equipment up mountain peaks via animal transport ! Triangulation and development of the EDM (electronic distance measuring in the 1950’s) continued well into the 1970’s and 1980’s.

LORAN was established during WWII for military navigation use and fast became the standard in worldwide coastal/aviation navigation when near radio reception.

Thanks to the Russians in 1957, Sputnik was the inspriration for the first truly GNSS, the US Navy TRANSIT system developed in the early 1960’s. This became the foundation of the first sub-decameter (if you had access to precise military codes/receivers) US NAVSTAR military positioning system in the late1960’s to the 1970’s. And of course, the the Russians developed their GLONASS system parallel along the same time line as the US. And the rest followed i.e., GALILEO (European), BEIDOU (China), QZSS (Japan) and IRNSS (India).

There are many books and online sources even a beginning novice can read/research/understand concerning this subject. GNSS is not the only methodology in geodesy, there are many not mentioned here.

I’d suggest getting a copy of GEODESY by Wolfgang Torge, first edition publication in 1980. Great basic knowledge. There has since been 4 other editions along with Jürgen Müller, another well known geodesist. But the first is always the best.

I still have the book my dad gave me when first published. It’s the gold standard of GEODESY for land surveyors.

[kseniia.suzdaltseva]

Hi Bryan,

Thanks for sharing such an exciting historical note and a bit of advice on a book!

It’s really helpful to know where the modern geodesy came from to understand better why it works this way. And I was also impressed when I first heard about surveyors’ hard work before the GNSS era. These guys are my heroes