-
Notifications
You must be signed in to change notification settings - Fork 262
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
Sigindex common2 #502
base: demo5
Are you sure you want to change the base?
Sigindex common2 #502
Conversation
aeac893
to
33b86b0
Compare
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.
Support determining the reported lock time from the lock time indicators. Calculate the time since the last observation (per signal). Use these to also check for a possible loss of lock. A slip might now be reported on an outage. Special case for receivers (Septentrio) that send a lock time indicator of zero on a half cycle ambiguity. Consider these as an outage deferring the decision to flag a slip until the signal returns. For a short period of half cycle ambiguity that recovers, a slip report might now be avoided. The functions for converting the lock time indicator to a time also support returning the time increment to the next indicator value. This was not found to be needed. Fix the observation flushing after a sync, which had been guarded by the max obs overflow check so that once the max obs limit was reached it was stuck.
The frequency index returned by code2idx() is not unique and conflicts need to be resolved. There were different implementations across the code, RINEX, RTCM, and the raw receiver decoders. Add a common exported function to implement this resolution. sigindex(..., opt) allocates an frequency index given a signal code, returning the allocated signal index on success of -1 on failure. Conflicts are resolved using the signal priorities that can be modified by the options in the opt argument, moving an existing allocation if necessary. sigindex(..., NULL) uses the same search algorithm as sigindex() but does not allocate a new entry or check the consistency of code priorities. Without the signal priorities, with the opt argument NULL, the allocation ordering could not be determined, so this case is used for this non-allocating variant. Apply this resolution per satellite as the set of signals can vary between satellites. Update the RINEX, RTCM3, Unicore and Novatel format decoders to use this new common function.
33b86b0
to
49aa5be
Compare
Best hold off this PR for now, and any that depended on it, sorry. The RTK solver path has issues with this that need to be explored, issues with multiple codes per frequency index. Probably the current limit of one phase bias per satellite frequency index, and perhaps that taking of differences across codes within a frequency index. Looking into solutions. A work-around is to ensuring that there are no such conflicts in the input data, to exclude them from the input observations, and then see some promising RTK results with many signals. |
Second try at this. The allocation is now incremental, does not require the full set of signals to allocate and so does not require multiple passes, and when there is a conflict an existing allocation might be moved or deleted. Also the function has two distinct modes, one to allocation and initialise, and the other mode just finds an existing allocation.