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
<[email protected]> 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
_______________________________________________
This message is sent to you from [email protected] 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
