[FOSS-GPS] gap in base observations unsettles RTKPOST indefinitely

Michele Bavaro mic.bavaro at yahoo.co.uk
Wed Jun 22 05:52:47 PDT 2016


Hi Anthony,
Did not try the demo3 branch as yet.. it's a great initiative but unless rtklibexplorer gets approved by Tomoji and they start pushing to the same code base, it will be difficult to do a merge each time code is updated on either side.Will try and let the community know.
Cheers,Michele
 

    On Wednesday, 22 June 2016, 14:37, anthony wooldridge <arwooldridge at googlemail.com> wrote:
 

  Hi Michele, I too have noticed irretrievable recovery after loss of fix eg base rover communication etc. 
  Possible some ideas from rtklibexplorer may help have you tried his demo3 branch, and other good ideas re recovering from fix and hold ? Regards Anthony
  
 On 22/06/2016 13:06, Michele Bavaro wrote:
  
  Hello, 
  I am doing Kinematic between base (LLH = 44.434828231 12.300198659 45.9096) and rover. The rover has 4Hz. The base has normally 0.2 Hz rate, but across midnight experiences a gap of about 90 seconds. So the age of differential correctly grows and solution goes from 1 (fix) to 5 (single). However when the base eventually comes back, a perfectly good set of observations pushes the EKF so far that AR does not recover anymore. So far I am solving this by adding  
              memset(rtk->x, 0, rtk->nx*sizeof(double)); /** RESET FLOAT STATES?? */ 
  in rtkpos.c after  
              errmsg(rtk,"age of differential error (age=%.1f)\n",rtk->sol.age); 
  However, my fix looks dirty and the problem should not manifest in the first place? So far I am guessing the problem is here:  
          if ((nv=ddres(rtk,nav,dt,xp,Pp,sat,y,e,azel,iu,ir,ns,v,H,R,vflg))<1) { 
  inside relpos() in rtkpos.c.  My feeling is that the age of correction when the base wakes up is said to be 0.2 seconds when in reality more than 90 have passed and so the partial derivatives go off scale?  Such behavior, if confirmed, may impair any real-life situation in which base and rover talk unreliably between each other...
  
  All data are here: https://www.dropbox.com/s/igwt9jsh8pco1bs/160531n-aann.zip?dl=0
  
  Can anybody comment on this and propose a cleaner fix?
   
   Cheers, Michele 
  P.S.: This happens with both 2.4.2b11 and 2.4.3b12  
  
 _______________________________________________
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/20160622/97504222/attachment-0001.html>


More information about the FOSS-GPS mailing list