ReachView 2 beta v2.1.3(and new image)

Hey guys!

We are releasing yet another update to our ReachView 2 beta, v2.1.3.


This is a minor update that contains various fixes mentioned by you or found by us.

  • RCH-329 Disconnect not always working properly
  • RCH-338 Make more informative disconnect notifications
  • RCH-385 Implement NTRIP Server for base mode
  • RCH-394 Display base on the map
  • RCH-358 Base mode: add ability to average float
  • RCH-383 Remember coordinate format after page refresh
  • RCH-386 Fix a bug with map follow feature

Also, we’ve chaged the way satellites are sorted. They are now sorted by name rather than SNR. This will make them stop from jumping around so much.


As usual, you can update using our new in-built updater. You can find it by going to the gear tab and looking for a link that says check for updates.

By the way, those of you updating from v2.1.2 will be able to check out our new cool update progress bar.

New image

We’ve also received numerous requests for an image with the newer app version, so here it is. If you’ve experienced any issues flashing our previous beta with Intel’s flashing tool, they should be solved with this one.

Our progress

At the moment two issues seem to be bugging our users the most: app behavior in firefox and the missing time marks.

We are working on firefox support, it takes time, and in the meanwhile you have the option to use Chrome and Safari.

The missing time marks will be addressed fairly soon with new patched RTKLIB apps and new instructions. So, you might want to keep your raw logs with the time marks.

That’s it!

Thanks everyone for the active feedback!

Best regards,
Emlid team



for wifi:

i have set up 3 different wifi connections

i think if the first don´t work reach switches to hotspot mode.

what is the User ID for NTRIP server?

Did the password change for the reach account when sshing into the device? The “reach” password isn’t working for me.

I flashed both my Reach devices with version 2.1,3 of the firmware. I was able to get past the first screen of the ReachView Web app after adding the WiFi connection, but not on the second. The second device’s lights were green, but could never get to to the main ReachView screen.

I’d recommend that the users not be required to setup a WiFi connection to use the ReachView application since it can be run locally with Ethernet over USB or by directly connecting to the device’s access point. It looks like there may be a requirement to get timing information from the GPS satellite as well before allowing access to the main screen. I don’t think that should be a requirement either, especially when there are problems. How are users supposed to troubleshoot the issues?

Imagine trying to configure and use the Reach without any WiFi access to the Internet…

Another use case is trying to configure and use the device using a hotel’s WiFi with a router that forces you to type in your name and room number in a web page before allowing access to the Internet. I had to setup my own access point that was connected via Ethernet to work around the authentication requirements.

Ah, Firefox, hope that will solve my problems!
Is there another alternative browser other than chrome? I don’t want to use chrome.

Reach will try all networks that it knows before switching to hotspot.

NTRIP Server feature is meant to send corrections to NTRIP Caster. It does not allow for direct device to device communication, data needs to go through a caster. Here is more info.

root / emlidreach

Could you please let us know more about the issue? If you could list all your steps with screenshots and IP’s that you enter etc… it will help us troubleshoot. Every detail is important.

Thank you for your feedback about the constraints and I feel your pain about connecting to Wi-Fi in a hotel. We will consider it for future updates.

1 Like

How about Chromium? :slight_smile:


Here is the screen after specifying my local NetGear wireless hub and the resulting output from ifconfig on the Reach device. Are there any diagnostics I can run to help figure out the problem? The status light on the Reach is solid green BTW. Notice that wlan0 doesn’t show up in the list of network interfaces.

root@reach:~# ifconfig
lo Link encap:Local Loopback
inet addr: Mask:
inet6 addr: ::1/128 Scope:Host
RX packets:2731 errors:0 dropped:0 overruns:0 frame:0
TX packets:2731 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:207512 (202.6 KiB) TX bytes:207512 (202.6 KiB)

usb0 Link encap:Ethernet HWaddr 02:00:86:58:7f:38
inet addr: Bcast: Mask:
inet6 addr: fe80::86ff:fe58:7f38/64 Scope:Link
RX packets:497 errors:0 dropped:0 overruns:0 frame:0
TX packets:269 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:67537 (65.9 KiB) TX bytes:93240 (91.0 KiB)

