RTCM MSM loss of lock indicator and last signal reported time

[ourairquality]

Describe the bug

RTCM MSM loss of lock indicator, assumption that the epoch time is the last reported lock indicator time.

This is a minor matter, just noted looking at the code, please close this is not important.

To Reproduce

Decoding a RTCM MSM stream where the interval between reported signal lock time indicators is not the same as the configured epoch interval. The RTCM stream might have a different rate, or there might have been an outage. A signal outage can be generated at the receiver in normal operation, or in the RTCM transmission pipeline where stuff happens. The lock indicator appears intended to make the loss detection robust to short outages.

Expected behavior

If the RTCM time of the last reported signal lock indicator were noted, for each signal, then the minimum reconstructed lockTime could be compared to this, rather than to the acsConfig.epoch_interval, for a more accurate LLI estimate.

If this time is greater then a loss of continuity is possible. There was time for the lock time to reset to zero and to again advance to this same lock indicator. Otherwise a loss in not likely, as already assumed in the code.

If the RTCM rate is greater than the acsConfig.epoch_interval then it can avoid excess LLI detection. e.g. if the RTCM rate is 1 sec and the config epoch 5 sec and then a lockTime of 3 need not trigger a LLI if the last report was 1 or 2 seconds ago.

Initialisation would also need to be handled.

The relevant code is:

rtcmDecoder.cpp

if (lockTime < acsConfig.epoch_interval)	sig.LLI = true; else sig.LLI = false;

[ourairquality]

Another related issue is that some receivers send a lock indicator of zero during a half cycle ambiguity, and yet recover reporting the lock indicator without a reset to zero, so it is effectively an outage. The outcome can be a slip, but that can be detect on recovery. If RINEX is logged and checked then an outage is reported but no loss of lock, for short outages. Perhaps they do this on purpose so that tests such as the current one, or tests checking for a regression in the lock indicator, trigger a loss of lock, or perhaps they did not think much of it. Septentrio appear to do this, and their Mosiac-X5 receiver was reported to be used in some Ginan related studies streaming RTCM to Ginan, and the current code logic might be resulting in unnecessary slips being passed on to Ginan.