Runtime frequency index configuration #715
Description
There is an initial proposal for runtime frequency index configuration in the branch https://github.com/ourairquality/RTKLIB/tree/oaq
This adds a new configuration option pos1-sigdef which has the format: -[sys][band][priorities][band][priorities] ... where each band is assigned to the next frequency index.
This also splits BDS into BDS2 and BDS3 to that each subsystem can have a separate set of frequency index mappings, now named C2 and C3. This also makes it easy to enable or disable these subsytems, rather than using satellite exclusions.
So, based on one set of ublox X20P data seen, the following might be suitable: pos1-sigdef -G 1C,2L,2S,5Q -E 1C,5Q,6B -C2 6I -C3 1P,5P,6I -S 1C -I 1C,5Q
The priorities are optional, and if not supplied then the defaults are used, so this could be defined as: pos1-sigdef -G 1,2,5 -E 1,5,6 -C2 6 -C3 1,5,6 -S 1 -I 1,5 This is applied to the bands individually, so only where a priority is supplied are the priorities for the band modified from the defaults.
Only the systems mentioned in this definition are modified from the defaults, so in some cases it might not be be necessary to define all systems.
The white space and commas are ignored and the signal base number need not be repeated so this could be defined as: pos1-sigdef -G1C2LS5Q-E1C5Q6B-C26I-C31P5P6I-S1C-I1C,5Q.
A frequency index can be skipped by using the band number 0, to leave it unassigned.
As an extension it would be possible to add some pre-defined mappings and give them some keys in this signal definition, for example the above might become: pos-sigdef -X20Pa or alternatively the GUI apps might just offer some suggestions to fill the signal definition if that is considered important.
The GUI app frequencies dialog is now dynamically generated and might help in testing a definition as it will show the index mapping and code priorities in a table. The '?' button for this has been include next to this definition in the GUI for this purpose.
Have not attempted to separate this from a good number of other wip PRs but it likely depends on many, so just putting this set out for anyone curious.
Many hard coded frequency index assumptions needed to become runtime decisions. To assist this the code priorities and frequency (Hz) have been separated from the frequency index mapping - these depend on the RINEX signal band and not the signal index. Some library function interfaces have been modified a little for this, and some new functions added. An benefit is that now there is not the developer burden of having to keep all those in sync with the frequency index.
The proposal requires a reversible mapping from the RINEX signal base number to a frequency index. It is no longer possible to say map both GLONASS G1 [band 1] and G1a [band 4] to frequency index 0. Hopefully this is not a show stopper. The split of BDS into BDS2 and BDS3 helps avoid some such issues for BDS. It is inherent in this proposed definition syntax that this can not be done, as each new signal band advances the frequency index. To do otherwise might add a lot more complexity.
There remains some hard coded frequency usage in pntpos.c, for the group delays, but sorting that out seems a good block of work itself, but it does not seem like a show stopper.
There was some hard code frequency usage in preceph.c satantoff() for the IFLC that now uses the first two frequency defined indices for the IFLC. That code appears to need reworking anyway - the non-IFLC rtk solution might be better using a separate offset for each frequency rather than the IFLC, but the code needs to work with the broadcast data which appears to be to the IFLC phase center, so that all needs more thought.
For Galileo the IFLC now uses frequency indices 0 and 1, rather than 0 and 2 when available, as it seems cleaner to just use the signal definition to define this. Lets see if there is still a need to separately define LCs separately from the frequency index.
This might also be helpful for testing a subset of frequency indices as only those defined are now used. It now possible to attempt a solution using only L2 or L5 etc, or to emulate an L1/L5 receiver using a data stream with more signals, or to ignore data at a system index by skipping it in the definition using band 0, or to vary to IFLC per system by reordering signals in the definition.
This branch includes the support in the GUI apps (windows and Qt) and the console apps.