[FOSS-GPS] RTKLIB FIX solution - Hold problem

[David Kelley]

Jérémy

This perhaps is showing the uBlox 6T in an unfair light.  Keep in mind 
that ALL the satellites have a Doppler of up to about  +-3000 m/s as 
they rise and set, reaching zero at they pass the zenith point.  In that 
reckoning, the additional rover movement is not of much consequence.  
But environmental effects are, so you may be seeing the rover or the 
base drop lock due to multipath or fades of more likely, both.  This is 
probably your root problem.

Export a RINEX file and look for this, look for the flag that declares a 
slip event.  There is also a logarithmic count value in the RTCM message 
that states "how long since the last slip" but I am not sure there is an 
easy way to view that value. There is a tool called RTCM inspect that 
does this, but is is not free.  Practical impact:  If your base station 
is sending constant slips, you rover can not cope.  Every time the base 
slips, the Rover must redo the ambiguity resolution for that SV.  Once 
you have a fix solution, this is easy, but before that time it jumbles 
up the search space. And as broad summary, all the tracked SVs will slip 
at odd times, perhaps once per ten minutes or so.  But when near the 
horizon (or any other obstruction) they will dramatically slip quite a lot.

As a broad summary of a complex issue (carrier tracking), I have seen 
over the past several years that the ublox residual tracking noise is 
perhaps 5mm worst case, while a truly great unit would be <1mm.  In 
other words, at short baselines normal RTK results <2cm is very 
practical if the correction themselves are good.

This strikes me as a odd thread for another reason, and I suspect the 
root problem is that using a low cost 6T uBlox for a reference station 
(where you will only get L1 data) is the root issue.  I have meet 
several people doing this over the years, but never done so myself 
(infrastructure  costs are not a prime concern in our work). I am going 
to have one of our staff repeat the experiment here using the 6T in 
place of a high grade reference station and see what we get both fixed 
and mobile.  We use 6T units in automotive testing all the time and the 
"out of the box" performance of the RTKLIB nav filer is surprisingly 
good under urban mobile conditions.

Sorry to be so lengthy, but hope it helps you track down the root causes
David Kelley


On 10/13/2014 8:05 AM, Fred Labrosse wrote:
> This is an interesting comment.  We are looking into buying receivers, for
> mobile applications, so it would be interesting to know which won't
> maintain carrier lock when moved.  Would you have details?
>
> Cheers,
>
> Fred
>
>
> On Monday 13 October 2014 09:51:43 Forrest Voight wrote:
>> What receiver are you using? I've noticed that some don't maintain
>> carrier lock when moved at all, making only static positioning
>> possible.
>>
>> On Mon, Oct 13, 2014 at 7:38 AM, jeremy.bouathong
>>
>> <bouathbouath at gmail.com> wrote:
>>> Hi,
>>>
>>> i'l currently working on the Kinematic mode and the Moving Baseline
>>> mode on RTKLIB. I succeeded to get FIX solutions for this two modes.
>>> The problem is that i can get a FIX solution when the rover is static.
>>> When i move the rover, the solution is FLOAT and RTKLIB searchs for an
>>> other Integer solution. In Options i configured the Fix and Hold
>>> solution, so I don't understand why i can't hold the solution i first
>>> found. I changed the bps on the COM options to 115000 bps to get more
>>> datas but it doesn't change anything. Can it be a hardware problem?
>>> I'm using a very old computer, with a low processor...
>>>
>>> Regards
>>>
>>> Jérémy
>>>
>>>