USRP Software Radio

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I get a faster Tx IQ rate, such as 5M or 10M

I would like to transmit my PN code as fast as I can. However, I found the maximum transmitting IQ rate I can reach is 2M. If it is larger, the error will come to be "niUSRP Write Tx Data (CDB).vi<ERR>Underflow: the Tx buffer was emptied before new data was provided.  Consider reducing the IQ rate, increasing the Write rate, or increasing the number of samples per Write."

 

 I have tried to increase the number of samples per write to be a very high value. However, it doesn't work.

 

Could anyone tell me how to increase the Tx IQ Rate efficiently?

0 Kudos
Message 1 of 13
(9,055 Views)

Hi Yikai,

 

Streaming data at IQ rates of 5 or 10 MS/s should be achievable on most systems.  I have a few questions and a few suggestions for you.

 

Questions

  • What type of computer are you using?
  • What is the processor?
  • What is the Ethernet chipset?  Or are you running your USRP using a PCI/PCIe gigabit Ethernet card?
  • Are you using an example that came with the driver or code that you wrote yourself?

Suggestions that have worked for myself and my coworkers

  • Change the computer's power setting from the default 'balanced' option to 'high performance'
  • Use the built in Ethernet port if possible.  If you are using a PCI/PCIe version, make sure it is a high quality card.  The cheaper ones cause dramatically poorer performance than the slightly more expensive ones
  • Turn off your virus scanner and other memory/processor intense programs
  • Check the "data Streaming Performance Tips" in the NI-USRP Help document.  There is a registry key that can be changed to help improve streaming performance

There are a lot of different factors that can cause poor performance with a USRP.  Please let me know a bit more about your system and the code you are running so I can better help troubleshoot this problem. 

Sarah Yost
Senior Product Marketing Manager
0 Kudos
Message 2 of 13
(9,053 Views)

Hi, Sarah

 

I use a 64-bit SONY laptop with AMD Athlon(tm) II P340 Dual-Core Processor and 4GB RAM. The Ethernet port is gigabit type. I connect the board to the laptop through Ethernet cables via a gigabit switch. An Tx example in the driver (in the attachment) is used for test.

 

After I take your suggestions that change the computer's power setting to "high performance", turn off the virus scanner, the rate still can't reach higher.

 

Yikai

0 Kudos
Message 3 of 13
(9,048 Views)

Hi Yikai,

 

Just wondering if you ever got this to work?

I'm having the same difficulty. What daughterboard are you using?

 

 

Thanks!

0 Kudos
Message 4 of 13
(8,922 Views)

Hey Mjsalv,

 

If you have tried everything mentioned above, you should also try changing your registry key.  How to do this is described in detail in this post:

 

http://forums.ni.com/t5/USRP-Software-Radio/Increasing-write-rate/td-p/2165368

 

Sarah Yost
Senior Product Marketing Manager
0 Kudos
Message 5 of 13
(8,919 Views)

Hi Sarah and others, 

 

I need to send data at 16 Ms/sec in my application. But I am having problem doing so. 

Is this possible ? I checked the various threads on this forum and can now write at 4 Msamp/sec, but I am not able to go beyond it. 

 

I am using:

 

- NI-USRP-2921

- Intel Core2 Quad CPU with 8 GB RAM

- Windows 7

- RealTek RTL8168D/8111D family PCI-E Gigabit Ethernet NIC

- I am using the "NI USRP Write Tx Data (poly)" vi

 

I changed the registry key to HEX2400, amde sure that the firewall is turned off, and changed the power options to high performance mode. 

 

When I try a Tx sampling rate of 8 Ms/s, the subCallConfigTX.vi return a Tx sampling rate of 7.69 Ms/s and I get the following error.

 

"niUSRP Write Tx Data (CDB Cluster).vi<ERR>Underflow: the Tx buffer was emptied before new data was provided.  Consider reducing the IQ rate, increasing the Write rate, or increasing the number of samples per Write."

 

I would appreciate any help. 

 

Thanks,

Adnan

0 Kudos
Message 6 of 13
(8,874 Views)

Hi

If you can manage with 8 bits samples ,this would half the data sendt to the USRP,

