Ambiguities as state variables

[ZiglioUK]

I've been thinking again about treating "code ambiguities" as state variables, just like goGPS does with "phase ambiguities".
Code-wise there are two cases: 1.sub-ms (snapshot) ambiguities and 2.sub-20ms (after bit synch) ambiguities (see, as usual, Van Diggelen).
In the first case, we solve the code ambiguities based on a priori within 150km max from the true position, depending on the clock error.
In the second case, the a priori position has to be 3,000km max away.
As in the "phase ambiguity" case, cycles slips can occur and we compensate (in the snapshot case) by keeping reconstructed pseudoranges within 150km from a chosen reference (or pivot I suppose) pseudorange.

Now I like the way goGPS treats phase ambiguities as state variable. It's really elegant.
But is it really useful? As far as I understand, those ambiguities are not supposed to change from epoch to epoch, a part from cycle slips. And they're not solved by the system, either, or are they?
I hope my question makes sense.

Here's my current development branch:
https://github.com/Sirtrack/goGPS/blob/snapshotGPS/src/main/java/org/gogpsproject/ReceiverPosition.java

Notice, I've also added a DTM option.

[Edit] Fixed limits for a priori location

[ege010]

Actually we still have to add an integer ambiguity resolution method to
goGPS Java (goGPS MATLAB already uses the LAMBDA method for this), to be
applied after the EKF update step. It's difficult to get reasonably correct
values for the phase ambiguities in one (or in some cases, even several)
epochs, because many of the errors affecting GNSS observations are larger
than the phase wavelength itself. So typically one starts from reasonable
a-priori values, then let the estimates converge within the filter. By
keeping them estimated as float values in the filter, and applying integer
ambiguity resolution after the the filter update at each epoch, one can
benefit from both the "flexibility" of the continuous float solution and
the precision of the integer solution (once it can be safely applied).

2015-11-13 6:27 GMT+09:00 Emanuele Ziglioli [email protected]:

I've been thinking again about treating "code ambiguities" as state
variables, just like goGPS does with "phase ambiguities".
Code-wise there are two cases: 1.sub-ms (snapshot) ambiguities and
2.sub-20ms (after bit synch) ambiguities (see, as usual, Van Diggelen).
In the first case, we solve the code ambiguities bases on a priori within
300km max from the true position, depending on the clock error.
In the second case, the a priori position has to be 30,000km max away.
As in the "phase ambiguity" case, cycles slips can occur and we compensate
(in the snapshot case) by keeping reconstructed pseudoranges within 150km
from a chosen reference (or pivot I suppose) pseudorange.

Now I like the way goGPS treats phase ambiguities as state variable. It's
really elegant.
But is it really useful? As far as I understand, those ambiguities are not
supposed to change from epoch to epoch, a part from cycle slips. And
they're not solved by the system, either, or are they?
I hope my question makes sense.

Here's my current development branch:

https://github.com/Sirtrack/goGPS/blob/snapshotGPS/src/main/java/org/gogpsproject/ReceiverPosition.java

Notice, I've also added a DTM option.

—
Reply to this email directly or view it on GitHub
#19.

[ZiglioUK]

Thanks @ege010 , I think what escapes me is the idea of a float solution. I'll do some more thinking.
Do you think goGPS could be adapted for a PPP case?

[ege010]

In the MATLAB version, I am veeery slowly introducing all the elements
needed for PPP. It's not so far now.
For the Java version, however, it will take some more time and effort.

2015-11-18 20:41 GMT+01:00 Emanuele Ziglioli [email protected]:

Thanks @ege010 https://github.com/ege010 , I think what escapes me is
the idea of a float solution. I'll do some more thinking.
Do you think goGPS could be adapted for a PPP case?

—
Reply to this email directly or view it on GitHub
#19 (comment)
.