ReachView v2.4.0 - Galileo support

Just two days since our last update, we are back with some new Reach goodness!

ReachView v2.4.0 brings Galileo support for both Reach and Reach RS. You will have 5 additional satellites at your disposition to enhance RTK ambiguity resolution and will be able to send Galileo-based corrections as well.

The update process is a little different from our normal routine:

  • First, update to v2.4.0 the normal way
  • After rebooting, go to the updater url http://your_reach_up/updater like this:

  • You will have a new option - Receiver update

  • Press the blue button, wait for the process to finish, reboot

After this, you are good to go!


  • Added galileo setting to the available GNSS
  • Added 1097 message to the base screen

Bug fixes

  • Fixed a bug with GNSS settings which resulted in the app not being able to turn GLONASS on or off
  • Fixed an erroneous message, which prompted user to connect an antenna on Reach RS

New sats in the status tab

Galileo sats are marked as EXX in our SNR chart.
Never mind the bad SNRs, this Reach RS is standing on a balcony :slight_smile:

Best regards,
Emlid team


Can’t wait to test it! Thanks for this great, long awaited, feature!


you guys are the best!!!

Thanks for the work

Great news!
Works like a charm.
Thank you!

Works great for me too!

Hy Emlid Team

Galileo present also in Italy !

Well Done



It seems like I can’t add the 1097 message to the RTCM3 in the Base mode tab. It think it saves the frequency correctly but the value of the checkbox doesn’t get save. When I refresh the page it is unchecked again. Can anybody confirm that bug?

How to I debug a LTE modem connection? The modem looks correct connected but there is no data stream over it…

EDIT ifconfig returns me the following:

enp0s17u1 Link encap:Ethernet  HWaddr 36:4b:50:b7:ef:2d  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::344b:50ff:feb7:ef2d/64 Scope:Link
          RX packets:44 errors:0 dropped:0 overruns:0 frame:0
          TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3148 (3.0 KiB)  TX bytes:3300 (3.2 KiB)

lo        Link encap:Local Loopback  
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:341176 errors:0 dropped:0 overruns:0 frame:0
          TX packets:341176 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:68554739 (65.3 MiB)  TX bytes:68554739 (65.3 MiB)

usb0      Link encap:Ethernet  HWaddr 02:00:86:04:7f:26  
          inet addr:  Bcast:  Mask:
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 98:f1:70:65:57:81  
          inet addr:  Bcast:  Mask:
          RX packets:50970 errors:0 dropped:0 overruns:0 frame:0
          TX packets:50670 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:5567501 (5.3 MiB)  TX bytes:8584578 (8.1 MiB)

Yes there is a small hiccup there.

After updating to 2.4.0, and when enabling the base mode GALILEO RTCM3 messages for the first time:

  • you check the box to enable, but you don’t get an “Apply” button below,
  • so you also check another box (Antenna type) and the “Apply” button appears,
  • click “Apply”
  • now uncheck the Antenna type message and click “Apply” once more to put it back the way it was

After doing that workaround, now each time you make a change to GALILEO, the “Apply” button will appear.

( @egor.fedorov )


@bide : Your right, that works! Thanks for the workarround.

Okay found a solution though it is a little odd. I check the routing table and it returns the following:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         UG    0      0        0 wlan0
default         UG    0      0        0 enp0s17u1     *        U     0      0        0 enp0s17u1     *      UH    0      0        0 enp0s17u1     *        U     0      0        0 wlan0     *        U     0      0        0 usb0

So I remove the WLAN gateway manually route del default gw and check if I can ping anything over the gateway which didn’t work. So I run a nmap search on the network address and it turn out that the lte modem stick has the IP As soon I added that address as standard gateway (route add default gw enp0s17u1) the connect work and I got a nice stream to my ntrip caster.

Any explanation for that?

ps: my routing table looks now like that:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    0      0        0 enp0s17u1         UG    0      0        0 enp0s17u1   U     0      0        0 enp0s17u1 UH    0      0        0 enp0s17u1   U     0      0        0 wlan0   U     0      0        0 usb0

EDIT Actually it’s enough to just add the new route, it’s not necessary to remove the WLAN gateway, that was just for the testing purpose. I just wonder why a traceroute always start over the ip

Thank you for the GALILEO update!

1 Like

Finally, I can see galileo. Great job, thank you emlid team.

1 Like

I seem to have a problem. I did the upgrade and with a little familiarization I think I had both Rover and Base units where they could record data points. So, the basic software works.

I find myself in the difficult position that my Rover hangs at the software point where the data points are being averaged for the log. It just does not record the data. I can exit this mode and everything works OK otherwise. Next, I try the obvious resort to reload the ReachView 2.4.0 . No problem? No, I am told I am up to date. No more for you…How do I get out of this???

I tried the updater. No help. Survey screen shows number of Rover satellites changing. Coordinates change, but no sigma output.

Set for SINGLE.

In your screenshot, the thin red bar shows “Starting collection…” That should only be displayed for a fraction of a second before a blue countdown timer bar is shown in the same spot. I also see that the “Accept” button is greyed out. Something is getting stuck.

I have 5 Reach / Reach RS updated and all are working fine with Android smartphone browser and Mozilla(~Firefox) PC browser.

I would first try deleting your project, rebooting Reach and try again. Which web browser were you using? Incognito mode?

Close and reopen the project does the trick Edit: Sometimes.
Its a bug i think @egor.fedorov

Edit: Happens with mine. Used autosave in singel mode and it would not start unless i close and then reopen the project.
Edit: it also apears if signals are bad but stil enough to get a solution within the parameters set in autosave mode.
Edit: Did some more testing with another unit. And it seems if you start it up under bad conditions and move it to get better signals / or if booted under good conditions and before it has run for a while and you have set settings for use and open survey and try to save points, it will not save until bad data that is in the loop is out and/or you adjust some RTK settings and reopen survey tab. Then it will save points.

Seems like there is something in the survey tab that has some parameteres running in the background that we dont see and is keeping survey to save if to much bad data has been collected… Or something.
I can reproduce the probleme but also clear it by doing as stated above.

1 Like

I’m not using Incognito mode. I am using Firefox with Android. I will look at Cache problems. Sometimes, these things pop up because there are left over Reach Server Pages and Client App? responds to first reply.

I will do a good housecleaning and try again.

And, need to see if I can learn what Incognito mode does. I think maybe it is Private Browsing mode in Firefox.

I am not sure its a cache issue, as i run into this in incongito mode as well.

1 Like

Guys, thanks for the reports. I am on a vacation this week, but the team working on Reach has confirmed both bugs - the collection start freeze and the apply button not appearing for Galileo.

They are working on a solution for these problems and we will release a fix next week.