Today I mapped a 50 acre site and I ran into some issues in Reachview.
I connected the RS2 to a tablet hotspot to try and get NTRIP RTK corrections. The RS2 rover did not get RTK corrections even though it showed connected and the correct mount point in the “Corrections Input” page for NTRIP. I really needed RTK today to save time
After you connect the RS2 Unit to the tablet hotspot, and then turn the hotspot off, you can not connect back to the RS2 using the Reachview app and the RS2 “hotspot”. You can connect back to the RS2 Hotspot but it displays the mac address under the unit name (using the Reachview App on ios) and the app crashes. You have to open Reachview in a browner and use the 192.168.42.1 ip address. After you have connected to it via the browser, you can then use the Reachview App again because it will now show the IP address instead of the mac address. This happened on both my Base and Rover.
I will have to do more testing on RTK via NTRIP to report definitively what is going on there.
I’ve found that I have to enable the hotspot before powering on the Reach RS2, or it will never connect to my hotspot.
An irritation, and hopefully they’ll fix it in future firmware.
starting hotspot before RS2 works every time for me. (nothing else does)
I have also had this happen a few times. I usually cycle the WiFi on my iPhone, and then access ReachView again. That always does the trick for some odd reason.
Even when I had the RS units, I found the best practice was to never have the RS units connect to my office or house wifi (that is always on). I only use my cell or tablet as a hotspot. It is part of the function of the RS units to search for a known hotspot to join. If they do not detect a known hotspot then it will establish it’s own hotspot for you to join (via phone, tablet, or PC) so that you can then use the ReachView app (or browser). That part works fine.
If they wanted to make this very nice and user friendly, then the following changes would be made:
Make it optional to auto join a “known network”. Lets say I have 3 known wifi networks entered in the ReachView app (on RS unit), then it would be very nice to have a user setting to search for known network on bootup or just start up the Local Hotspot on RS unit
Make the timeout of switching from external hotspot to turning on Local Hostpot. Right now it is a very long time. So let’s say the RS unit is connected to a tablet for internet service. And the tablet goes dead and you need to switch to the Local Hotspot on RS unit. It is a very long time before the RS unit will let you connect to the Local hostspot, because there is some set time that it will keep trying to reconnect. It would be nice if this value was user defined (or greatly reduced to say… 60 seconds).
If you are already logging and in a job, you can not just reboot the device to get connected to the Local hotspot. You have to wait it out or turn the external hotspot back on so that you can relog back in and manually tell the RS unit to turn on the Local hotspot.
Hmmm, this wouldn’t work for my use case though.
Kind of a sticky wicket, and I can understand why they’re in the position they’re in with the way it is currently set up.
I think one way to cheat it would be to have this timeout a dependency of the RTK enabled/active status.
So, if RTK is enabled then the timeout would be infinite… (or extremely long)
If RTK is disabled, then the timeout should be short.
This would enable people using the system for RTK to prevent having the headache of losing the link to the phone’s hotspot for corrections due to low battery, but would also provide those acquiring static data with the ability to connect to the RS2 WiFi Access Point should the external network disappear after 15min or so.
geohawk, that is a very good idea! They could probably do both. Meaning there would be a timeout value (reconnect to another source) that is user defined. It would be awesome to have one value for when RTK (incoming NTRIP corrections) is enabled and a second value when it is disabled.
One thing is for sure, there is room for improvement in this one area.
Is there any chance you can share a screenshot/screencast with us? It’s weird that Reach behaves this way.
Usually, if Reach loses the connection with a network during its operation, it’ll be looking for it until it connects back. If you want Reach to go into hotspot mode, you need to enable hotpot in the app.
Do I get it right that the issue with MAC address happens when you manually switch Reach from the client to hotspot mode?
Thanks for these suggestions! The first feature indeed sounds quite useful. As for the other one, we hardly can add this as in a lot of cases it’s important Reach can reconnect to a known network after losing it accidentally. As I said above, you can just manually switch Reach to the hotpot mode in ReachView if needed.
