How many bits can I send and receive via USRP?

[Ferdoon]

Hi,

I am using usrp 2932 for the packet transmitter and receiver example. I use one box to transmit and another one to receive. My question is how long message can I send? I mean how may bits? Because when I send a text which contains around 3 million bits, everything works good. When I increase my text to 5 million I get error at receiver. My error is " number 1074118610 , The received data is out of sequence. This may be a symptom of overflows due to an inability to maintain streaming at the specified IQ Rate, or rearrangement of packets by an ethernet adapter or network switch" 

Now my question is what is the reason? Is is about length of message? IQ data rate? time acquisition?

Thanks in advance,

[Captain_K]

Hi Ferdoon,

Generally this error is about rate, not so much about the number of bits. Can you post the code you're using with the parameters you're using set as default? Do you see this same behavior when running shipping examples?

Also, what are you using to host the USRPs? A desktop, embedded controller, ect? 

I would try reducing the IQ rate and also review the Data Streaming Performance Tips

http://zone.ni.com/reference/en-XX/help/373380F-01/usrphelp/data_streaming_performance_tips/

[Ferdoon]

Thanks for replying to me.

So why with smaller size text this error dose not happen? even for high IQ rate data? when I increase size of text it happens.

I use the example of this forum which is a well known one : http://forums.ni.com/t5/Software-Defined-Radio/Packet-based-Digital-Link/ta-p/3509866

I just use a text that produce bits more than 3 million.

I am doing this because I wanted to measure the BER of my system. I know that if I wanted to have reliable results the number of bits I am sending should be large. 

Thanks in advance.

[Captain_K]

The reason it may be happening with a larger data set is because you’re eventually filling up your buffer. The RX Fetch rate may be able to keep up when there’s only 3 million bits, but as more and more bits come in, it gets to a point to where the RX Fetch can’t pull the data fast enough.

There are many factors that can affect the streaming performance of a USRP. These include PC performance, code architecture, and Ethernet speed. Although it may not be possible to continuously stream data to the PC at the highest IQ rate, there are a few things you can do to increase your streaming performance. The first of these is to increase your number of samples per fetch. This must be increased in multiples of 363 or 726, for sample widths of 16 bit and 8 bit respectively. Another is to make sure that you have a dedicated PC which is not running any other programs in the background which consume memory and processor resources

[Ferdoon]

Where is this buffer? Is it a memory inside my PC or the USRP? How much is it?

MY second question, when you say: "The RX Fetch rate may be able to keep up when there’s only 3 million bits, but as more and more bits come in, it gets to a point to where the RX Fetch can’t pull the data fast enough." should n't it just be related to the rate? Why it is related to the number of bits? I mean it is a loop. 

If I understood correctly, the usrp start to sampling the received signals and give these samples to a buffer. The buffer evacuation rate depends on the PC and labview program speed?

If this speed is constant, then the number should not have any effect. It should be just the IQ rate.

Am I correct?

[Ferdoon]

Dear Matt

First, Where is this buffer? Is it a memory inside my PC or the USRP? How much is it?

MY second question, when you say: "The RX Fetch rate may be able to keep up when there’s only 3 million bits, but as more and more bits come in, it gets to a point to where the RX Fetch can’t pull the data fast enough." should n't it just be related to the rate? Why it is related to the number of bits? I mean it is a loop. 

If I understood correctly, the usrp start to sampling the received signals and give these samples to a buffer. The buffer evacuation rate depends on the PC and labview program speed?

If this speed is constant, then the number should not have any effect. It should be just the IQ rate.

Am I correct?

[Captain_K]

For this particular error, I’m not sure if it’s referencing the PC buffer or the buffer on the USRP. Generally, overflow errors are a result of not being able pull data off of the device FIFO fast enough. The network connection would be would be my guess as to why this error is being caused. There are some tips in the link I posted previously that may help.

For your second question, even if the rate is constant, there may come a point to where there’s too much data coming in. Think of a leaking bucket analogy where the bucket leaks at a constant rate. For a while, we can add water to the bucket at a rate that’s faster than the leak but eventually, the bucket will fill up and overflow.

For your test, have you tried increasing the Acquisition Time? In the code, you can see that the Fetch RX Data in dependent on this value. Increasing the number of samples to fetch may help with this error.

[Ferdoon]

Hi again,

I have tried increasing the Acquisition Time and it makes it better. It makes it receive the data even when I increased the total bits send BUT up to a certain level. 

Now I encountered the same problem at transmitter.  For the receiver I get it. But for transmitter since it is already work in a loop and send some bits continuously, why when I increase the number of bits it is giving me error of underflow?

Thanks again,

[Captain_K]

There are some great additional forums post with user discussing the same topic. Have you reviewed the followed links and tried any of the suggestions?

http://forums.ni.com/t5/USRP-Software-Radio/Avoid-underflow-and-overflow/td-p/3586085

http://forums.ni.com/t5/USRP-Software-Radio/USRP-2954R-Tx-Underflow-at-IQ-Rates-gt-50MHz/m-p/3579050

https://forums.ni.com/t5/USRP-Software-Radio/Tx-Underflow-details/td-p/2304048

http://forums.ni.com/t5/USRP-Software-Radio/Error-Underflow-the-Tx-buffer-was-emptied-before-new-dat...