Make a transceiver from USRP Packet TX/RX example

[tintin99]

well. I use the same version

I can't find the example. I am using 1.1 but I didn't download it from the website. Somone from the Ettus team sent me this driver something like 8 month ago. Maybe the one on the website is up to date. Yes I would greatly appreciate if you can send me the FW/FPGA images. I use N210

Thanks

[Sarah_Y]

Hi tintin99,

You can download the 1.1 driver here.  If you need me to send you the actual files, send me a private message with your email address and I'll find a way to send it to you.  The driver is a little over 30 MB, so that is over most email inbox size limits, but I can still get it to you if you need.  It's possible that you may have a beta version of the driver instead of the version that was released.  Hopefully updating the driver will help.

When you download the driver it also downloads the FW and FPGA images.  You can use the NI configuration utility to write them to your device.  Under the N2xx/NI-292x Image Updater tab, the path to the most recent versions will be autopopulated.

[tintin99]

Hi Sarah,

Thanks for the link. I have installed the driver and now it works. The problem I have to implement FH is , I would like to change the centre frequency for every iteration inside the loop. I can change the Centre F for the first iteraion but in the second iteraion I get this error:

Error -1074118645 occurred at niUSRP Write Tx Data (CDB Cluster).vi

Possible reason(s):

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.

While the IQ rate is 1 MS/s , time out is set to be : -1  . I think it might be a limitation of the usrp so I can't change the carrier frequency that fast. What do you think?

How fast can I change the centre frequency on fly inside when I want to transmit IQ data?

I think enough time should be given to the LO to lock and so it might not be possible to change the carrier frequency in a fraction of ms. Am I right?

And if this is true then is the USRP a good device to implement FH while we see in Blutooth it is possible to hop 1600 times in a sec!

[Sarah_Y]

Hey tintin99,

I don't have a spec'd number for how fast the LO can hop, but that has nothing to do with the Tx error that you are getting.

I did some benchmarking on how fast I could change the LO.  I was able to change the frequency and get an LO lock within 0.001 ms.  I'm not sure how fast you want to push the device, but if you have too much processing in your loops, they will be the bottleneck, not the LO frequency change.

A Tx buffer underflow happens when there is not data being sent to the Tx loop fast enough.  This can happen if you have any sort of processing in your Tx loop and it takes longer to do the processing than it does for all of the data to be transmitted.  I would highly recommend using queues and a producer consumer architecture to help get around this issue.  If your LO is not locking because you are trying to change it too fast, the driver will return an error with something like "The LO did not lock within the specified time."

[tintin99]

Hi Sarah,

Somthing in fraction of a ms is exactly what I am looking for but as I mentioned I don't know why I can't achive it and the loop run just one time and then I get that error.

Please take a look at this simple example attacehd to this post. As can be seen there is no processing at all in this loop but I still get that error in the second iteration.

I have also used a control to see whether I can change the carrier frequency while the driver is in use and it works without any problem: meaning that the new driver is installed and works properly

but I can't do hopping when I want to change the carrier frequency in every iteration!

I use N210 not 2921. Have you ever tried to implement this by N210. maybe this is the problem!

[Sarah_Y]

Hi tintin99,

Using an N210 is not a problem.  A 2920 is an N210 + WBX daughterboard and a 2921 is an N210 + XCVR daughterboard.  As I mentioned in my last post, the buffer underflow error has nothing to do with changing the frequency.  That error means that you are transmitting all of the data out of the buffer and not putting new data back into it in time to maintain the IQ rate that you are trying to transmit at.  Looking at your VI, you are trying to transmit 2 MS/s, but your waveform that you are generating is only 4092 samples.  You need to provide more samples to your buffer, or slow down your IQ rate to something around 200k which you probably don't want to do.  I didn't debug your packet creating VI, but one simple fix is to add more samples per symbol.  You will simply need to generate more samples in order to get rid of this error.

[tintin99]

HI Sarah,

First of all really sorry for asking so many questions.

I have changed the number of samples. For example I used 40000 samples for 200kS/s ( IQ rate) or 400000 samples for 1MS/s. It works without any problem and I can see the carrier frequency hop into different frequencies. But there are two problem.

1- As I mentieond before, I would like to transmit every packet at different Carrier frequencies. Consider I have 10 guard bits,20 Sync bits, then 200 message bits and finally 200 pad bits. In total 430 bits. Lets say the number of samples per symbol is 8. Finally the number of my IQ samples in one packet is less than 5000 samples and I would like to transmit this packet as fast as possible ( Highest sampling rate possible) . Now my question is , number of samples should be at least 40k to use 200k S/s IQ rate so how can I transmit 5000 samples!

The code works properly if I don't use the USRP Property node inside the loop to change the carrier frequency in fly but when I use this property node , as I said , for 200k S/s I should have atleast 40k samples. I would greatly appreciate your suggestions. How  can I transmit 5000 samples as fast as possible when I hop the frequency in fly.

2- I have used tick count function with shift register to measure the time delay between iterations in loop .When I transmit 400k samples at 1MS/s IQ rate. It takes about 400 ms. If I transmit 40k samples at 200k S/s it takes about 200ms to hop the frequency which is by far more than what I expected. I thought I can hop in a fraction of ms. Is it a limitation of the USRP? Would you please run the attached code to see how long does it takes for you

Many thanks Sarah

[Sarah_Y]

Hey tintin99,

To address question 1, you will have to use the "end of data?" option to let your device know that it is only going to be transmitting one packet so it doesn't give an underflow.  See the VI I attached in this post.  It should help, but it's still tricky to get functioning correctly. 

I get more or less the same times that you do, and I get them regardless of whether or not I have the Carrier Frequency property node in the loop.  If you think about it, you are sending 400k samples.  At 1MS/s, it takes 400 ms to transmit that many data points.  Same for 40k at 200k S/s, it takes 200 ms to transmit 40k samples.  If you send you 5k packets, it will not take as long.

Check out my "bursty demo" code.  That should be what you need.  It should be fairly easy to modify for what you need, but will probably take some tweaking to get everything working perfectly.

[tintin99]

Hi Sarah,

Sorry I was away for few weeks and I didn't have access to LabVIEW and USRPs to test your suggestions.

For question 1, as you said , I wired "true" to  "end of data?" terminal to show that one packet transmission is complete. using this method I didn't get underflow error but the problem is when the end of data? is false it takes about 1 ms to complete 1 itteration inside the TX loop but when I wire true the time it takes is about 54 ms

and when I change the carrier frequency to implement FH this time becomes 140 ms which is by far more than FH standards.

From the help:

TRUE	Specifies that the data input contains the end of the data transmission. The transmission aborts when the last data sample generates.

I think when the end of data is true , LabVIEW aborts the usrp session as well . Have you faced this problem?

Good things is , as you mentioend, there is no underflow problem but the time to change the centre frequency on fly is too much.

Regarding question 2, you are completely right . Would you please check my code ( attached to the previous posts) to see how much does it takes for you to complete one iteration in while loop . As I mentioend for me is 54ms.

and thanks for the bursty demo example. I try to learn and get some idea from it.

many thanks