Index signal specific data using the signal code #470
+264
−226
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is just a part of work to improve multi-frequency support. This addresses some subtle issues, and this plumbing needs fixing one way or another and this seems the simplest. There were changes in the set and ordering of signals mapping to the frequency index and state was mixed up on such changes. There are various signal priority strategies used in the code, some are currently fixed orderings, some not.
Even the ublox decoder was not keeping separate state per signal, rather state per frequency index. Perhaps the ublox encoding is static for a given configuration, tracking at most two signals, in which case the ordering of the frequency index could not change, but perhaps not. It was certainly an issue in many paths.
This change is intended to be rather neutral, not attempting to fix other issues, just changing the indexing. There might be some subtly differences in some paths where the signal frequency index could change, where state is no longer mixed up.
This might help make some of the signal to frequency index priority functions more flexible. For example, it might be possible to just pack in extra signals into the NEXOBS set, in no particular order, as the consumers might not be assuming a fixed order. Useful for decoding signals to RINEX or RTCM paths etc.
Only the observation data is still indexed by the frequency index. The problems have been narrow.
Rather than the signal frequency index which is still used in the observation structure to keep that compact.
When there are many signals the set of signals can change and when the priorities are recomputed the frequency index can change so the frequency index is not a reliable key for this state. This is not an issue with just one signal, or perhaps two, but with more than NFREQ signals there were subtle issues as the priories changed and the state was mixed up.
There are a good few structures with just one array of data for each signal and these have been expanded from being NFREQ+NEXOBS to MAXCODE so that the signal code can be used as the index. This is a little wasteful of memory but simple.