[FOSS-GPS] RTKPos processing options
António Pestana
afsm.pestana at gmail.com
Wed Feb 11 14:49:56 PST 2015
Felipe
Your answer to my questions far exceeded my best expectations. Thank you
very much.
You directed me to appendix E of the manual. Somehow I have missed it... It
clearly deserves attentive reading. I hope to be able to fully understand
the concepts and the algebra involved.
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?
Best regards
Antonio
2015-02-11 20:57 GMT+00:00 Felipe G. Nievinski <fgnievinski at gmail.com>:
> a) What are the differences between position modes Single,
>> Static, Kinematic and DGPS/ DGNSS?
>>
>
> Basically you have two dimensions:
> - with or without base station (relative or absolute positioning, AKA
> baseline and point position);
> - using pseudoranges only or carrier-phase too.
>
> Then there are four combinations:
> - absolute position using pseudoranges: RTKLIB's "single";
> - relative position using pseudoranges: RTKLIB's "DGNSS";
> - absolute position using carrier-phase & pseudoranges: RTKLIB's "PPP";
> - relative position using carrier-phase and
> pseudoranges: RTKLIB's "static/kinematic/moving-base".
> (Confusingly, outside of RTKLIB "differential GPS" sometimes refers to
> relative positioning, but I discourage that.)
> "Fixed" and "PPP-fixed" are, respectively, relative and absolution
> solutions where the position is not estimated as an unknown; it's useful
> for atmospheric/ionospheric sensing based on observations residuals.
>
> Both static and kinematic modes estimate a position at every observation
> epoch (here RTKPLOT has no choice, as it implements a sequential filter
> rather than a batch estimate), see RTKPOS Options, "Output" tab, field
> "Solution for static mode" (all/final). The effective difference is in how
> much the position is allowed to vary from epoch to epoch: in kinematic
> mode, some artificial position uncertainty is injected from epoch to epoch,
> so as to prevent premature convergence; in contrast, in static mode,
> eventually the filter will settle on a position estimate saturated with low
> uncertainty, and then will stop paying attention to any new observations;
> see eq.(E.7.14), p.165 in the documentation:
> <http://www.rtklib.com/prog/manual_2.4.2.pdf>
> Apparently there's some interplay with the "Receiver Dynamics" option, too.
>
> See Appendix E, "Models and Algorithms", for details:
> - sec. E.6, "Single Point Positioning"
> - sec. E.7, "Kinematic, Static and Moving-Baseline"
> - sec. E.8, "PPP (Precise Point Positioning)"
>
>
>> b) What are the differences between Integer Ambiguity Resolution options
>> Continuous, Instantaneous and Fix&Hold?
>>
>> See Table on p.37 of the documentation:
> - Continuous : Continuously static integer ambiguities are estimated and
> resolved;
> - Instantaneous : Integer ambiguity is estimated and resolved by
> epoch‐by‐epoch basis;
> - Fix and Hold : Continuously static integer ambiguities are estimated and
> resolved. If the validation OK, the ambiguities are tightly constrained to
> the resolved values.
>
> T. Takasu may want to correct any misinterpretation in the above.
>
> Best,
> -Felipe.
>
> _______________________________________________
> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your
> subscription
> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/foss-gps/attachments/20150211/69d75c59/attachment.html>
More information about the FOSS-GPS
mailing list