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:
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?