One sample shift on periodic pulse in RX channel

[Gluttton]

Hello everyone,

I faced a problem when my LimeSDR has a different offset for periodic pulse in loopback mode.

Topics with the similar problem:

• Cannot create consistent loopback ;
• [LimeSDR-Mini] Synchronized TX/RX Loopback Random Sample Offset .

Environment (system configuration):

• host OS: Linux;
• LimeSDR library: v20.07.2 (latest);
• board: LimeSDR USB (LMS7002M);
• gateway: 1.4 r2.23 (latest);
• work mode: 1x1, loopback using a RF cable with 20dB attenuator.

Problem:

1. If a pulse is transmitted with odd period (odd number of samples) the received signal front has a different offset (one sample difference) from period to period. The described problem has a 100% reproduce rate.
2. If a pulse is transmitted with even period (even number of samples) the received signal has the same offset of received signal front from period to period. But from sessing to session (after stream stopping and starting again) it may have a difference by one sample. This problem has a low reproduce rate (about 10%)…

Screenshots below illustrate the problem number 2:

Note: both screenshots have been captured with the same LimeSDR configuration but during different work sessions.

To make the issue investigation easier I’ve prepared a project with a minimal code example:

Gluttton/LimeLoop

The project is pretty simple, so it doesn’t have UI controls for signal adjustment. To change a work mode the source code has to be modified. The project readme file has some general explanation, but in case of additional questions, I would be glad to provide the all necessary information!

I hope that with this example it would be very easy to reproduce the issues on your side (at least the issue 1).

Any help would be greatly appreciated!

[Gluttton]

Below a summary of my progress.

First of all, I’ve added several minor improvements to the example. Besides minor fixes (comments and variable renames) some logic errors were fixed.

I’ve tried to reproduce the issue No.1 with the different settings:

• different carrier frequency;
• different sampling rate;
• different oversampling ratio (including “1”);
• different oversampling ratios for Tx and Rx (using LMS_SetSampleRateDir function);
• with enabling TDD mode (using EnableSXTDD function).

With all configurations above the issue is reproduced (the testing was performed before fixes using this version: https://github.com/Gluttton/LimeLoop/commit/fe5f9f1ccf27597d068d2e20dbff6ed9c8e66175 ).

After some testing, I realized that the issue isn’t reproduced with the disabled TX burst mode. The initial version of the example sends only non-zero samples to the HW with the flag for waiting for the timestamp and enabled TX burst mode. But the issue isn’t reproduced with another logic when zero samples are sent on HW explicitly and with disabled TX burst mode. This configuration may be tested by applying the following changes:

$ git diff
diff --git a/LmsQtLoopWorker.cpp b/LmsQtLoopWorker.cpp
index 167820c..93cb8a8 100644
--- a/LmsQtLoopWorker.cpp
+++ b/LmsQtLoopWorker.cpp
@@ -75,9 +75,9 @@ void Transmitter::Routine ()
     Sample <int16_t> signal [sampleSize];
     std::fill_n (signal, sampleSize, Sample <int16_t> {0, 0});
     const size_t signalFill = context->FillSignal (signal + context->offset, sampleSize - context->offset);
-    const size_t signalUsed = std::min (signalFill + context->offset, context->period);
+    const size_t signalUsed = context->period;

-    lms_stream_meta_t meta {0, true/*waitForTimestamp*/, true/*burst*/};
+    lms_stream_meta_t meta {0, true/*waitForTimestamp*/, false/*burst*/};

     while (!context->isExit->load () ) {
         if (!plan [idx].load ().isDoneRx) {

over the commit: https://github.com/Gluttton/LimeLoop/commit/5aaeba7b491ef5aae9887308744a9c9f9b157288 .

The preliminary conclusion: issue No.1 (wobble of the transmitted signal front) is reproduced only with the odd period and enabled TX burst mode. The issue isn’t reproduced with disabled TX burst mode and adding zero samples in the TX stream.

[Gluttton]

Below a result of my investigation.

1 Regarding the Issues.

Probably the issue No.2 isn’t a problem at all. The signal delay depends on different factors including the TX and RX actual filter parameters. But the filter parameters depend on the environment temperature and may have a random error. So, probably it is not an issue if the transmitted (or received) signal has an offset by one sample in different sessions.

Issue No.1 seems like a real problem. It looks like the LimeSDR can’t correctly detect a front of a received signal with the odd time offset. So I spent the time tried to investigate exactly this issue.

2 Testing results.

Explicitly utilize the TX stream with disabled burst mode (waitForTimestamp = true, flushPartialPacket = false).
As I mentioned in my previous post the issue isn’t reproduced when disabled burst mode and explicitly sending zero samples (samples with zero values) from timestamp to timestamp.

Explicitly utilize the TX stream with enabled burst mode (waitForTimestamp = true, flushPartialPacket = true).
I’m not sure if such a use case is correct. But in this mode, the received signal has the constant offset if the timestamp is a multiply of four. In other cases, the signal will “slide”. This is the second time when I faced the “magic four number”. The first time was when I tested GPIO TX indication: Select a TX channel as a trigger for activity indication (adjust a GPIO signal delay) - #5 by Gluttton .

Partially utilize the TX stream with enabled burst mode (waitForTimestamp = true, flushPartialPacket = true).
This is my target settings and it is the most interesting to me.
As I mentioned in my previous post the issue is reproduced in this mode. I tried to find an answer in the source code, but unfortunately I didn’t.

Fortunately, I found this post: TX/RX round trip latency and coherence - #2 by cmichal , when @cmichal wrote:

@cmichal

if you are using a single RX channel - never put an odd number as the timestamp in the tx packet header. Bad things happen. Internally the rx timestamps are only ever even numbers if there’s only one RX channel available, so presumably the odd number never matches.

I tried to add the second RX channel and the issue is gone! Everything I need is just to add LMS_EnableChannel and LMS_SetupStream it is even not necessary to read the second (dummy) RX channel.

Conclusion.
Seems like the LimeSDR USB has the following limitation (or feature): if only one RX channel is used with the following TX settings waitForTimestamp = true, flushPartialPacket = true the timestamp value must be an even value.

I kindly ask anybody from the maintainers teem confirm the conclusion above?

[andrewback]

This is one for @Garmus or @Zack.

[Gluttton]

Hello everyone,

Please find a video that should help to understand the issues I explained in my previous post.

@Gluttton

Explicitly utilize the TX stream with disabled burst mode ( waitForTimestamp = true, flushPartialPacket = false ).

Everything is OK.

@Gluttton

Explicitly utilize the TX stream with enabled burst mode ( waitForTimestamp = true, flushPartialPacket = true ).

Period is multiply of four, everything is OK.

Period is an odd value, there is an issue (“sliding”).

@Gluttton

Partially utilize the TX stream with enabled burst mode ( waitForTimestamp = true, flushPartialPacket = true ).

Period is an odd value and only one RX channel is used, there is an issue (one sample shift or Issue No.2 as I called it earlier).

Hope it helps better understand what I wrote about.

[Gluttton]

Hello @Garmus and @Zack,

Could you take a look at my question, please?

@Gluttton

Conclusion .
Seems like the LimeSDR USB has the following limitation (or feature): if only one RX channel is used with the following TX settings waitForTimestamp = true, flushPartialPacket = true the timestamp value must be an even value.

I kindly ask anybody from the maintainers teem confirm the conclusion above?

Thanks in advance!