ReachView v2.22.7 is out for all devices

I totally understand that you test all stable releases vigorously but there are always some outliers that cannot be tested for. In those cases you have left folks high and dry without the ability to roll firmware back to a previous state that worked for them. There may also be issues in stable firmware that you had not found that will pretty much ground the units until you release a fix. Seems quite silly as this could alleviate some issues but emlid seems quite reluctant to listen or care.

I was lead to believe that SSH root access has been taken away after a recent firmware upgrade?

Dmitriy and yourself are both correct:

  1. Yes you can get access IMU data via SSH.
  2. Yes root access is not longer available.

To get access to IMU data, you need to SSH in as a regular user, not as root.

1 Like

Sorry, but the link of “stable version” 2.22.3 is this?


Thank you

Hi Sergio,

This is the link to the Reach RS stable image. May I ask you to clarify why you want to reflash the Reach RS device?

Hi Tatiana,

I have an RS2 with 2.22.2 firmware I wanted to go to 2.22.3 to see if the management of the NTRIP channels is more stable.

Why on the link

is there only version 2.22.2 ?

Hi Sergio,

We’ve just updated the links to the latest v2.22.3 stable image.

However, you don’t need to reflash the receiver to update it. You can just connect Reach to the Internet and follow the instructions from here.

1 Like

Can someone explain what this means?

The radio can broadcast on one of many frequencies. In many countries, only a portion of those available frequencies are allowed to be used without obtaining a license. So, depending on your geographical location, the useable range of frequencies will be different.

e.g. some countries are more permissive at the 868Mhz end of the range and some are more permissive at the 915Mhz end of the range.

Here is an old post about it from a couple of years ago:
How do I change lora frequency? - SOLVED


I propose to redraft the tab ‘Base mode’. If the receiver is not the base, i.e. ‘OFF’, it should not be in this tab active ‘Base coordinates’ and ‘RTCM messages’.

This tab ‘Base mode’ should then be empty.


Hi Ryszard,

Thanks for the valuable suggestion! It will be discussed.

1 Like

A post was split to a new topic: Incorrect baseline for RS+ v2.22.4

Thanks for this update.
I have done a confirmatory test session. I still expect such confirmation from users who also reported this to me.
I attach the survey report. Unfortunately only in Polish, because this external controller has no foreign version.
image image (4.6 KB)
Session made with Reach RTK module, RTN method, data stream: RTN3G_VRS_RTCM32 (GPS + GLO + GAL)

1 Like

I also did an additional test for checking of cycle-slip detection and repair in the new version 2.22.4. For this purpose, at the same point as previously, I briefly interrupted the reception of satellites by covering the antenna by hand. This time, the solution was always ‘fixed’, it gave the same result. However, with a longer break reinitialization, it is sometimes frozen. It can be seen here:

Quality checks can be carried out in many ways. And so, e.g. with teqc.exe:
qc.pdf (74.5 KB)
You can also use the CSRS-PPP report:

raw_202004171629.pdf (920.8 KB)
Or simply do it on the basis of the ‘Land survey report’, where individual results were recorded. (4.5 KB)
From this conclusion that in this version 2.22.4 this problem has probably been optimally solved.
However, there are still cases, already signaled in several threads, freezing the process of initialization and re-initialization. This occurs when the solution ‘float’ remains in a place like this:

Here in this test it is RTK method to the remote 20km reference station so such freezing is justified. Manual parameter change definitely speeds up the re-initialization, for example, a minor change, e.g. in RTK Settings elevation mask by one degree or GLONASS AR mode. I guess this can be done programmatically. This problem did not occur in earlier versions before reflashing so it may be worth returning to that initialization algorithm for one-frequency receivers. Maybe this should to be worked out in the next version.
The test concerns the Reach RTK module.

I include raw data throughout the session: (3.1 MB)


it would be nice to have a refresh button for NTRIP mount point list.

1 Like

and it would be nice if ReachView M+ or M2 could show the number of events marked so that we could compare to the photos taken.

2 posts were split to a new topic: RS+ loses fix every 5 minutes

It can be seen that after the discussion EMLID team left in this new version 2.22.4 active frames for ‘Base coordinates’ and selection of ‘RTCM3 messages’ with inactive base mode. This causes the user to doubt whether it may conflict with the measuring procedure if he only works with the receiver as a rover with NTRIP. Please, dispel these doubts.

1 Like

It would be very good, that when configuring in static only enable the base coordinates and in kinematic that it cancels the entry of the coordinates

‘Rover’ with NTRIP is a ‘rover’ irrelevant or ‘static’ or ‘kinematic’. ‘Base’ is what we get from NTRIP (point or VRS). :slightly_smiling_face:

I am thinking when one does not have ntrip availability and I generate my own ntrip or for when I do PPK and it is not confused between base and rover