[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gpsprof: higher resolution

From: Gary E. Miller
Subject: Re: gpsprof: higher resolution
Date: Sun, 16 Aug 2020 16:15:52 -0700

Yo John!

On Sun, 16 Aug 2020 19:00:43 -0400
John Ackermann N8UR <> wrote:

> On 8/16/20 5:26 PM, Gary E. Miller wrote:
> > RTK float/fixed is something the user usually sets, not the
> > receiver.
> > 
> > See: UBX-CFG-DGNSS  
> I don't think that's correct.  The UBX-CFG-DGNSS mode "3" says "fix 
> ambiguities whenever possible", but it doesn't force FIXED mode.  The 
> "whenever possible" is the key.  I just checked and my F9P is set to 
> mode 3, but is reporting a FLOAT solution.

Oh, that is just the start of places to look.  Nothing forces fixed
mode, but many things prevent it.

> In the past, I've seen the solution flip between FLOAT and FIXED when 
> using rtklib to do the processing, and also when using the M8P RTK 
> engine.  I think there is some requirement for signal quality,
> satellite geometry, or some other magic to determine whether the
> fixed mode is used.  If those conditions aren't met, the solution
> falls back to FLOAT, with reduced performance.

Yes, much magic.  The nav solution is a non-linear equation, so not
directly solvable.  The receiver takes a WAG on location and time, then
compuetes a trial set of measureables.  Those are compared to the 
actual measureables, then iterated again.

Only if the solution converges nicely will it report fixed.  Many things
will stop convergence.  The usual suspects: multipath, ionosphere,
ephemeris errors, etc.

> I don't know if this is correct, but here's the best description a 
> little bit of Googling (a dangerous thing) turned up:

And, of course, no vendor describes their secret sauce.

> Carrier phase measurements are very precise and in a GPS receiver we
> can measure them with mm-cm level measurement accuracy. However, we
> can only measure these quantities in fractions of one cycle. One
> cycle being 19 cm for the L1 GPS frequency. We do not know the number
> of cycles that exist between the satellite and the receiver. This
> unknown number of cycles is called an ambiguity parameter.

Never heard it called that.  Just an unknown to solve for.  Like
having a micrometer that only reads on the most significant digits.

> Theoretically, this ambiguity value must be an integer number (ie. 
> ...-infinity,...-1,0,1,... infinity). However, in reality there are 
> biases that exist in the satellites and receivers that cause this to
> not be the case.

I suggest you watch the Stanford videos that I recommended to Hal.
I much prefer their terminology to yours, and they go closely to
the IS-GPS-200.

> The big "if" here is whether we fix to the correct value or not.
> Because of multipath and other unmodelled errors, it can be very
> difficult to fix the ambiguity to the nearest value. For example, if
> estimated ambiguity is 1.5, should I round to 1 or 2? In this case we
> would not try to fix it to an integer value.

You assume the equation is linear, it is not.  The only solution method
is to iterate.  So you have the order of events backwards.  You try 
integers solutions, when they fail, you just mush it to death to some
sort of "flaot" answer.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpbufRnwnjOQ.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]