I’m not sure how relevant this is, but I said I’d try a test, so here is what I found:
For the past few days, I’ve been testing RTK with the latest ReachView (0.4.5) under an obstructed sky:
- ~80% sky view for base (north 20% blocked by trees)
- ~45% sky view for rover (north 55% blocked by building)
- 15m distance apart
Because of the poor sky condition, take this with grain of salt. I was able to get a fix for a very short time, but nothing lengthly. The details:
Some testing I did was with Reach sending over TCP to let `RTKNAVI.exe` do the processing and `RTKPLOT.exe` do the plotting. In `RTKNAVI.exe`, I could watch the 'ambiguity ratio' live. When a satellite appears or dissapears or slips above or below the minimum SNR value, I notice it **resets the ambiguity ratio back to 1.0** and that is a major setback in the quest for a fix, as it must reach 3.0 (default) for a fix. I watched this happen repeatedly, over and over under these conditions. Understand that this is not ReachView doing this, it is RTKLIB, and I know ReachView uses modified RTKLIB binaries so this particular quirk
may or may not be
_is not_ present when ReachView is handling the processing.
Another thing I noticed with both ReachView and
RTKNAVI.exe is a stalling effect where there is no output for 1 to 30 seconds, and then it continues. I thought it might be network latency, so I switched things up and was able to get the age down to 0 or 0.1 seconds, and it still had stalling problems. I don’t know why. My setup: I had the rover connected with ethernet over USB and the base was connected to a wireless router 3m away and that is wired to my computer. In the
RTKNAVI.exe window, I can see the base and rover input icons stay bright green when it stalls and the processing(?) icon goes dark.
Another thing I noticed in the
RTKPLOT.exe window a couple of times was a very stable float with an extremely tight grouping (only about 20mm) for several minutes, but with the ambiguity ratio hovering at 2.0 it was to low to become a fix.
In this testing with an obstructed sky, the best of my poor results were obtained with GPS and SBAS only, 14Hz (but I don’t think frequency mattered here) and picking a minimum SNR that would allow at least 5 or 6 satellites to be used in the processing.
I was really hoping to get a decent RTK fix this way, but it appears I will be off to find more open sky to achieve that.