[FOSS-GPS] High accuracy positioning with low cost GPS devices:a FOSS project

[Martin Vermeer]

On Thu, 16 Oct 2008 18:20:28 +0200
Eugenio Realini <eugenio.realini at gmail.com> wrote:

> We have written something on goGPS here: 
> http://geomatica.como.polimi.it/elab/goGPS/index.php?lang=en
> 
> John Morris wrote:

...

> > I sort of got burned out trying to implement a kinematic float solution. I
> > eventually concluded it is very difficult to detect or correct phase errors
> > with float solutions. You either have to be stationary and use a Kalman
> > filter, or you have to "fix" your solution so you know your position well
> > enough to catch the inconsistencies. I'm curious to know your approach - and
> > I'm really, really glad you've taken on this piece of work.
> Do you mean cycle slips when you say "phase errors"?
> At the moment, we set ambiguities as state variables in the Kalman
> filter, so that they evolve "dynamically" with the system... we
> initialize them as float values by comparing code and phase measurements
> and they converge in not so much time (with good conditions of sky 
> visibility).
> Then we detect cycle slips by comparing subsequent epochs and when they
> occur we just re-initialize the affected ambiguities.
> 
> ---
> 
> We have a couple of doubts we'd like to ask the community:
> 
> 1. up to now we didn't worry about the "half-cycle
> ambiguities resolved" that appear in the LEA-4T data sheet... do they
> impact significantly on the receiver performance?

I suppose so, in the sense that the "wavelength" for ambiguity
resolution will be only half, so it gets harder to do. But when
successful it shouldn't affect performance.

So this receiver apparently uses a Costas discriminator which doesn't
"see" a 180 deg phase shift.

> 2. We noticed that the same phase values read from RINEX and from RTCM 
> (same permanent station: RINEX taken directly from it, RTCM 3.0 stream 
> sent by the GNSS positioning service it belongs to) differ by a constant 
> value. The results are not affected by it because it goes away in the 
> differential positioning, but we do not understand why it's there.
> 
> Eugenio