[Top][All Lists]

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

Re: gpsprof: higher resolution

From: John Ackermann N8UR
Subject: Re: gpsprof: higher resolution
Date: Sun, 16 Aug 2020 19:10:15 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

BTW, it's possible that the reason I'm not able to get a FIX solution is that the reference station I'm using (an old Trimble NetRS) is GPS-only so the number of SVs being corrected is limited and the geometry might not support the ambiguity resolution required. (I've tried limiting the F9P constellations to GPS only vs. all four, but that didn't make any difference.)

That's one reason why I'm interested in trying the ODOT reference network in the hope that they will provide correctsions for GLONASS as well as GPS.


On 8/16/20 7:00 PM, 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.


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:


reply via email to

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