Problem using Lime w/Soapy 'C' API for full-duplex TX/RX

Projects LimeSDR
1

Apologies in advance - this is most likely a PEBCAK problem. I’m still spinning up on the API, and am not aware of all the nuances and dependencies.

I’m working on a radar, so I need to transmit and receive at the same time. I started with the ‘C’ receive samples example:

I built LimeSuite and Soapy from source (pulled both a couple of weeks ago).

The ‘C’ example works just fine. And when I modified it to create a TX stream in isolation that worked too - I see my signal coming out the correct spigot, and it appears just as expected.

But when I try to run both TX and RX at the same time only the receiver returns samples. The transmit LO turns on, but I don’t see my signal coming out.

The specific code:
// Send and receive the samples
for (int i = 0; i < 128; i++)
{
int txret = SoapySDRDevice_writeStream(sdr, txStream, txbuff_signal, tx_bufsize, &txflags, txtimeNs, txtimeout);
int rxret = SoapySDRDevice_readStream(sdr, rxStream, rxbuffs, rx_bufsize, &rxflags, &rxtimeNs, rxtimeout);
txtimeNs += tx_bufsize * 1e9/sample_rate;
}

If I comment out the readStream my signal shows up on the TX spigot. If I leave readStream in situ, I see the carrier pop up, but my signal does not come out.

I get no errors back from the API calls either during setup or when I’m on the air.

Can someone give me a clue?

1 Like
2

Try add constant to transmit timestamp(like 100ms). Your transmit packet are late for LimeSDR due to USB, FPGA etc delays. I used C++ API. Early working version is in:

3

I will give that a try. But my previous experiments seem to indicate that the timestamp clock gets reset to zero on the first use of the stream - my readStream timestamp always starts at zero and increments by buffer size * sample period.

Thanks -

4

Yes, it starts at zero. From what I understand timestamp represents internal clock within FPGA. When you read stream you get the value of it. But when you write it tells FPGA when to start transferring the data. So when you set transmit timestamp to what you got from read the packet is already late. You need to send future packets in advance:

for (int i = 0; i < 128; i++)
{
int txret = SoapySDRDevice_writeStream(sdr, txStream, txbuff_signal, tx_bufsize, &txflags, txtimeNs+100ms, txtimeout);
int rxret = SoapySDRDevice_readStream(sdr, rxStream, rxbuffs, rx_bufsize, &rxflags, &rxtimeNs, rxtimeout);
txtimeNs += tx_bufsize * 1e9/sample_rate;
}

Also note if you dont overload USB3.0 transfer. For 2xTX+2RX I only managed maximum sampling of 20MSps. That makes 4channels4bytes/sample2010^6=320MB/s

1 Like
5

OK - that seems to have helped.

Running at a 12.5 megasample rate, if I delay the start of the TX burst more than about 10 us (not ms) the TX signal does come out the spigot with the RX enabled.

But I still think it’s odd that in the ‘not working’ case no error messages come back indicating a TX underrun - is that typical?

Thanks much for the pointer -