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

[Michael Tandy]

The key feature of the LEA-4T which makes it interesting for high
precision applications is that its binary protocol includes a message
giving raw observables - that is, code and carrier phase pseudorange
and doppler shift. This is documented in U-blox's protocol
specification as UBX-RXM-RAW (
http://www.u-blox.com/customersupport/antaris4_doc.html ). Carrier
phase information, in particular, is what's interesting.

I have heard the SIRF-II chipset also offered this raw data; but those
have largely been replaced with SIRF-III which doesn't offer the right
raw data - Sparkfun does have a few SIRF-II modules in stock though; I
don't know if sparkfun have a source for new SIRF-II modules after
those are out of stock. I've dropped Sparkfun an e-mail to ask - if
they have a source for SIRF-II modules that would be a pretty neat
find, as $60 for SIRF-II modules is a lot more affordable than $350
for an AEK-4T evaluation kit from U-blox.

The Trimble Copernicus chip on Sparkfun also got my hopes up with its
report packet 0x5A - but it doesn't offer carrier phase information
either. Most of the other GPS modules I can see on Sparkfun either
don't offer raw data, or at least don't say anything about raw data in
their documentation, which is as good as not offering it.

Michael


2009/2/3 Tyler Mitchell (OSGeo) <tmitchell at osgeo.org>:
> Anyone happened to tried any of these modules before?
> http://www.sparkfun.com/commerce/categories.php?c=4
>
> They also have some receivers listed with a combined cellular module.  Or
> are all of these out of the league for doing higher accuracy stuff?
>
> Tyler
>
> On 17-Oct-08, at 2:20 AM, John Morris wrote:
>
>> 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
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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
>