Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Index signal specific data using the signal code #470

Open
wants to merge 1 commit into
base: demo5
Choose a base branch
from

Conversation

ourairquality
Copy link

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.

@ourairquality ourairquality force-pushed the code-key-vs-freq-idx branch 3 times, most recently from e154c67 to c34afba Compare September 23, 2024 13:21
@ourairquality ourairquality force-pushed the code-key-vs-freq-idx branch 4 times, most recently from 3aa775b to be37f57 Compare October 8, 2024 06:06
@ourairquality ourairquality force-pushed the code-key-vs-freq-idx branch 5 times, most recently from f83b653 to 47b4459 Compare October 28, 2024 11:05
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant