You can get new image here:
Never saw a good solid fix before with such a compromised view of the sky… so something has changed for the better! More experiments, particularly with moving rover, to follow.
Hi,
i updated my reach modules at the last FW.
Actually i have an access point without internet connection and the modules seem to not start waiting for internet connection (Time Sync step).
Is Thre a workaround for this?
Best,
Stefano
Hi Stefano,
Reach needs to perform time sync either using Internet connection or GPS. If Internet connection is not available you can connect GNSS antenna to the module and it will get time from the satellites.
Hi emlid team,
Thanks for the great work you’re putting into this.
I have two questions for you :
- have you released the source code for the second version ? if not, when do you intend to do so ?
- what is the “max acceleration” parameter, can you point me towards the proxied RTKLIB parameter ? What’s the unit ? m.s-2 ?
Hi @guillaug,
Thank you for your kind words.
The source code for this version is not open. We leave the previous app version open source for everyone.
The units are m/s^2, thank you for noticing, we will add it to the app. The parameters are accelh and accelv.
Hi everyone,
Did some testing today using NTRIP with 2.1.5. Same result as yesterday - the rover gets a good fix, and holds it for a while. I was able to drive about 1km from the base and no problems with the accuracy and holding fix. But, after about 10 minutes the AR validation falls to <2.0 and stays there. Power off the rover and start again and gets the same results - good fix then loses it again. I haven’t been able to test using a non-Reach base yet, may be able to later today.
See attached screenshots showing the time and strong fix, then lost fix. This was with the rover stationary and only 10m from the base.
I can add logs if they would help, just let me know which ones.
Simon
1 Like
same story at me for…
losing fix after x miniutes fix never comes back.
i did investigate rtk.conf today.
minfixsats is set to 4. in tims data sets this is allways set to 3.
today i was unable to get fix with 2.1.5…
Hi, Simon.
Could you share your logs, please?
UPDATE: I connected this afternoon to a commercial reference network over TCP. This would be a Leica base station, and it is approximately 18km from my location. The Reach receiver took about 5-7 minutes to achieve a fix initially, but then held the fix for several hours! I even drove around with it on the roof of my vehicle and didn’t lose fix. It’s still fixed now, even parked close to a building.
Here’s a link to the latest log files. I’m not sure if these include the earlier tests also when I was using the Reach base - anything after approx 1:00pm central time (USA/Canada) would have been on the TCP base, and anything earlier in the day would have been using the Reach base over NTRIP. I had to get the TCP provider to turn on the L1 messages, which they did at around 1:20pm.
Thanks for the help about my screwed up Supplicant.conf file. I tried to connect via ssh to fix it, but ran into the problem that Eric had and then went with other option of reflashing. I had problems reflashing the original 2.x firmware file but sorted it out when I flashed the newer 2.1.3 file. Now Im on 2.1.5 and all is working well.
But I still have a problem. I can now get reach to log on to my local home router, connect to an Ntrip server via the internet, and send mock GPS data to my android tablet. I have my reach mounted on a home-made survey pole and powered via a little usb power bank. So I can go outside, and as long as I stand within a few meters of my apartment, I can see that everything is working: Reach sees satellites, gets correction data from Ntrip server, outputs solved coordinates to app in Tablet. But I want to be able to do this NOT only near my apartment. And so I want to connect to a hotspot on my iPhone. Trying to set this up was what ended up with my reach not being able to connect to any router.
But even now having reflashed my reach, I can’t get it to connect to my iPhone hotspot. I have confirmed that I am typing the name in correctly, confirmed the password, confirmed wpa2 as password type (and tried others) but it won’t connect. When I tell it to connect in reachview it fails and goes into hotspot mode. I can log into the reach hotspot, tell it to log back into my local router, and it does. Then if I change back over and connect to reach view again via my home router, I can command it to switch to the iPhone and it once again fails to connect and restarts hotspot mode. I tried removing my home router info entirely from the Reach and leaving just the iPhone info and then rebooting the Reach, but it still does not connect and goes back to starting its own hotspot.
I was sure I had seen that people HAD used their iPhone in this way (to connect reach to the internet, rather than connecting TO the reach hotspot). Is that not right? Is this not supported? How else would I get Ntrip correction data in the field? Again sorry if this is the wrong thread to ask this, I was not sure if this is a 2.x problem or not (I never tried to connect to my iPhone before in 1.2). Also if it helps, I actually got a new iPhone today, so I actually tried to connect to two different iPhones with the same result.
I don’t know what the answer is to your iPhone hotspot connection problem, but I will confirm that your concept is correct, so keep trying. I connect Reach to the internet for NTRIP corrections via mobile hotspot from android device. Maybe somebody who uses iPhone can comment.I had such problems on earlier v1.2 but now all seems to work well for me.
Could you please share logs which show this happening?
I’ll need base, raw & LLH solution file to analyze the issue.
Great!
I’ve analyzed your logs and real time solution and post-processed one matched exactly 
2 Likes
We’ve tried to reproduce your problem, but without success. Reach connects to my iPhone just fine.
Next week we’ll release new version with significantly reworked Wi-Fi controller, this might fix your issue.
If it doesn’t help please report again and we’ll look for more details.
Here are log files from today, using Reach unit as base over NTRIP. Same happened - got a fix then lost it and couldn’t get it back
Regards
Simon
Uh, I think this needs a bit more explanation please. Is this closed until official release, or closed forever?
Changing licensing is a BIG deal.
2 Likes
Have you seen my previous post: Reach integration with Pixhawk Issues - #4 by rrr6399
It looks like the altitude datum reference and GPS status issues are still there.
Also, I don’t like the approach of not showing any data until its determined that the GPS antenna is in an open area. I do a lot of testing indoors to test communication and such and its nice to see the status of the GPS using the web interface during testing. It also keeps users in the dark until the conditions are met.
Hi,
After the update for the first startup everything worked. After 1 power cycle the gps signal still looks fine, but for some reason the rest won’t work. It doesn’t get a fix. Tried to flash it again, same thing happens. Anything i forgot?
Hi!
From the look of it, your signal reception is way too bad to even get a single solution. You should see at least 5 green satellites.
Hi, Simon!
I’ve analyzed your new logs and could say that sometimes there’s no connection with your NTRIP server.
That’s cause loosing fix as you can see.
P.S. If you’ll send your logs in the future could you log them in LLH mode, please. In that case we could see age of differential and ratio factor for AR validation. Thanks 
1 Like