Does anyone see anything wrong?
I can get it to work fine with both units talking though the WiFi router at the house.
As a last minute test, I added port forwarding for the base module through port 80 (for HTTP) and was able to access it’s web pages over the internet with the cell phone.
This image shows my settings for the port forwarding for port 80.
I’m trying port 115 for the RTK data because the other higher numbers I tried wouldn’t open and must be blocked by my ISP. I checked my ports here Open Port Check Tool - Test Port Forwarding on Your Router.
No matter what I try, I don’t get the 2nd set of bars for the base satellites. I also tried the Lefebure NTRIP client on the cell phone. I get it to connect to the base but I don’t know how to view the data. I think it needs a Bluetooth receiver to completely work.
I’ve done some more testing and a little learning but still don’t see the correction data at the rover.
I’ve tried more ports and any I pick seem to work. You just have to test them while the base is working otherwise they show up as closed.
I swapped modules around so the base became the rover and vice-versa.
I now see how the Lefebure NTRIP app works. I can get a connection back to the base through the router. It tells you the IP address and port that it has connected to.
So I still have no correction data showing up on the rover.
Theoretically this should be possible. We are trying to figure out the same thing right now, except that in our case both the base station and the rover are on cellular data through smartphone personal hotspots.
Basically there are three potential obstacles for our setup:
Smartphone’s personal hotspot may perform some firewalling.
Smartphone’s personal hotspot definitely performs NAT, so some port forwarding must occur on the smartphone that has the base station’s tcpserver.
Cellular data provider may perform some firewalling or NATing too, so you may have to negotiate with them to fix it.
In your case, the base station is entirely under your control, and you appear to have it configured properly, so it is most likely that 3) is your problem. 2) does not apply to you since the rover doesn’t act as a server. 1) may affect you if the smartphone itself is firewalling traffic somehow.
I expect that the final solution for both you and us will be some sort of VPN tunneling to effectively punch through whatever firewall or NATing the cellular data provider is doing. What may end up working is to have each REACH Edison unit set up an outbound SSH tunnel to a central SSH server acting as a middleman.
I am working on using a two-legged SSH tunnel as I described where the two REACH modules’ Edison boards SSH outbound to a central SSH server somewhere on the internet.
The proof of concept works. I am running an Apache webserver on port 9000 for the test:
webserver is at some IP address, let’s say 10.0.2.15, running on port 9000 (this will be the RTK Base)
jump server is always at 192.168.13.33
webclient is at some IP address, let’s say 192.168.2.10 (this will be the RTK Rover)
From webserver to jump server:
ssh -g -l user 192.168.13.33 -R 9000:localhost:9000 -N
From webclient to jump server:
ssh -l user 192.168.13.33 -L 9000:localhost:9000 -N
Now the webclient can wget from localhost:9000 the web page being served by 10.0.2.15:9000.
This is confirmed to work. I only need to figure out how to get it to work on the REACH Edison boards AND make sure outbound SSH always works on cellular data networks (it should always work).
With SSH key authentication, it should be possible to have the REACH Edison boards automatically create the tunnels to the jump server every time they boot, IF it is possible to modify the Edison’s boot scripts.
I don’t have a Reach yet but this solution is tantalizingly close. I want it for GIS data capture running something like ArcGIS on a tablet with the rover. To me the biggest limiting factor at the moment is solid transmission of corrections to the rover in urban areas. The idea of cell phone to cell phone over 3G is the perfect solution. If somebody could solve this I’d buy a set.
I haven’t finished testing the two-leg-to-middleman SSH tunnel solution yet, but it should work. I have tested each leg separately (I have only one smartphone right now), and the data does get to the middleman server.
I was also able to easily set up systemd to automatically start the SSH tunnel at boot time. There are several tutorials out on the web on how to do this on Intel Edison boards.
I’ll update this thread with my findings when I get to borrow a second smartphone and do the final test with a real RTK run using two smartphones, one REACH hanging off of each smartphone.
So far, the only hiccup is that the SSH tunnels will remain open even if the smartphone loses its internet connection, after which time the defunct tunnel is dead. It has to be killed (it is killed automatically by timeout on the server) before another tunnel can be opened. It may be possible to fix this by tweaking the SSH tunnel parameters or by using a reverse SSH tunnel.
It would be utterly awesome to have the REACHView app provide a front-end for starting up an SSH tunnel to any given SSH server so that it is easy for anyone to use this method. Hopefully after I have proven the solution works the devs will take my findings and do exactly that.
I confirm that the two-leg SSH tunnel with a middleman server WORKS to provide RTK between the Base and Rover across the internet, punching through firewalls. However, I have only tested this via regular WiFi-to-cable-modem routers and not via smartphone mobile hotspots.
The commands I gave above to set up the SSH tunnel are correct, except replace the -N with sleep 180 like so:
webserver is at some IP address, let’s say 10.0.2.15, running on port 9000 (this will be the RTK Base)
jump server is always at 192.168.13.33
webclient is at some IP address, let’s say 192.168.2.10 (this will be the RTK Rover)
From webserver to jump server:
ssh -g -l user 192.168.13.33 -R 9000:localhost:9000 sleep 180
From webclient to jump server:
ssh -l user 192.168.13.33 -L 9000:localhost:9000 sleep 180
The change to sleep 90 is to help the SSH tunnel shut down on the server if and when the REACH is shut off. I am asking for a new feature: the ability to run a graceful shutdown script OR a script by pressing a button in the REACHView UI so that we can tear down the SSH tunnel gracefully.
Currently, the biggest challenge to this idea of using SSH tunnels is that the tunnels can freeze/lock-up and need to be restarted when that occurs. I know there are solutions out there like autossh and such that I can research to improve this solution.
Currently using two TP-LINK MR3040’s with GSM/LTE modems to the outside world, and they each are hotspots with separate WiFi networks, and fixed 192.x.x.x address for each Reach.
So, to setup and test what you have outlined above should be pretty straight forward, and will let you know how this all works out.
@robins Did you consider publishing your correction data to a public NTRIP caster? Then connect your rover to the NTRIP caster rather than a direct TCP to your receiver at your house. This way you can avoid the routing and firewall complexities and risks hopefully. I’m interested in doing the same thing. Here’s one such caster: http://rtk2go.com
