N210 buffering problems

Has anyone noticed any buffering issues with USRPs? I can transmit and receive data but whenever I change the transmitted data, the receiver still reads the old transmitted signal. This is true even if I stop transmitting or disconnect the power from the transmitter. If I do a "release" or a very large number of dummy reads, the correct data is read. This leads me to believe there is a problem with buffering but I don't know how to solve this, apart from releasing the system object or reading lots of dummy data (both of these approaches take up a lot of time).

I'm using two N210 with XCVR2450 daughterboards and Matlab R2020a (Communications Toolbox with SDRuTransmitter and SDRuReceiver). I've tried both with and without Burst Mode but that doesn't seem to make any difference. I'm seeing the same problem under Windows 10 and Ubuntu 20.04.

Answer 1

[Karunya Choppara]

The dummy data indicates that the data is not valid. If the data length output of the SDRuReceiver is greater than zero, it indicates that the data is valid. If the data length output is zero, it indicates invalid data.

[Magnus Sandell]

That still doesn't work. I followed the example in the documentation by doing

while len<=0, [rcvdSignal,len]=radio_rx(); end

The variable rcvdSignal still contains data from the previous transmission unless I repeat this operation a large number of times. That's why I suspect some kind of buffering issues.

[Karunya Choppara]

The current implementation of the SDRu receiver has inherent buffering, which we are actively working on to eliminate the buffer delays. However, upon releasing the receiver system object, the buffers would be cleared.

To obtain the valid data (outData in the code below)

for t =1:1000

[rcvdSignal,len]=radio_rx();

if len>0

outData = rcvdSignal;

end

end

release(radio_rx);

[Magnus Sandell]

Yes, this is essentially the way I do it. I apply a number of dummy reads with radio_tx() where I don't care about the results. Once that is done, I read the data until len>0 to get valid data. However this is taking a long time, which slows down the measurements considerably.

Another approach is to release the system object. However, apart from taking a long time, I find that this has some transient behaviour where the read data looks strange the first few times, e.g, wild fluctuations even if a single tone has been transmitted. It settles down after a while but this adds to the delay.

Are there any other tricks to clear the buffer and ensure fresh data?

Answer 2

[Karunya Choppara]

Hi Magnus,

One trick would be to use burst mode with number of frames in burst set to 1.

https://in.mathworks.com/help/supportpkg/usrpradio/ug/burst-mode-buffering.html

We are actively investing to update the internal buffer mechanism to eliminate the invalid data outputs with the receiver. The updates would be available on the release notes at https://in.mathworks.com/help/supportpkg/usrpradio/release-notes.html

[Magnus Sandell]

Thanks for the tip. However when I tried it, I get the error message

Error using comm.SDRuTransmitter/stepImpl

Transmit unsuccessfully: Could not execute UHD driver command in 'sendData_c':

libmwusrp_uhd_capi:tx_send_samples:ErrInternalUnderflow There was underflow when performing a burst transmission.

This was with a transmit signal of size 5216 samples and an InterpolationFactor of 32. I tried other number of frames but although I can avoid the above error message, I still need dummy reads to avoid buffering issues.

Answer 3

[Karunya Choppara]

Hi Magnus

The buffer mechanism for SDRu Transmitter and Receiver system objects is updated in R2021b, that are now available with the R2021b pre-release at this link.