<div dir="ltr"><div>Let me resurrect this old thread.</div><div><br></div><div>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. </div><div><br></div><div>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).</div><div><br></div><div><div>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.</div></div><div><br></div><div>If I were to implement this, I'd be easier for me to do it Octave rather than built into RTKLIB's C code.</div><div><br></div><div>-Felipe.</div><div><br></div><div>PS: the non-integer epoch seconds can be handled by teqc, see, e.g.:</div><div><<a href="http://postal.unavco.org/pipermail/teqc/2012/001310.html">http://postal.unavco.org/pipermail/teqc/2012/001310.html</a>></div><div><br></div><div>Sat Jan 18 06:54:24 PST 2014<br></div><div>Previous message: [FOSS-GPS] rtklib kinematic Stop Go post-processing with<span style="white-space:pre"> </span>rnx2rtkp</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Dear Felipe G. Nievinski,<br>Sorry for my delay.<br>RTKLIB, rnx2rtkp, do not have stop and go processing option, at least 2.4.2.<br>I process as kinematic and use the tagged rinex information to extract stoped location interval ( mean position).<br>I can share my test data if you wanna see it.<br>I do not know if the processing algorithm can or must  use some constraint for stop and go.<br>my doubts:<br>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.<br>2) how to restart in case of loss of lock, restart from previous good measured point ?<br>3) can we perform backward solution, and discard the signal loss portions and remeasure it back later ? i guess yes.<br>back to time:<br>I have one u-blox 4T (time receiver ).<br>looking inside RINEX files I realise some time offset like this:<br> 12  3 18 14 20  9.9940000  0 10G 2G26G25G 9G15G 4G29G12S20G27<br>we have 9.994, where should be 10.000. RINEX file starts as integer seconds. <br>a) Is this a cristal oscillator instability  ?<br>b) could it affect pseudorange and carrier phase measurements ?<br>c) could this clock jump effects be modelled and fixed by software ?<br><br>regards<br>julio menezes<br><br>Em Sexta-feira, 17 de Janeiro de 2014 3:05, Felipe G. Nievinski <fgnievinski at <a href="http://gmail.com">gmail.com</a>> escreveu:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Dear Julio,<br>did you find a solution to process stop-and-go data with RTKLIB?<br>I'm facing the same problem.<br><<a href="http://lists.osgeo.org/pipermail/foss-gps/2012-August/000779.html">http://lists.osgeo.org/pipermail/foss-gps/2012-August/000779.html</a>><br>Thanks,<br> </blockquote></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br></blockquote></div>