Changeset 10943 in ntrip

Timestamp:

Jun 22, 2026, 3:50:26 PM (4 weeks ago)

Author:

stuerze

Message:

handling of ionospheric constraints described/updated

Location:

trunk/BNC/src

Files:

• bnchelp.html (modified) (1 diff)
• pppOptions.cpp (modified) (1 diff)

trunk/BNC/src/bnchelp.html

@@ -4398 +4398 @@
 </p>
 
+<p>
+The choice between an uncombined ('Pi&amp;Li', 'Pi', 'P1&amp;L1', 'P1') and an ionosphere-free ('P3&amp;L3', 'P3',
+'L3') linear combination does not just change which observations are read - it changes the set of parameters
+estimated by BNC's Kalman filter and how each observation enters the filter:
+</p>
+
+<p><b>Uncombined PPP</b><br>
+Each frequency's code and/or phase observation enters the filter on its own, without forming the
+ionosphere-free combination first. The state vector therefore carries, in addition to receiver position, one
+receiver clock per GNSS system and troposphere zenith delay (if estimated):
+<ul>
+  <li>one carrier-phase ambiguity per satellite and per phase frequency,</li>
+  <li>one slant ionospheric delay (ION) per satellite, and</li>
+  <li>one differential code/phase bias per frequency and GNSS system (common to all satellites of that
+      system), mainly needed to absorb hardware delays and to remove the rank deficiency between receiver
+      clock, ambiguities and biases.</li>
+</ul>
+Receiver clock, biases and the per-satellite ionospheric delay are re-estimated fresh every epoch (no Kalman
+process noise carried over), while position, troposphere and ambiguities accumulate over time. This means each
+epoch's ionospheric delay per satellite is, by default, determined from that epoch's code-minus-phase
+combination alone - exactly the weakly observable quantity that the optional ionospheric pseudo-observations
+(see <a href=#pppconstraints>Section 2.13.2.9</a>) are meant to stabilize.
+</p>
+<p>
+Uncombined PPP is not limited to two frequencies. For GPS, Galileo and BDS the custom band selection (e.g.
+'P125&amp;L125', see above) adds a third, fourth, etc. frequency the same way: one more code and phase
+observation, one more carrier-phase ambiguity, and one more per-frequency bias parameter, all referring to the
+very same single per-satellite ionospheric delay (ION) parameter, scaled to each frequency through the usual
+1/f&sup2; ionospheric mapping. The optional ionospheric pseudo-observations of
+<a href=#pppconstraints>Section 2.13.2.9</a> are added for any uncombined band selection this way, predefined
+('Pi&amp;Li', 'Pi', 'P1&amp;L1', 'P1') or custom, as long as at least one code or phase observation is configured
+for the affected GNSS system.
+</p>
+
+<p><b>Ionosphere-free PPP</b><br>
+The dual-frequency ionosphere-free linear combination is formed from code and/or phase data before it enters
+the filter, which removes the first-order ionospheric delay from the observation equation. The state vector
+therefore needs no per-satellite ionospheric delay parameter at all; it carries only receiver position, one
+receiver clock per system, troposphere (if estimated), and one combined (non-integer) ambiguity-like parameter
+per satellite that absorbs the carrier-phase ambiguity together with the satellite/receiver hardware delays of
+the combination. Because this combined parameter is not an integer number of cycles, ambiguity resolution
+(<a href=#pppar>Section 2.13.2.10</a>) is not applicable in this mode, and the optional ionospheric
+pseudo-observations of <a href=#pppconstraints>Section 2.13.2.9</a> do not apply either, since there is no
+per-satellite ionospheric state left to constrain.
+</p>
+
 <p><h4 id="pppcodeobs">2.13.2.2 Code Observations - mandatory</h4></p>
 <p>

trunk/BNC/src/pppOptions.cpp

@@ -290 +290 @@
       }
     }
-  }
-}
+    if (_pseudoObsIono && !LCs->empty()) {
+      LCs->push_back(t_lc(t_lc::GIM, t_frequency::dummy));
+    }
+  }
+}