False GPS cycle slips in Unicore decoder due to L2L observation index collision

[geofis]

Environment

• RTKLIB-EX: 2.5.1
• Receiver: Unicore UM980
• Input format: Unicore binary (-r unicore)
• Tool: convbin

Problem

RINEX observation files generated by convbin contain a large number of GPS Loss of Lock Indicators (LLI), resulting in thousands of apparent cycle slips in RTKPLOT.

The same raw binary converted with the official Unicore Converter.exe does not exhibit these GPS cycle slips.

Investigation

I instrumented decode_obsvmb() in src/rcv/unicore.c to trace the lock time handling.

The relevant code is:

tt = timediff(raw->time, raw->tobs[sat - 1][idx]);
lli = lockt - raw->lockt[sat - 1][idx] + 0.05 <= tt ? LLI_SLIP : 0;

The lock time logic itself appears to work correctly.

However, the trace revealed that two different GPS observation codes are assigned to the same observation index (idx).

Example:

2 UNICORE_LOCK G05 idx=1 code=20 tt=1.000000 lock_prev=1.010000 lock=2.010000 dlock=1.000000 lli=0
2 UNICORE_LOCK G05 idx=1 code=17 tt=0.000000 lock_prev=2.010000 lock=0.000000 dlock=-2.010000 lli=1

Both observations use the same raw->lockt[sat-1][idx] and raw->tobs[sat-1][idx] entries.

As a consequence:

• the first signal updates the stored lock time;
• the second signal immediately compares against the first signal's lock time;
• this generates a false LLI (LLI_SLIP).

This pattern repeats throughout the file, producing thousands of false GPS cycle slips.

Cause

sig2code() returns CODE_L2L, but checkpri() does not explicitly handle this code.

As a result, CODE_L2L remains mapped to the standard L2 observation index, where it collides with another L2 observation.

Temporary fix tested

Adding an explicit handling for CODE_L2L in checkpri() eliminates the collision and completely removes the false GPS cycle slips.

After this modification:

• GPS observations become continuous in RTKPLOT (attached).
• The generated RINEX behaves consistently with the official Unicore Converter output.

Question

Is this the expected handling for CODE_L2L, or should it instead receive its own dedicated observation index?

I'd be happy to prepare a pull request once the preferred solution is confirmed.

Example of RTKPLOT (Sat Vis) observations from a RINEX file generated with RTKLIB_EX 2.5.1, showing numerous false GPS cycle slips.

Example of RTKPLOT (Sat Vis) observations from a RINEX file generated with the patched convbin, showing that the false GPS cycle slips have disappeared.

[ourairquality]

Known issue, for receivers with multiple signals that map to the same frequency index, and there are probably many similar issues in the code. My approach was to index this data using the signal code rather than the frequency index, see the patch 'Index signal specific data using the signal code' in my queue, and for the unicore decoder that affects tobs[] lockt[] and halfc[].

[geofis]

Hi @ourairquality

I tested your patch (PR #470) using raw binary logs from a Unicore UM980 receiver.

Previously, I had implemented a local workaround that avoided the false cycle slips by assigning CODE_L2L to a separate internal index. Although that removed the slips, it also caused RTKLIB to export an additional observation type, which is not the correct solution.

After compiling RTKLIB with your patch, the results are much better (screenshot attached):

• the false cycle slips completely disappear;
• the generated RINEX contains the correct observation types (no extra frequency is created);
• RTKPLOT shows continuous carrier tracking, without the widespread false loss-of-lock events observed with the current master branch.

So your approach of indexing the lock time by observation code instead of frequency index

raw->lockt[sat-1][code]

instead of

raw->lockt[sat-1][idx]

appears to completely solve the issue for the UM980.

Thank you for implementing this fix.

One question, though: is there any particular reason why PR #470 has not yet been merged into the main branch? From my testing it seems to resolve this issue cleanly without introducing any observable side effects.

[ourairquality]

Thank you for testing. The project has limited resources, reviewing is a burden, it's easy to make mistakes and break things, the focus of this fork has been on low end single and dual band receivers, so I try to submit patches for merging that have a chance. Fwiw I have a personal fork with a branch that is effectively a pending patch queue that people could pick from if ever interested, but don't have the resources to support that.

[geofis]

Thanks for the explanation. I completely understand. I just wanted to report back that the patch works correctly with a real UM980 data set. We'll use this version in our processing pipeline, and hopefully the test results may be useful if someone revisits this issue in the future.