[FOSS-GPS] rtklib kinematic Stop Go post-processing with rnx2rtkp

Felipe G. Nievinski fgnievinski at gmail.com
Sun Apr 19 21:58:08 PDT 2015

Let me resurrect this old thread.

The processing could be done in kinematic mode (either forward-only or
forward+backward combined).  That way, initialization tricks (antenna-swap,
fixed-length bar) as well as ambiguity reinitialization (cycle slips) are
less of an issue.

Then stop-and-go could be implemented forming weighted averages of the
kinematic position coordinates and precision (3-by-1 vectors and 3-by-3

It'd require a time table of occupation start and end times (and marker
name), which could be obtained simply grepping the rover RINEX observation
file to extract event flags.

If I were to implement this, I'd be easier for me to do it Octave rather
than built into RTKLIB's C code.


PS: the non-integer epoch seconds can be handled by teqc, see, e.g.:

Sat Jan 18 06:54:24 PST 2014
Previous message: [FOSS-GPS] rtklib kinematic Stop Go post-processing with

Dear Felipe G. Nievinski,
> Sorry for my delay.
> RTKLIB, rnx2rtkp, do not have stop and go processing option, at least
> 2.4.2.
> I process as kinematic and use the tagged rinex information to extract
> stoped location interval ( mean position).
> I can share my test data if you wanna see it.
> I do not know if the processing algorithm can or must  use some constraint
> for stop and go.
> my doubts:
> 1) at field session start point, the rover must stay over a known point
> for a while or use antenna swap or a fixed lengh bar as initialization.
> 2) how to restart in case of loss of lock, restart from previous good
> measured point ?
> 3) can we perform backward solution, and discard the signal loss portions
> and remeasure it back later ? i guess yes.
> back to time:
> I have one u-blox 4T (time receiver ).
> looking inside RINEX files I realise some time offset like this:
>  12  3 18 14 20  9.9940000  0 10G 2G26G25G 9G15G 4G29G12S20G27
> we have 9.994, where should be 10.000. RINEX file starts as integer
> seconds.
> a) Is this a cristal oscillator instability  ?
> b) could it affect pseudorange and carrier phase measurements ?
> c) could this clock jump effects be modelled and fixed by software ?
> regards
> julio menezes
> Em Sexta-feira, 17 de Janeiro de 2014 3:05, Felipe G. Nievinski
> <fgnievinski at gmail.com> escreveu:
>> Dear Julio,
>> did you find a solution to process stop-and-go data with RTKLIB?
>> I'm facing the same problem.
>> <http://lists.osgeo.org/pipermail/foss-gps/2012-August/000779.html>
>> Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/foss-gps/attachments/20150420/e621eb53/attachment.html>

More information about the FOSS-GPS mailing list