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 matrices). 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. -Felipe. PS: the non-integer epoch seconds can be handled by teqc, see, e.g.: <http://postal.unavco.org/pipermail/teqc/2012/001310.html> Sat Jan 18 06:54:24 PST 2014 Previous message: [FOSS-GPS] rtklib kinematic Stop Go post-processing with rnx2rtkp 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, >> > > >
_______________________________________________ This message is sent to you from FOSS-GPS@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