[FOSS-GPS] High accuracy positioning with low cost GPS devices:a
eugenio.realini at gmail.com
Thu Apr 30 13:06:40 EDT 2009
Michael Tandy wrote:
> I have a few questions, if you wouldn't mind...
> 1. Do you plan to release the source code, and if so, do you know when?
As soon as we have translated the main comments in the software from
Italian to English, an alpha release of goGPS will be published (MATLAB
code, probably under the GPLv3). I think that it will be done by next week.
> 2. How have you found Matlab for real-time processing? I was working
> with it a year or two ago, but I found some of the design decisions
> (which are great for postprocessing data and making programming
> simple) made it difficult to write bug-free, reliable code for
> real-time serial processing.
We worked a lot on MATLAB scripts for real-time processing. The main
difficulty was not directly related to MATLAB design, but rather to
synchronize properly the receiver and the permanent station data
streams. At the moment the software seems to be quite robust concerning
the MATLAB real-time acquisition, even though there are still some odd
behaviours that should be better investigated.
> 3. In the conclusion you say that goGPS always outperformed low-cost
> receivers, and sometimes matched the performance of high-cost
> receivers. I note you talk about decimeter accuracy. When goGPS didn't
> match the performance of the high-cost receivers, what was the cause?
> i.e. are you fixing your integer ambiguities, but incorrectly? Or
> leaving them floating? Or is it that even with correctly fixed integer
> ambiguities, you find higher noise/poorer tracking/imprecise
> time-tagging on the LEA-4T? Or something else entirely?
The main problems are related to:
1) LEA-4T data quality: code observations seem to have a noise that is
correlated in time and this correlation is currently not modeled in the
Kalman filter; phase observations show a similar correlation and, in
addition, they present "jumps" probably due to the clock drift
corrections implemented in the receiver. At the moment these "jumps" are
treated as cycle slips, but a "smarter" solution is surely possible.
2) Ambiguities are never fixed, because it is difficult that the
accuracy of estimated ambiguities decreases below 1 cycle. In order to
get this accuracy you need a long uninterrupted observation period (no
cycle slips), which is generally unrealistic under usual navigation
conditions (at least here in Como where we live!). In addition the
strongly correlated noise of the code observation could lead to biased
estimations of the phase ambiguities, that again would need much time to
3) Another important source of error is the dynamical model of the
Kalman filter, which at the moment is quite simplistic. In particular it
is not an adaptive model (e.g. same model for straight and curved
paths). We have some ideas on how to build an adaptive filter to
overcome these problems, but they're not implemented yet.
> Michael Tandy
More information about the FOSS-GPS