BDS 2 vs 3 signal priorities

[ourairquality]

Looking at test trace results shows some success using BDS-2 satellites but it appears that BDS-3 satellites are not used as only a single frequency is noted. With the BDS code priorities as filled by the GUI code_priorities: [L2I, L7I, L6I, L5P] the following is noted in the trace file:

PDE-CS GPST 2026-03-17 16:13:28.00 C24 42.59 --single frequency--

Processing C22 L5P L:  - single freqency data excluded
Processing C22 L5P P:  - single freqency data excluded
Processing C22 L2I L:  - single freqency data excluded
Processing C22 L2I P:  - single freqency data excluded
Processing C22 L6I L:  - single freqency data excluded
Processing C22 L6I P:  - single freqency data excluded

In case it helps, Wuhan bias product header notes:

- Overview of the OSBs included in the file
    BDS-2   C2I, C7I, C6I, L2I, L6I
    BDS-3   C2I, C6I, L2I, L6I
    BDS-3   C1X, C1P, C5X, C5P, C7Z, C8X

For BDS-2 the set is 2I 2X, 7I 7X, 6I 6X. Whereas BDS-3 has 7D rather than 7I, and not all receivers have 7D, and the set is 1P,1X 2I,2X 5P,5X 6I,6X, 7D. This just does not appear to fit within the broad BDS definition used by Ginan.

Alternatively if the BDS priorities are defined to suit BDS-3 code_priorities: [L1P, L5P, L6I, L2I, L7D] then BDS-2 satellites are lost:

Processing C16 L7I L:  - single freqency data excluded
Processing C16 L7I P:  - single freqency data excluded
Processing C16 L2I L:  - single freqency data excluded
Processing C16 L2I P:  - single freqency data excluded
Processing C16 L6I L:  - single freqency data excluded
Processing C16 L6I P:  - single freqency data excluded

There are some products that use only BDS-3 such as GRG0OPSULT and in this case it would be appropriate to use the BDS-3 signals.

Could Ginan separate the signal definitions for BDS-2 vs BDS-3 so that different signal priorities can be defined? Fwiw I have done this for my personal fork of RTKLIB.

[smcclusky]

We will look more carefully into this BDS2/3 code priority issue you have raised as I can see how this could be a problem, but have not yet reproduced the issue myself.
If you can send me an example config (and rinex file), I will take a deeper look at this issue.

What might be happening in the code, if you are using use_primary_signals: true option as the first BDS satellite found will likely be setting the 2 dual freq signals that will be used to select observations for both BDS2 and 3 satellite types. But I think if use_primary_signals: false is used this should not be the case?

What I know works from my limited testing of BDS data processing is code_priorities: [L2I, L6I].
Because both of these frequencies are broadcast by BDS2 and BDS3 satellites and should to be available for all BDS satellites? But as you point out this only works for receivers that track those two signals.

[ourairquality]

The CODE products appear to have changed their handling for BDS. On the 2026 day 38 the COD/MGX/FIN product includes both BDS2 and BDS3 and notes C2I and C6I as the reference observables, and on day 39 the same product includes only BDS3 and notes C1P and C5P as the reference observables.

The follow messages seems relevant:

https://lists.igs.org/pipermail/igsmail/2026/008649.html

At the same time, the MGEX ACs processing BeiDou will switch their signal selection from the legacy B1I/B3I signals to the modernized B1C/B2a signals. As the latter are only transmitted by BDS-3, this also means that BDS-2 satellites are not included anymore in the MGEX products.

https://lists.igs.org/pipermail/igsmail/2026/008677.html

decommissioning of BeiDou-2 satellites and the reassignment of the present BDS-2 PRNs to BDS-3 satellites

https://www.csno-tarc.cn/notice/noticeDetail?id=990&lang=en

Changes in Constellation Status During BDS Upgrade

Using some public data as an example, MOBS, at "/rinex/hourly/2026/039/00/MOBS*" and giving this as input into the Ginan UI and selecting COD/MGX/FIN then it notes 1P and 5P as available in the BIA file and automatically selects L2I L7I L6I L5P but does not select 1P. After manually selecting L1P the config file it generates has bds: code_priorities: [L2I, L7I, L6I, L5P, L1P] and when processed ginan does not use any of the BDS satellites in the result.

Might it be helpful if the UI automatically selected only the codes that are available in the BIA file.

Noted that the UI allows changing the priority order by dragging entries, so this can all be set in the UI. Manually changing the config to L1P L5P allows BDS3 satellites to be used.

Noted in passing that the PDE-CS might be having an issue with this. It seems to be claiming triple frequency but calculating garbage for lamew, gf25, and mw25. Enabling another signal such as L6I overcomes this.
PDE-CS GPST TRIP 2026-02-08 00:01:00.00 C19 31.90 0.751 -0.0168 0.1650 0.0114 inf 0.0000 nan vtpv= 0.2 val= 0.0 thres= 4.10 7 2

Btw looked into the use_primary_signals: true config option but it did not appear to be relevant here.

In general does it help the solution to include all signal available, or at least 3 for BDS, even if there are not bias products for them all? Might the variance given to an unknown bias handle that and still make these signals useful? Might they be a help after ambiguity resolution. Or might it be best to just use L1P L5P for this CODE product.

Also noting again that the solution file gives no hint as to the satellites being used. It could help users spot config issues if they see less than the expected number of satellites used in the solution.