N210 buffering problems

14 views (last 30 days)
Magnus Sandell
Magnus Sandell on 22 Mar 2021
Answered: Karunya Choppara on 1 Jul 2021
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.

Answers (3)

Karunya Choppara
Karunya Choppara on 14 Apr 2021
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.
  3 Comments
Karunya Choppara
Karunya Choppara on 17 Apr 2021
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
Magnus Sandell on 20 Apr 2021
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?

Sign in to comment.


Karunya Choppara
Karunya Choppara on 29 Apr 2021
Hi Magnus,
One trick would be to use burst mode with number of frames in burst set to 1.
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
  1 Comment
Magnus Sandell
Magnus Sandell on 30 Apr 2021
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.

Sign in to comment.


Karunya Choppara
Karunya Choppara on 1 Jul 2021
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.

Categories

Find more on Communications Toolbox in Help Center and File Exchange

Products


Release

R2020a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!