Can’t wait to test it! Thanks for this great, long awaited, feature!
you guys are the best!!!
Thanks for the work
Works like a charm.
Works great for me too!
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…
ifconfig returns me the following:
enp0s17u1 Link encap:Ethernet HWaddr 36:4b:50:b7:ef:2d inet addr:192.168.0.182 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::344b:50ff:feb7:ef2d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 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:127.0.0.1 Mask:255.0.0.0 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:192.168.2.15 Bcast:192.168.2.255 Mask:255.255.255.0 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:192.168.1.58 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 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 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
Thank you for the GALILEO update!
Finally, I can see galileo. Great job, thank you emlid team.
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.
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.
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.
I just gotta say it! Have a great holiday!It really seems like you guys are always working! Hope it’s a relaxing holiday and not a business trip! Отдыхай! Hope you get rested!