M2 RTK solution: ReachView LLH vs RTKNAVI DEMO5 data analisys


I am evaluating the M2 receiver as a base and I came across some features that I would like to share.

The methodology was to occupy a landmark of known coordinates and to compare the RMS deviations from RTK positions carried out in relation to three base stations of the RBMC-IP network: (1) distant about 18 km; (2) distant 200 km and (3) distant 500 km from the landmark.

Two sets of results were obtained: (1) generated directly from the receiver by REACHVIEW 2.22.4 (LLH set) and (2) obtained via RTKNAVI (V. DEMO-5 B33-C) on a Windows 10 PC; on the same WIFI network the receiver was on (NAVI set).

Two antennas were used: (1) helical Tersus brand model AX3705 https://www.tersus-gnss.com/product/antenna-ax3705 (TERSUS) and (2) Navspark model GRADE ANTENNA - http: //navspark.mybigcommerce .com / survey-grade-antenna / (GRADE), both capture signals from the GPS (G), GLONASS ® and GALILEO (E) dual frequency systems.

I performed 7 occupations of each antenna in RTK realization with each RBMC base (…) over 1 hour each, at different times with a frequency rate of 1hz; totaling 42 occupations and more than 350,000 RTK solution points.

For each occupation, the RMS dispersion values ​​of the E-W; N-S and U-D vectors were obtained with respect to the known coordinates of the landmark. These values ​​were tabulated and allowed to evaluate the dispersion of the solutions obtained in each processing, generating 84 sets of position variation data, 42 LLH and another 42 NAVI.

What is striking is the difference between the quality of the positioning of LLH results compared to NAVI: on average, the RMS deviation obtained by direct processing at the receiver (LLH) is about twice as large as that of the NAVI set, obtained on the PC (…) and for the shortest base distance (about 18km), the effect is much more noticeable!

The figure below shows the three-dimensional averages of the RMS dispersions of the various surveys in relation to the base distances. The diameters of the circumferences indicate the standard deviation of the averages.


Regardless of the antenna (TERSUS or GRADE) the LLH results (in red) are worse than those obtained in NAVI processing (in green).

For the base distance of 500 km the difference is less noticeable, indicating that similar results can be obtained with the LLH or NAVI set (…) while for a distance of 18km, if only using the LLH data, double error is obtained than if using a PC with RTKNAVI.

The same strategy is being used to evaluate M+ receivers and first REACH module; with single frequency antennas.

Preliminary data indicate that the difference, in single frequency receivers, is no more than 10% and without a trend (there are times when the LLH set is better and others when the best is NAVI … indicating that the difference can be caused by other reasons: satellite geometry, antenna quality, etc …)

My intention would be to use M2 without the need for a PC - generating RTK solutions directly from Reach View (LLH) … but given the results, it seems that I will need to change my intentions!

I hope that the next versions of Reach View can better handle RTK solutions and generate more accurate data.

A few questions:

  • Did you use static or Kinematic mode?
  • How does this compare with the spec of Reach Units (as posted above)?
  • How do you ensure that the sats seen by each test are consistent?
  • What was environment like? Clear horizon? Close to buildings? Etc?

I used static mode for LLH and NAVI solution.
Here the parameters used: (the oriniginal extention is .conf, I renamed to .pos and erased my username/passwords from RBMC-IP system to upload here)


The results shows a low compatibility with the specs - the study was to verify the capability of the M2 to obtain RTK solution. The best solution is with PPK.

The reason why I repeated 7 times the test with each antenna/base: eliminate the efect of satelite geometry, getting an averange data.

The environment was not too good for ‘best performance’ of position quality - but it inpact both solutions (LLH and NAVI), once the data is the same for both.

Here a photo of the spot (on a window sill of my house)

So in other words, part of the sky was blocked by the window sill of the building ? That makes great sense…

All USA CORS have open sky, no obstructions… How can you compare apples to apples, when you are comparing oranges to nuts ?

Also 500km is stretching it a bit too far, M2 specs are 60km. You also need to do the math on the positioning specs shown above.

I think this test is a slap in the face of EMLID, when a major part of the sky is obstructed and you claim it doesn’t meet their specs.


What I am comparing is the ability of the ReachView and DEMO5 to solve RTK schemas.

Maybe ReachView is apple and DEMO5 is nuts… but I am comparing the RTK solutions (all limons), from the same constelation and same issues coused by the lack of good positon quality!

The variability of the base distance is to ensure if the effect is present in all ranges - it is more sensible in short range… what is a bad thing to those that works with RTK - no PPK.

I hope EMLID can see these data effects and implement a better RTK solution on the ReachView for M2 - the obstructed sky data was the same for REACHVIEW and for DEMO5 … and DEMO5 slaped REACHVIEW for good!

