[FOSS-GPS] RTKPos processing options

[Felipe G. Nievinski]

>
> One more question:  integer ambiguity is estimated and resolved by
> epoch‐by‐epoch basis. So, if I understand correctly each epoch we have to
> deal with one unknown ambiguity for each observation. So the number of
> unknowns equals the number of the available observation equations plus the
> position unknowns plus etc... How can we manage to get an unique solution
> to the problem?


It's only in instantaneous AR that ambiguities are reset every epoch.  Even
then, there are always two observations per satellite signal: one
carrier-phase and one pseudorange.  So if there are, say, 7
satellites visible from a single-frequency receiver, there are at least 7 x
2 = 14 observations and 7 + 4 = 11 unknowns (7 ambiguities, 3 position
coordinates, and 1 receiver clock).  As 14 > 11, it's still doable.
Furthermore, one can track multiple signals broadcast by a given satellite,
which increases redundancy.

If using fixed positioning mode, there would be only 7 + 1 = 8 unknowns per
epoch.  And if using static mode, eventually the position coordinates will
be well known, so the filter starts having 11 unknowns but ends with
effectively only 8 unknowns per epoch; and if you run the filter backwards
(then later combine it with the forward run, as RTKPOST does), the start of
the session is covered as well.

Now, that was for instantaneous AR, and I don't think you'd ever want to
use it, except perhaps if you're investigating the quality of your data, or
into some research about the various biases.  Continuous AR carries over
the previous epoch's ambiguities estimate and their uncertainty into the
next epoch, so that eventually the ambiguities will have converged.

After ambiguities are estimated as "float" (floating-point values), RTKPLOT
will also try to resolve double-differenced ambiguities as integer
multiples of the wavelength, as they're supposed to be (that's a physical
constraint). Finally "fix and hold" means that once an ambiguity is
successfully resolved an an integer, it's assumed exactly known afterwards,
which improves the precision of the position coordinate estimates
subsequently.

Hope this helps.
-Felipe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/foss-gps/attachments/20150214/35b19958/attachment.html>