[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
> 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
> 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 ?
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the FOSS-GPS