[FOSS-GPS] RTKLib - Constant offset between UBlox NEO-M8T

Felipe G. Nievinski fgnievinski at gmail.com
Tue Apr 14 08:34:24 PDT 2015


Why moving base?  Relative positioning works best when whatever
ranging/phase errors involved are affecting equally rover and base
receivers.  At least multipath will be very different, between the car roof
and at your base location (soil or building roof).  If your base is within
a km of distance (and altitude difference within 100 m), atmospherics can
be assumed the same across the baseline.  Any unaccounted for phase wind-up
(the phase variation caused by antenna rotations) will cancel out if your
base is rotating along with the rover. (Although RTKLIB accounts for
wind-up, I think it's only complete for static positioning, i.e., I think
it neglects phase wind-up due to the receiving platform attitude; you may
want to check that on the documentation).  This should make the solution of
each of the two rovers w.r.t. the moving base better than the latter's
w.r.t. fixed base.

If PPK (backwards processing + combination) won't improve your "RTK"
(forward-only run) then I'd blame it on the antennas... On the other hand,
if PPK is better than RTK, it'd be possible to improve RTK with a longer
initialization time (i.e., leave it on, parked, before driving), especially
for L1-only data.

If you want to rule out software, download and try Spectra GNSS Solutions,
which is free (as in beer) for single frequency data, as it seems to be the
case for UBlox NEO-M8T.

If you have time, you may want to have RTKPOST logging observation
residuals, then inspect those in RTKPLOT. Based on this you might wish to
raise the cutoff elevation mask, i.e., discard grazing satellites, esp. if
you have good sky visibility.

Good luck.

-Felipe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/foss-gps/attachments/20150414/4711c6fb/attachment.html>


More information about the FOSS-GPS mailing list