My intention is get the best RTK solution with my receiver… and, for now, it is using a PC and DEMO5 installed on

I’d like to use only the ReachView solution (less equipment on the field), so I posted this case of study to show EMLID’s community that this issue happens… hopping that EMLID developer people could see a solution for it.

The aim was not show the accuracy of the data (it is bad, for many reasons) but show that on REACHVIEW is worst.

Hi all,

Thanks for such a discussion and everyone’s input.

@fabio_lobo Interesting tests you conducted! Any chance we can get access to dataset recorded for the base station 18 km away? Also, could you clarify (I might have missed it) what vertical axis units are - meters, centimeters?

I am afraid 210 and 500 km are indeed too big baselines to draw conclusions about the performance of RTK receiver.


@dmitriy.ershov the tests reached who I hoped!
Thank’s for seen this!

I cannot guarantee that this behavior is exclusive to my receiver, as I don’t have another one on hand! I have got mine on the last March.

On this graphic, Y axis is in meters

Here are the LLH and POS data from the 18 km base (RTK NTRIP realization with IBGE’S CCEU BASE STATION).Descritivo_CEEU.pdf (12.5 KB)

M2_CEEU_EMLID.zip (1.4 MB)

The coordinates from my occupation point are (LLH):
-3.74612765584222; -38.5305347634482; 52.285

Hope to hear some good news on the next reachview version for M2!!!

A closer look on the 18km base RTK solution (values are in meters).

It seems that the GRADE antenna is a better choice over TERSUS.

I will repeat the 7 tests schema with a brand new antenna I’v got today: Tallysman TW1889.
As soon as I get some results, I’ll send to the community.

1 Like

Sorry I am missing something.
How can be the 3DRMS values of an RTK solution on a base line of 18km are in 1-3 meters?
At first I thought that it was cm.
Can you explain this please?

The principal issue maybe the lack of good satelite reception, once my occupation spot is at a window sill of my house.

These tests were done to emphasize the difference between the LLH and NAVI RTK solution results.

In this case, it is worth to see the difference using GRADE and TERSUS antenna - the GRADE one seems to have better results.

Although the satellite constellations are from different moments, the amount of tests (7 occupations of 1 hour each) allow us to obtain an average RMS value (orange graph) and infer that one antenna has better results than the other.

That was not what I was asking.
Maybe you refer to Single solution and not RTK?
In RTK the RMS values should be in cm level not meter level.

These are the RTK solution 3D RMS… they are in meters.

Good results comes with good satellite reception - in my case, it is not a good result (no good satellite reception).

So, we have got meter RMS!

And I’m not looking for a good position result - I am testing the capability of the REACHVIEW and the RTKNAVI to get RTK (any) results… even in meter discrepancy.

To highlight the lack of quality caused by the occupation position, I did the PPK processing of one of the tests with the same base, 18 km away.

The PPK quality is admittedly better than RTK and, even so, it got a discrepancy in the range of a few tens of centimeters, far above what would be expected for a short base differential positioning.

In the figure below the PPK data is marked in yellow and the RTK data is in blue.

The fact is that my RMS result is comparing the RTK coordinate with a known data.
In this case, RMS is a measure of accuracy.

If I was comparing the RTK result with it self, then I would get a centimeter or better discrepancy.
In this case, the RMS is a mesure os precision.

So you have a known point XYZ referenced to some coordinate system and you occupy this point with RTK using some Base station 18km far away. And the results you get DX,DY,DZ from the known point values are?
The Base station coordinates are in the same system of the known point you occupy?
In my country there are grid files which are needed to convert the coordinates of the occupied point and the expected difference from the published coords is within 10cm.
I don’t know if I am not getting what you are trying to do correctly…

The issue is between reachview and rtknavi.

LLH data (reachview solution) is far worst than the rtknavi!

Hmm ok… meters…! I also thought it was in centimeters…

If you cannot even get a solid fix with an M2 at 18 km baseline, your reception environment just isn’t good enough for these kind of things, sorry.

The difference you see is probably because RTKnavi and your M2 are configured differently in terms SNR mask etc.

Don’t be sory at all!
The test is regardless to the absolut position… it is a comparation of rtknavi and reachview to obtain RTK result…

The point is extataly this… as we can not set these parameters on reachview, the hope is that EMLID’s professional peaple, such as @dmitriy.ershov, can see this behavior and improove it for us…

On RTKNAVI I used the setup posted here:

The oriniginal extention is .conf, I renamed to .pos and erased my username/passwords from RBMC-IP system to upload here.

You can see that the setup is a ‘standart’ one: Elevation 15 degrees, Fix and hold amiguity, min ratio 3.0… nothing crazy!

But with your challenged reception environment, I am not sure what you are trying to prove? Why bother with non-fixed solutions at all?