Just updated the topic to include v2.2.1 fixes!
4 Likes
Nice, fast update with no problems and both devices are starting now in the same time.
Looking forward to test it and compare it to our Trimble RTK GPS next week.
1 Like
I’ve seen the GPS stop responding after awhile when connected to the Pixhawk. Cycling power fixes it. The WiFi connection drops as well. Any ideas? (The Pixhawk sends out a message that the GPS 2 is not responding and Reach View disconnects.) I’m running Arducopter 3.4.4 BTW. Latest stable build.)
I’m experiencing some odd networking issues - of course they could be all due to my local network, but I’ve not noticed this with v2.1.6: ReachView fine when starting up, but after a few hours I find it unresponsive. My rover does not come up (it’s connected to a router about 1m away from it). Ping times long:
PING reachbase1.local (192.168.0.14): 56 data bytes
64 bytes from 192.168.0.14: icmp_seq=0 ttl=64 time=330.364 ms
64 bytes from 192.168.0.14: icmp_seq=1 ttl=64 time=157.475 ms
64 bytes from 192.168.0.14: icmp_seq=2 ttl=64 time=447.042 ms
64 bytes from 192.168.0.14: icmp_seq=3 ttl=64 time=365.977 ms
64 bytes from 192.168.0.14: icmp_seq=4 ttl=64 time=219.113 ms
I power cycle it, ReachView comes up fine again, and ping times more reasonable:
PING reachbase1.local (192.168.0.14): 56 data bytes
64 bytes from 192.168.0.14: icmp_seq=0 ttl=64 time=9.710 ms
64 bytes from 192.168.0.14: icmp_seq=1 ttl=64 time=7.761 ms
64 bytes from 192.168.0.14: icmp_seq=2 ttl=64 time=21.443 ms
64 bytes from 192.168.0.14: icmp_seq=3 ttl=64 time=21.765 ms
64 bytes from 192.168.0.14: icmp_seq=4 ttl=64 time=17.067 ms
64 bytes from 192.168.0.14: icmp_seq=5 ttl=64 time=8.792 ms
(On boot I’ve also occasionally had Reaches create a hotspot needlessly… and then demand a WPA2 password to log into the hotspot?!? Again, a few restarts and I get them back onto the network!)
Clearly could be something to do with my network setup, but was wondering if others have seen similar?
Hi!
Interesting problem. Can you check whether Reach reboots when this happens? Is there a chance this is a power issue?
Ping times do not matter as long as Reach answers the calls. What are the leds showing?
LEDs away end up green. I don’t think it is a power issue: I did experience a power issue with the rover when connected to a Raspberry Pi3 that various other devices attached (camera, 5GHz wifi dongle, M8U evaluation kit) so I switched to delivering the solution via tcp, not USB, and powered it from a reliable alternative supply. I guess that switch is something that is new, and with several other parameters changing I can’t be sure that it is unrelated to the Reach software. The hotspot asking a password is an odd one - Not something you’ve changed?
That’s good.
Sorry for the confusion, this question about power was addressed to another comment.
I don’t think there is a problem here.
No, it’s always been this way. The hotspot password is emlidreach.
Regarding your issue in general, if your router has an option to create a separate 2.4GHz-only network, you should try that. That might help!
1 Like
SSH into reach and run “top” to see if any of the processes are hogging resources.
Just happened again. It looks like the Reach rebooted since it went offline (network disconnected) temporarily and eventually came back.
Update went fine to 2.2.1. Feature requests from other thread:
- GST NMEA string
- Control NMEA string selectively including frequency (Hz) - GGA on at 5 Hz, GSV on at 1 Hz for example
- Recall past NTRIP providers in NTRIP selection dropdown
- Audible tone when solution type changes: Losing fix or gaining fix, for example
1 Like
Hello all,
Upgraded to beta v2.2.1–
More details later. First test. All float in Kinematic on ReachView. However, bad skyview. Both Rover and Base meters away from row of tall pine trees. Much better response than previous versions. ReachView Float plot within decimeters of post-processing FIX track. I loosened filtering (not AR Ratio) on post-processing. Adding SBAS to Ephemeris helped and, surprisingly, TIDE improved FIX as I am within 10 miles of the Pacific Ocean.
Next test-- Be fair to upgrade. Do open sky tests. The satellite visibility plots had considerable cycle slips on all satellites (both Rover and Base)on my first test. My initial response is quite positive. ReachView appears to respond as I expect it should.
I hope to have more good news to report after the next test. Looking forward to other reports.
Richard
Ah, I must have forgotten that. However… it’s not accepting emlidreach either. However, a couple of power cycles (and sacrificing a chicken, muttering a few incantations etc) and normal connection to wifi resumes. Could be some noise source in my office or just bad karma… I bet after the end of the test days with the client it reverts to behaving itself perfectly! 
@fraser Modern phones are trying to act smart by checking if the hotspot has internet connection and refusing to connect if fallback to 3g/4g is available. Maybe you have experiencing that?
I tested 2.2.1 on my other copter with a good WiFi connection and I’m not seeing the issue. Does the Reach reboot if it loses the WiFi connection and has to switch to a hotspot mode? I’ll let you know what we find out. The WiFi was weak where we were testing.
Comparison of beta v2.2.1 Reach vs Post-Processing-- I ran previous tests on Static mode. Reach never had FIX and AR Ratio appeared as consistently at 0. In post-processing, I threw out 12 satellites between Rover and Base as potential problems and got somewhere near 60 percent fixes. Almost all satellites were low elevations.
I plotted Reach solution minus post-processed solution. Although, in this test, Reach never showed FIX, the the difference between Reach and post-processing was less than about 10 cm after 1 hour at 20+ meters baseline. Data appeared to be converging toward agreement between Reach and post-processing. As precise STATIC L1 surveys are required by some agencies to use a minimum of 4 hours and recommended to be 24hours, I think this looks good to me.
I have not gotten more into open sky tests. In the city, a lot of the open-sky locations are in the middle of street intersections. I’m not too keen on those locations. I hope to find some better locations for testing.
Conclusion: Looks like this will do the job. The plot shows if you have glitches. I did not see any. You can watch the solution converge.
Igor, undoubtedly connecting to the iPhone is a black art, but that’s a separate issue. What I’m getting now is failing to connect to my office network. But of course this could be to local network issues - I’m scratching my head to work out if something else has changed, but there is nothing that stands out that should have an impact on wifi.
@fraser Most common issue with wi-fi would be DHCP. If there is a custom config on the router it might not give an IP address to Reach. Does Reach act like it is connected (not creating AP), but the app is not accessible? That would be a clear symptom.
Hi Coby: Nothing obvious on Top:
Mem: 133336K used, 849700K free, 0K shrd, 3264K buff, 50784K cached
CPU: 7% usr 3% sys 0% nic 88% idle 0% io 0% irq 0% sirq
Load average: 0.23 0.22 0.23 2/118 24494
but ping times up at 300+ms and failing to connect to the web interface. Power cycle and ping down to 10-15ms and web interface connects first time.
Clearly could be my local network… but I’ve not changed any router or access point settings for ages. I guess I’ll try power cycling the router and access points. Good news is that things work for a while after rebooting, so should not have an impact on tomorrow’s test day.
F.