I have a Soapy program that transmits 20 bursts during 0.3s, then waits for 0.3s, then transmits again, … After usually less than a minute the call to SoapySDRDevice_writeStream returns a lower number than the expected number of samples. I use a 2.5s timeout, knowing that the bursts are between 2 and 10ms, and that I schedule them at specific times. All subsequent calls to SoapySDRDevice_writeStream return -1.
I’m using a LimeSDR USB configured at 55MS/s at 2450MHz and use another SDR to see what is being transmitted. At first I see my expected bursts, then after a while I don’t see my bursts being emitted anymore. After calling writeStream about 80 times (and not seeing any of the corresponding bursts being transmitted), it returns a lower number than the expected number of samples.
It looks as if at some point the FIFO gets filled but no sample is ever removed again. As a result no signal is sent and soon after the FIFO is full and stays like this.
Note that I do not queue too many signals. I schedule them to be sent a few milliseconds in the future and I verified they were indeed sent on time.
SoapySDR return -1 on timeout and that happens when it cannot put samples into software FIFO because it is full. So samples are not being taken from FIFO and sent to hardware. I can think of some reasons why it could happen:
High timestamp value is accidentally sent to FPGA and FPGA starts to wait on it.
Maybe the board is running very hot or lacks power and some logic error happens in FPGA/FX3 freezing operation.
Problem with USB driver or libusb. But in this case you would probably be bombarded with USB transfer error messages.
Tx thread is stopped (e.g. deactivateStream()), however I am not sure if soapy allows writing to inactive stream.
Also, have you tried it with lower sample rate? Does the same happen?
There was indeed an issue where sometimes the wrong timestamp was send, but it wasn’t a high timestamp, instead it was a negative timestamp. It’s obviously a bug on my part, but when you give a negative timestamp, part of the API handles it as a long long until it’s converted to a uint64_t, converting the negative timestamp to a huge positive one.
So maybe to avoid issues, the API could return a SOAPY_SDR_TIME_ERROR straight if a negative timestamp is passed.
I do have another question concerning the sampling rate. I tried lowering the sampling rate for TX, but it seems the RX and TX sampling rates are linked. So I used 55MS/s when activating the RX, and a 55/4=13.75MS/s for the TX. But when sending my bursts their duration was only 1/4 of the expected duration, as if the TX were actually running at 55MS/s. Is this expected?
