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:
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?
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 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
default 192.168.0.1 0.0.0.0 UG 0 0 0 enp0s17u1
192.168.0.0 * 255.255.255.0 U 0 0 0 enp0s17u1
192.168.0.1 * 255.255.255.255 UH 0 0 0 enp0s17u1
192.168.1.0 * 255.255.255.0 U 0 0 0 wlan0
192.168.2.0 * 255.255.255.0 U 0 0 0 usb0
So I remove the WLAN gateway manually route del default gw 192.168.1.1 and check if I can ping anything over the 192.168.0.1 gateway which didn’t work. So I run a nmap search on the 192.168.0.0/24 network address and it turn out that the lte modem stick has the IP 192.168.0.2. As soon I added that address as standard gateway (route add default gw 192.168.0.2 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
0.0.0.0 192.168.0.2 0.0.0.0 UG 0 0 0 enp0s17u1
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 enp0s17u1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s17u1
192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 enp0s17u1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
192.168.2.0 0.0.0.0 255.255.255.0 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 192.168.0.1…
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.
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.
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.
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.
