<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Good luck.</div><div><br></div><div>-Felipe.</div><div class="gmail_extra"><br></div></div>