Issue with scheduled signal when using different RX and TX sampling rate

Projects LimeSDR
1

Hi all,

It seems that when scheduling a signal to be transmitted at a specific timestamp, if the TX sampling rate is different from the RX sampling rate, the duration of the transmitted signal may be incorrect.

For example, I’m in SISO, RX is at 55MS/s and TX is at 55MS/s or 55/2. The duration of the transmitted signal is fine, whether I send it at once or I schedule it.

But then if TX is at 55/4, 55/8 or 55/16 MS/s, then when scheduling the signal, I see that the duration of the transmitted signal gets shorter and shorter. From a signal that should be ~2.2ms, I end up seing a signal lasting ~1.8, ~1.4 and ~1ms respectively.

With the same code (using Soapy), if I transmit the signal at once, it is always of the correct duration, no matter the TX sampling rate.

@IgnasJ @Zack Is that a know bug or limitation?

Thanks.

2

Has anyone already observed this? I’m reading the signals to transmit from files, so I know the signal for a specific sampling rate is always the same . That’s why it’s weird that there’s a difference between when I sent the signal at once and when I schedule it. Also, the transmitted signal has the right bandwidth, it’s just its duration which is incorrect when scheduling it.

I’m using Soapy but I would guess Soapy simply forwards the calls to the Lime API, without doing any processing.

@andrewback @IgnasJ @Zack Is there a way for me to debug that?