Labview Communications Suite Buffer Overflow Error with USRP

[GenericAccount]

Hello, j_bou.  After doing some trouble shooting I had discovered that it was the Tx Dequeing that was creating the error.  The Tx loop was encountering a problem and was invalidating the queue.  I had removed the portion where the Tx dequeue portion will release the queue if it had run into any errors.  This stopped the Queue error messages, but there still was a buffer underflow error being thrown by the Tx.  What I am guessing is that the Producer loop is not enqueing my data fast enough to my Consumer loop(The USRP Tx process). This may be why the error started to appear when I had increased the sampling rate beyong 2MHz.

I keep hearing that the queing process is the way to go when it comes to keeping the USRP buffers wellfeed before it gets cranky and throws buffer errors.  So.....I am a bit at a lost.  Maybe implementing a timer to have the Enque loop occur before the Tx buffer consumes? LIke, a USRP timestamp?

[GenericAccount]

Just wanted to update regarding something interesting.  I was doing some tweaking and noticed that my VI became more stable(not 100% stable because an occasional buffer error will pop up, but is progress!).  I then noticed from my Fetch Rx Data block that I had accidentally tied my numeric value for Number of Samples to the Timeout node. On my panel the numeric value for Number of Samples was 100k. This meant that my timeout value was being set for 100k and my Number of Samples was defaulting to 100k.  I then had properly set the Number of Samples to 100k, and let the Timeout default to 10.  But, this resulted in Buffer errors for both Tx and Rx processes.

Attached is the latest VI.  What I have done is tie the Number of Samples and Timeout nodes together with the numeric value for the number of Rx samples from my panel.  Thus far, the buffer errors seem to have been very much reduced.  It seems more stable for up to 400k Rx samples at a 30MHz sampling rate.  Buffer errors result when I ramp the sampling rate up to 40MHz.

I really don't want to jump the gun and say that the issue is fully resolved as there is further testing to be done.  But, the stability of the VI has very much improved, and just by sheer dumb luck.  Is setting the Timeout to an insanely high value a common remedy?

Please note that this was tested on a PC with USB3.0 interfacing.  I would like this VI to work on a laptop with USB2.0.  I have yet to test this program with USB2.0, but can give update after I do.

[Rama015]

hi all,

i have a problem about synchronizing and to get continuous transmiting and receiving signal for my project. the project about radar ofdm. in my experience to set bandwidth that the desired, needs to set iq rate because iq rate that i adjust equal to bandwidth output signal. but if i increase the value of iq rate as bandwidth, the flow data of the project, it happend to my rx that stopped the otherside the tx still running. i haven't idea about this problem, is anyone understood how to solve my problem to configuring bandwidth that i want and about iq rate?

regards,

rama

[Bowley]

Sounds like your buffer is overflowing, but you haven't got the correct error handling programmed in to make the error pop up. So the code just stops without explanation.

You can't increase the IQ rate indefinitely. You need to make sure you are fetching the samples from the device quick enough to stop an overflow. Producer Consumer architectures can help with this, and/or changing the number of samples per fetch. Different buses can handle different data rates, so if you're using USB USRP maybe try an ethernet USRP, or a PCIe (MXIe) USRP RIO.

I would recommend starting a new thread to get the right help as this one is buried and dead.