try change the network-adapter Transmit buffer size , it may help

i manage receiving at 25 MSPS i 8 bit mode, but i have a dedicated network adapter directly to the USRP,

 it is only stable if you don't do any other network access to another network-adapter.

 

 

0 Kudos
Message 7 of 13
(8,868 Views)

Hallo Sarah,

I've seen your posts around this topic which seems to burden almost all USRP user including myself. You might have much experience with that device I suppose.

 

Actually, I've followed all the instructions that have been given to solve the "Underflow Issue" generated by the USRP 2920.

-I edited the FastSendDatagramThreshold and set it to 2048 (in my case it wasn't any)

-I changed the computer default performance to high prerformance

-Unfortunately, I couldn't shut down the anti-virus since I'am working on a company's desktop and not my own

 

My observations are following :

Previously to those changes, I could send/ receive to/from USRP at same rate for a particular setting; lets say I record a IQ rate =200k, number of samples = 1024.

Previously : I recorded / transmitted at 0,67 % of 1Gbits

After changes : I record at 0,67% of 1Gbist, and transmit at 1,32% of 1Gbits

 

I am working on a Tarox computer

-Intel core (TM) i5-2500 @ 3,3Ghz

-64 bits windows OS

-Realtek PCIe GBE Family Controller

 

I've attached my VI to this post may be you'ill make some recommandation for change.

 

Thanks in advance for your support

0 Kudos
Message 8 of 13
(7,576 Views)

I noticed two things in your code that are unusual. Firstly, you set the USRP parameters for Active Antenna, Gain and Carrier Frequency in every loop iteration. I'd start by taking the USRP parameter block outside of this transmit loop.

 

You are using two separate loops to generate the samples and to write them to the USRP which is generally a good design. However, I don't understand why you use timers in the first loop. I guess this is to prevent that the input file is read all at once and written to the queue completely but you can achieve a similar goal by just limiting the size of the queue by setting the parameter in the "Obtain Queue" VI. Inserting an element into the full queue will then cause the call to block until the other loop removed an element, effectively forcing both loops to run at roughly the same rate and with the queue as a buffer in case of jitter. The principle is that the only critical rate in your program currently is the rate at which the USRP transmits samples. So by introducing an artificial rate limit in the producer will most likely lead to either a slow filling up of the queue (in case the producer runs slightly faster than the consumer) or to an eventual buffer underrun (in case the producer runs slightly slower than the consumer). Those effects usually show more quickly at higher rates since the margins for jitter become thinner and thinner.

 

After doing this change you can also easily add some functionality that prevents the transmission from starting until the queue is filled up to a certain degree. This buffering gives greater tolerance against timing jitter and is effectively the same as in streaming audio or video where it's used very successfully.

Last thing, 1024 samples sounds a bit small per chunk to write to the USRP. I don't know if there are internal improvements to this but I had big success when increasing the chunksize to 32k or 64k in applications with high sample rates.

So to put it together:

 

- Do not run producer and consumer with different time sources, base everything off the consumer since it's the critical one, size-limited queues are great for that

- Remove everything from the inner loops that does not absolutely need to be there

- Prefill queues to allow for buffering

- Increase size of data chunks sent to the USRP at high rates

 

Regards,

Jan Dohl

TU-Dresden, Vodafone Chair

0 Kudos
Message 9 of 13
(7,564 Views)

Hi Jan,

thanks for your suggestions it was really helpfull.

I've limited the queue length and it works fine. The memonry issue I had previously is been canceled.values causes the program to record nothing; that's the recorded file size remain 0 KB. Or you get lesser size for slightly greater values (2048 or 4096).

 

However, I had another issue regarding program execution. When running the VI, the consummer runs verly slowy or start running only after the queue is full and the producer stop pulll data in there. In that time I can listen to my record on a normal FM radio set. When I then stop the procuder, my record become plausible on my FM radio set. That would means the processor time is unbalanced bitween the two threads.

 

Is there a way to reverse this?

 

I was able to playback a 5M IQ rate file yet although I've performed all suggested in the forum. But, the parallel execution issue is my major concern. 

 

Thanks for your support 

0 Kudos
Message 10 of 13
(7,542 Views)