Re: gpsprof: higher resolution

[John Ackermann N8UR]

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.

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.

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

"  
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.

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. To remove these fractional biases, we can perform relative 
positioning (double difference between receivers and satellites) which 
cancels out these non-integer biases and which leaves only the unknown 
integer value remaining. When we estimate this value, if the remaining 
error sources are properly modelled, the estimated value will be very 
close to an integer value. Because we know that in theory it should be 
an integer number, we can choose to remove the remaining fractional part 
and "fix" the ambiguity to the nearest integer value. If we are able to 
do this for all satellites in view, and we fix them to the correct 
integer value, we will get a very precise and accurate solution because 
we now have an unambiguous cm level measurement.

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. Instead we would let it "float" or 
keep the "real" number value for the ambiguity. This is a float 
solution. Over time this value will tend to converge towards its final 
value but this will take time. For long baselines or for PPP, this may 
take more than an hour! However, given enough time to fully converge the 
float solution will become ALMOST as good as the fixed solution, but not 
quite.

A fixed solution will always be more precise than a float solution 
because the ambiguity (number of cycles between the satellite and 
receiver) is constant. However, if I fix my solution to the wrong 
integer number , maybe because there was multipath or other unmodelled 
error sources, my result will not be accurate. It will have a bias but 
may still be precise (very small variation) which can mislead a user 
into thinking that they have a good solution.
"

from page 6 of this thread: 
https://rplstoday.com/community/surveying-geomatics/whats-the-difference-between-float-and-fixed/

John