Here are the contents of the wpa_supplicant.conf file:

BTW, on the device that did work, I can’t add a new Network interface. The Create button here doesn’t respond:

Very usefull hint, thank you. I will try later wheter that solves the problems!

I Had. The same trouble. Green led and can’t connect to wlan.

login as: root
root@'s password:
root@reach:~# ifconfig
lo        Link encap:Local Loopback
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:120 (120.0 B)  TX bytes:120 (120.0 B)

usb0      Link encap:Ethernet  HWaddr 02:00:86:a8:db:1e
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::86ff:fea8:db1e/64 Scope:Link
          RX packets:312 errors:0 dropped:0 overruns:0 frame:0
          TX packets:92 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:26261 (25.6 KiB)  TX bytes:20086 (19.6 KiB)

wlan0     Link encap:Ethernet  HWaddr 90:b6:86:01:f6:ce
          inet addr:  Bcast:  Mask:
          RX packets:213 errors:0 dropped:38 overruns:0 frame:0
          TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:17496 (17.0 KiB)  TX bytes:3983 (3.8 KiB)

But no Access point…

root@reach:~# ping
PING ( 56 data bytes
64 bytes from seq=0 ttl=64 time=13.386 ms
64 bytes from seq=1 ttl=64 time=3.625 ms
64 bytes from seq=2 ttl=64 time=22.220 ms
64 bytes from seq=3 ttl=64 time=21.903 ms
64 bytes from seq=4 ttl=64 time=10.873 ms
64 bytes from seq=5 ttl=64 time=12.731 ms
64 bytes from seq=6 ttl=64 time=15.877 ms
64 bytes from seq=7 ttl=64 time=19.439 ms
64 bytes from seq=8 ttl=64 time=3.764 ms
  --- ping statistics ---
9 packets transmitted, 9 packets received, 0% packet loss
round-trip min/avg/max = 3.625/13.757/22.220 ms

When I restart hostapd the access point comes up.

root@reach:~# sudo systemctl restart hostapd

but no access to the rooter

root@reach:~# ping
PING ( 56 data bytes
ping: sendto: Network is unreachable

any help appreciate

resolve by doing this :

  1. start reach.
  2. accessing to the reachview interface by the local ip in html browser .
  3. configuring itself -> OK
  4. restarting
  5. On the web interface same ip, make a hotspot from the wifi button. then, the hotspot is created.

Where do I find the NTRIP server feature in 2.1.3?

From the menu on the left hand side select “base mode.” You should see “corrections output.” It looks similar to “corrections input” settings.There will be three options for corrections output, Serial, Ntrip, and TCP. The Ntrip heading contains blanks for Ntrip caster info.Get these settings from your Ntrip caster. This is something you will have to set up and make sure its running.Best of luck!

1 Like

Chromium worked well. I downloaded portable binaries for Windows here: Chromium binaries.

I’m not sure wether the configuration of reach is permanent or whether it is lost every now and then. Got the impression that sometimes onfigurations like stop logging when full or position output change their configuration magically.

It would be nice to have profiles. And automatic logging start after 2 minutes.

I managed to connect via a 433 MHz UART radio. First had problems because correction output as well as position output was via UART. Would be nice if a message would be displayed so that everytime one of them is enabled the other one is disabled.

Got float and fix under weard circumstances behind a window… , Baseline was 40 m eventhough the antennas where 10 cm apart. Precision was 6 cm. So total nonsense data. What is the problem here and how can I trust other results?

Thank you,

1 Like


Thanks for the report!

I can confirm that adding an open network is broken. Will be fixed in the next release.

Hello Hugo,

What you see here makes perfect sense. On the first screenshots you can see Reach has an IP address on the wlan0 interface, so it’s connected to your network and can ping the router.

When you start hostapd Reach creates its own network, so it can’t ping your router.

It’s base mode output