Question about code BIA states and ionosphere constraints in BNC PPP

[asdf123hb67@…]

Dear BNC developers,

I am currently studying the PPP/PPP-AR model implemented in BNC 2.13.6, especially the dual-frequency uncombined PPP parameterization in the src/PPP/ path. I would like to ask for clarification about the theoretical interpretation of the code BIA states and the ionosphere constraint model in BNC.

In a GPS-only test configuration, for example:

PPP/lcGPS=P12&L12
PPP/constraints=no

my understanding is that the LC string is parsed as:

cG1, cG2, lG1, lG2

At the same time, the PPP filter creates the following code-bias-like states:

BIA cG1
BIA cG2

together with per-satellite ionosphere states ION and per-satellite, per-phase-LC ambiguity states. From my current reading of the source code and the PPP output, BIA cG1/cG2 appear to be real Kalman filter states, not merely diagnostic output quantities.

We also noticed that the common mode of BIA cG1/cG2 is datum-coupled with the receiver clock. BNC seems to regularize this direction through the prior variance of the code BIA states, for example through aprSigCodeBias. Therefore, we do not think that the absolute values of BIA cG1/cG2 should be interpreted as independently observable physical receiver code hardware delays.

According to my understanding of conventional dual-frequency UDUC PPP, when no external ionosphere product is used as a constraint, receiver code biases are usually not estimated as a separate receiver DCB parameter. Instead, they are absorbed through re-parameterization into receiver clock, ionosphere states, ambiguities, and related datum definitions. Explicit handling of receiver DCB becomes necessary mainly in ionosphere-constrained PPP, where GIM, SSR/VTEC/STEC, or regional ionosphere products are used to constrain the ionosphere states. Otherwise, receiver code biases may contaminate the ionosphere states and cause datum inconsistency with the external ionosphere constraints.

Therefore, my main question is why BNC still estimates BIA cG1/cG2 for the dual-frequency code LCs even when:

PPP/constraints=no

This seems different from a conventional minimal full-rank UDUC PPP parameterization. It looks more like a code-LC-wise bias-like nuisance-state parameterization.

Under this interpretation, BIA cG1/cG2 can be re-parameterized into a receiver-clock common component and a receiver-DCB-like differential combination, for example:

DCB_like = BIA cG2 - BIA cG1

However, the absolute values of BIA cG1/cG2 would then be datum-dependent and prior-dependent.

Could you please help clarify the following points?

1. What is the intended interpretation of BIA cG1 and BIA cG2? Should they be interpreted as physical receiver code hardware delays, or rather as datum-dependent code-bias-like nuisance states?
2. Why does BNC estimate separate BIA cG1/cG2 states for the enabled code LCs in dual-frequency uncombined PPP even when constraints=no and no external ionosphere constraint is used?
3. What is the recommended interpretation of aprSigCodeBias in the BNC model? Is it mainly a numerical regularization parameter, or should it also be understood as a physical prior for receiver code biases?
4. When ionosphere constraints are enabled, for example using GIM/IONEX or real-time SSR/VTEC/STEC ionosphere corrections, what exactly does the BNC ION state represent?an absolute slant ionosphere delay, or a residual correction with respect to the external ionosphere model?
5. Does the ionosphere pseudo-observation directly constrain the absolute value of the ION state, or does BNC first apply the external SSR/GIM ionosphere correction on the computed side and then constrain the residual ION state close to zero?
6. If the receiver code-bias datum and the external ionosphere-model datum are not perfectly consistent, why does BNC use an absolute ionosphere pseudo-observation rather than, for example, a satellite-differenced ionosphere constraint or an explicit receiver DCB random-walk parameter?
7. Is the BIA cG1/cG2 code BIA parameterization mainly intended to support ionosphere-constrained PPP, especially real-time SSR/VTEC/STEC ionosphere constraints, by reducing receiver-code-bias contamination in the ionosphere state? If so, why is the same code BIA parameterization retained when constraints=no?

I am asking these questions because this implementation appears to differ from some common IC-PPP formulations in the literature, where receiver DCB is explicitly handled mainly when external ionosphere constraints are introduced. In BNC, the BIA cG* states look more like code-LC-wise bias-like nuisance states, and they seem to be used independently of whether ionosphere constraints are enabled. I would like to understand and document the BNC model correctly and avoid misinterpreting these states as directly observable physical receiver hardware delays.

Thank you very much for providing BNC as open-source software, and thank you in advance for your help in clarifying these model details.

Best regards,
Melissa Grove