|
| From: | Gerry Creager - NOAA Affiliate |
| Subject: | Re: gpsprof: higher resolution |
| Date: | Mon, 17 Aug 2020 22:55:40 +0000 |
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
| [Prev in Thread] | Current Thread | [Next in Thread] |