RX, TX, timestamp and SoapySDR


#1

Hi all,

From what I read the timestamp on the Lime correspond to the FPGA counter in the RX part, and so it isn’t defined until you start to RX.

What does that mean for the TX part at the SoapySDR API level? To transmit something I have to pass a buffer as well as a timestamp. I guess it means the Lime will start streaming the buffer when that timestamp is reached. But then what happens if I never set the RX part?

Thanks for any pointers on how to use that TX API.


#2

That’s true, you cannot make TX-only app for LimeSDR if you want to work with timestamps, you have to also use RX calls in order to start the counter.


#3

Thanks,

So for TX-only app, do I have to use “real” timestamps or can I always use 0? Are those buffers simply put in a queue and sent as fast as possible, no matter what their timestamp is?

As for RX+TX app, is there an order to set things up? For example should I first setup the RX part, start its stream, and only then setup and start the TX stream, using a big enough timestamp to make sure I’m not late?


#4

Hi,
there is SOAPY_SDR_HAS_TIME flag that enables synchronization to timestamps. If this flag is not set then timestamp is ignored and data is sent to RF as soon as possible.

Also, it should be possible to use timestamps in Tx only. When you start streaming, timestamp in FPGA is reset to 0 and starts increasing even if Rx is not used, You can just start with some initial time offset. If packet is late (packet timestamp < FPGA timestamp) it is immediately dropped and ‘L’ is printed to console.


#5

Thanks for the clarifications.


#6

That’s true, but still you need to use at least one RX call to start the counter, and this is what I meant that you cannot make TX-only app :wink: Also it should be noted, that timestamps returned by getHardwareTime() method available in SoapySDR API are actually cached at the moments when you receive samples. Which means that if you won’t periodically use RX calls during operation, you won’t be aware of current estimate of hardware time, and the only way to know it to some extent is to observe late packet indicators, mentioned by IgnasJ.

At least that was the case few months ago, when I was testing it, it is possible (but not likely) that things have changed since then.