USRP Software Radio

cancel
Showing results for 
Search instead for 
Did you mean: 

Questions about Packet-based Digital Link Example

I have two questions about the Packet-based Digital Link Example which is listed in https://decibel.ni.com/content/docs/DOC-18801.

 

I. Why do we need to send the data a second time?

II. Is there a way to see which packet is being sent right now? I have no idea how to get that information out of a queue or the cluster data.

 

for-loop.png

0 Kudos
Message 1 of 12
(7,995 Views)

Sorry, I can't edit my thread, so here is another question relating to the Packet-based Digital Link Example.

 

These are my modifications:

 

1. The while-loop for enqueueing an element stops after all message packets are in the queue.

2. The other while-loop stops when there are no more data inside the queue (variable 'End counter').

3. The carrier frequency is incremented with every loop iteration.

4. The message text is longer, but that does'nt matter.

 

This vi only work for a Tx IQ Sampling Rate [s/sec] of maximum 200k. 

 

My problem is that the vi sometimes works, sometimes not. If you run the vi a couple times, you can see what I mean.  Everytime it isn't working, the following error message appears.

 

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.

 

My goal is to send every packet only one time and to see how much packets the receiver USRP receives correctly.

0 Kudos
Message 2 of 12
(7,985 Views)

Hey YYY,

 

Just one thing I noticed as I started putting various indicators in your VI and the original Packet TX VI is that the original always keeps 10 elements in the queue.  With yours, even when I go onto the debugging tab and increase the queue length, I still see the queue fill up once and then go back down to zero.  I removed the portion of the code that stops the enqueueing loop and still see this.  I haven't looked at all the other changes you made yet, but that seems to indicate there is a problem with the rate that the data is being supplied to the queue.  Also, you seem to have edited the subGeneratePackets.vi, would you mind posting your updated copy?

 

I'll be looking into this more, just wanted to give you an update on what I think the likely cause is based on what I am seeing at the moment.

Sarah Yost
Senior Product Marketing Manager
0 Kudos
Message 3 of 12
(7,980 Views)

Hi Sarah,

 

to prevent any mistakes of subVI-modifications I have decided to download the example again and start over and it works.

 

These are my modifications:

 

1. The while-loop for enqueueing an element stops after all message packets are in the queue.

2. I'm using the False-case to see how many packets were sent.

3. With deenqueueing an element the carrier frequency is incremented by 1MHz

 

Now the vi only also sometimes work for a Tx IQ Sampling Rate [s/sec] of 500k. 

mod_2.PNG

 

When I deactivate the frequency incrementation to see how many packets the receiver gets, the receiver receives maximum 22 of 46 packets by packet repeat = 2. I have to increment the packet repeat to receive more packets. What are the reasons for this problem? I tought it should be possible to receive everything correct by sending each packet only once.

 

0 Kudos
Message 4 of 12
(7,973 Views)

It looks like nobody can help me. So I will explain it again. I guess the frequency incrementation is irritating. So I removed the incrementation. These modifications remain:

 

a.) The while-loop for enqueueing an element stops after all message packets are in the queue.

 

b.) I'm using the False-case to see how many packets were sent. This is possible when the queue length = 1. 

 

mod_3.PNG

 

I'm doing this to see how many packets can be received when they were sent only once. The receiver receives maximum 22 of 46 packets by packet repeat = 2. I have to increment the packet repeat to receive more packets. What are the reasons for this problem? I tought it should be possible to receive everything correct by sending each packet only once.

 

0 Kudos
Message 5 of 12
(7,954 Views)

Hello YYYs,

 

We were actually talking about this problem last week.  I have a strong feeling that only part of the packet is being received. 

 

Take a look at the time domain signal that the receiver is placing into the shift register, you may find that only part of the signal is being captured.

Anthony F.
Staff Software Engineer
National Instruments
0 Kudos
Message 6 of 12
(7,947 Views)

I changed my last vi a little bit. I found a mistake. The transmitter sent actually only 45 of 46 packets. I simplified my modifications. These modifications remain:

 

a.) The transmitter stops after sending all packets once. To make sure that the loop will be left after sending the last packet I used another "or comparison". Otherwise the loop will be left immediately after the Number of Packets in Message and Packets send comparison is true. In that case 46 packets were dequeued, but only 45 were sent. 

 

Now the transmitter really sends 46 packets. With Tx IQ Sampling Rate [s/sec] = 1M and packet repeat = 1 the receiver is also able to receive 46 packets. But this works only once in 20 tries. With Tx IQ Sampling Rate [s/sec] = 500k I was able to receive 43 packets.

 

I hope you can help me further.

 

Thanks

0 Kudos
Message 7 of 12
(7,941 Views)

I would be very thankful if somebody could explain me why it is not possible to receive all packets by sending them only once.

 

0 Kudos
Message 8 of 12
(7,885 Views)

Hello YYYs,

 

I have been able to receive all packets successfully with just one transmit if I adjust the Acquisition Duration control in the RX Parameter tab to a lower value such as 20 mS or 10 mS.

 

Since the USRP does not have a large onboard buffer, it is necessary to call the Fetch RX Data VI as quick as possible to avoid losing any part of the data stream.  Because the demodulation, resampling, and reordering all happen in the same loop as the Fetch RX Data VI, it is prone to losing parts of the data stream as these functions take some time to complete.  You can notice this delay if you set a large Acquisition Duration such as 1 second.

 

A better method would be to implement a producer consumer architecture so that the data retrieved from the USRP is not disturbed by the processing functions.  I believe also that the resampling and demodulation VIs that were written for this example work better on smaller acquisitions.

 

Try running the original receiver VI with a lower acquisition duration and post your findings back here.

Anthony F.
Staff Software Engineer
National Instruments
0 Kudos
Message 9 of 12
(7,879 Views)

Hello Anthony,

 

thank you for your answer. Especially the information about Fetch RX Data. How big is the onboard buffer?

 

I have tried to change the acquisition duration, but there were no improvements. Have you used the USRP Packet Tranmitter_mod_4_1.vi from my previous post? How are the Tx Parameters?

0 Kudos
Message 10 of 12
(7,875 Views)