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

[Eugenio Realini]

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 
be corrected.

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.

> Thanks,
>
> Michael Tandy
>
>