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

John Morris john at coyotebush.net
Fri Oct 17 05:20:39 EDT 2008


If your LEA-4T has early firmware and you want "fix" solutions, then you
should upgrade. U-blox used to do free upgrades. It involved sending the
unit to their office for a week or so. The newer firmware does full-cycle
phase just fine.

One way to think of it ... with half cycles, you have to know your position
to double the accuracy. This will take at least 4X the measurements,
assuming the measurements don't have any bias to them. If they do, then you
can only handle half the bias; you have to stay closer to the reference
station. 

  - John

-----Original Message-----
From: foss-gps-bounces at lists.osgeo.org
[mailto:foss-gps-bounces at lists.osgeo.org] On Behalf Of Martin Vermeer
Sent: Friday, October 17, 2008 12:30 AM
To: Open Source GPS-related discussion and support
Cc: eugenio.realini at gmail.com
Subject: Re: [FOSS-GPS] High accuracy positioning with low cost GPS
devices:a FOSS project

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
_______________________________________________
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



More information about the FOSS-GPS mailing list