I tested my reach in field, there is no obstacles blocking the skyview, see the following figure.
And there are seven satellites with high SNR level (45-50), see the following figure. But my reach still can not reach FIX status, It’s at FLOAT status.
The GPS can reach Float status, it means that my setup is correct. Is there anybody help me figure out this problem?
Thanks a lot
I did have similar issue with nothing but float.
I postprocessed and made the adjustment in rtklib. I went from 17% fix to 82,7% fix.
And most where gain by changing ionospher from sbas to brdc. A major leap from 27% something to over 70% fix.
Timespan i logged was about 35min and the rest of period with float was probable due to buildings nearby.
so, nest time you use reach RTK, use same setting as rtklib. i could change from place to place but worth a go.
There could be many things that lead to not getting a fix. Please post your configuration and log files with raw data, reference and solution.
Are you sure that your Reach had sbas as default setting? This is highly unlikely.
Well, these setting are certainly not what we ship by default and indeed they would affect fix.
Not sure if this was a custom file or default but yes, it made a difference 
Thought i should bring that up, since most of us is hammering with all these settings
Thanks for your reply
Since I’m a new user, I can not attach the log files
I would try GPS only with sbas and ad satellite system one by one. And use those who is visible to you.
-Set filter to combinde, not forward
-Set SNR to 35
-Set glonass integer ambiguity off
-use same Hz on base and rover. And another thing, if you log this and pull it into rtklib for post, you get quicker result on what works and what doesn`t. It actually could take some time before fix is solid.
-and with post you could tell how far of you are with integer ambiguity and if your satellite geometry is bad (high dop values)
-if you have obstacles nearby, increase elvation mask angel
Thanks for the information @TB_RTK. Just to learn and understand about the matter. Could you explain how you determined that this configuration works better and how does each individual setting you mentioned affect the performance?
I am currently experiencing issues even with excellent coverage (almost all green bars) and correction link without gray bar dropouts (through Wifi). I always get FLOAT really fast, but FIX is very unpredictable: sometimes I never get it, other times I get it fast but loose it after take-off (it is mounted on an hexacopter) and I rarely get it back in that case.
What things could be causing this? I am thinking that maybe the corrections that arrive to the rover are too old (Wifi link is long range and may not have enough quality). I posted this issue on a different thread, but I am still curious how other settings could be affecting performance.
Thank you again for your help.
I cant go in detail, i dont know enough to do that.
But after hours of tweaking and adjusting, those setting is what i see make some difference in a positiv way for me, it may not work for you but couldn`t hurt trying. Location may also be a factor.
Old correction data is problem too. Yesterday when i testet a setup on my local wifi, i had stable fix with AR above 100, but dropped to under 10 when i turn on my laptop 10-12m away for this setup. Turning of laptop and AR started to rise again.
Same issue when using phone as hotspot with poor location coverage. I get fix, but takes much longer time if i have much trafic on my phone.
Have you tried your gear away from the copter?
In our latests field tests we had the Base RTK on a 1.7m-high tripod about 50-60 meters away from my GCS, where I have a Wifi Router. The drone is around 10m from the GCS before take-off (and up to 100m away during flight). It seems that the wifi network has enough range because the link is maintained (in fact the Rover shows FLOAT almost the entire time). Maybe at such distances the wifi range is enough to keep the devices inside the network, but does not allow fast enough communications and the corrections arriving are too old. The corrections go from the Base to to the Router in the GCS and then to the Rover.
I don’t know if more powerful (in terms of range) wifi-network would be of help. In the tests where I had everything within 10-15m, it seemed to work fine (on the ground).
I will try to do some testing in 1-2 days (although it takes some time and effort). Hopefully, I will test distances between Base-GCS-Rover as well as the configuration that you mention, @TB_RTK .
If possible, save rover and base log for post work, good info on those logs.
I do have some logs of last week’s testing (in the configuration I mentioned before. The logs are available here: Dropbox - File Deleted - Simplify your life
I am not able (nor have enough experience) to plot it or analyze it with RTKPlot or RTKPost.
I posted it on a different thread and I got this answer from someone at Emlid:
Unstable Fix - modem speed issues? - #6 by igor.vereninov
Here you can see my configuration (the basic, I currently have the advanced settings by default):
Can you see something unusual ?
Hi @TB_RTK, I did some testing today and it was very successful. It was all done with the drone on the ground, but good results nevertheless.
I tried all the parameters that you suggested but none of them seemed to improve the performance at all (in fact, the opposite occurred). I tried back and forth to make sure and finally ended up leaving the values by default.
In real time I was plotting the output in RTKPlot to visualize how all the changes affected the AR and I obtained solid FIX several times with almost no change to FLOAT (a couple of times it did but in half a minute it was back on FIX. I did this connecting RTKPlot using TCP connection to the IP of the Rover Reach (in the same network). I tried to separate the devices (up to 75m from Base RTK to the Wifi Router and then 90m to the drone on the ground). I tried turning off all the systems and then on again and after 1-2 minutes obtained FIX again. I moved the drone with my hands around and made some circles and rectangles to verify with RTKPlot in real-time. No loss of FIX
Overall it was great results. Which makes me very happy, although I still don’t know why the two times that I have gone to do some “real” field testing, the performance was awful even on the ground. The conditions where almost the same and there was no change in configuration.
Here are the logs obtained from the Reach Rover back at the office: Dropbox - Public - Simplify your life . I tried to plot them in RTKPlot but was not able, maybe I am not doing it correctly. Can you visualise them or process them? Are they corrupt?
I can’t wait to try again with the drone flying.
Hi,
glad to hear you got results. Try the same setting over several day, you might find other day hard to get fix.
Your new logs work, your old one didn`t so well.
Here is what i got out of it with not default setting 98,5% fix
With stock default setting i got around 84% fix.
Thank you again for the feedback. I understand that what you get in post processing is the same results I would get real-time with that configuration. Is that correct?
I wasn’t able to plot the logs that I provided using RTKPlot. Are you using RTKPost? Which of the logs I provided did you try? I don’t have much experience using RTKLib tools. I did manage to use RTKPlot in real-time using TCP.
Another thing, I see that reach partitions a single log session in different files. What is the criteria for this? duration? size?
I will post the results from the flying tests (probably beginning of next week).
Yes within the same timespan, that`s how i understand it.
rtkpost yes, i used the newst rov/ref files found under the folder named log2.
If you look at the rtkpost window i posted above you can see the files i used to post process your log.
I found the source of all my problems today… The elevation I was using as reference for the Base in field testing was over Mean Sea Level (MSL). However, the altitude that the REACH is measuring is ellipsoid height. Which at least in my area has a 50m difference.
I actually went to a geodesic point close to my office, for which I have the following coordinates and elevation (ellipsoid):
And the following elevation MSL:
If I use the MSL elevation, AR does not go above 1, and therefore only FLOAT is obtained.
I changed the reference elevation to 711.778m (ellipsoid) and FIX is easily achieved within 1 minute. I even took off with the drone and the AR was improved! no loss of FIX. I was still using the default configuration and saw no issues. I placed the RTK Rover antenna right next to the Base, and it measured 711.78m, I lowered exactly 1.2m and it measured 710.58 (amazing accuracy). I changed back to MSL elevation again and AR was at 1 and only FLOAT (and much lower accuracy measured, around 4 meters in altitude).
Maybe I am too inexperienced in this field (although I believe I am making progress), but I am sure that many people may face this issue, because MSL is the typical value I see reported for reference points. For example, the elevation of runways in airports is shown in MSL in the official AIP documents. If my findings are true, it would be great to have this indications in REACH documentation/wiki. Can anyone corroborate that this is true?
What I need to do now is find a way to convert the elevations MSL I have for my reference points in the different fields where I do tests to ellipsoid height. Does anyone have guidance on this?
I’ll share a couple of images of how I placed the Base.
