USRP Software Radio

cancel
Showing results for 
Search instead for 
Did you mean: 

How does Fetch Rx Data works?

Dear Sir or Madam,

 

I have a problem when I am implementing MAC protocols by using LabVIEW and USRP2. Actually there are two problem, I will show them in a simple CSMA protocol.

 

The first design is that in CSMA protocol, node 1 sent a data packet to node 2, and node 2 received the packet, analyzed it, and sent back a corresponding ACK. The problem is, node 2 need to switch between receiving mode (to receive the packet) and transmitting mode (to sent ACK back), and the switching time is non-neglectable (around 7 to 10 ms). That delay significantly decreases system performance. Is that any way to reduce the switching time?

 

The second problem is rising after the first one. To overcome the time delay, I use two antennas in the system, therefore one can always work in Tx mode and another in Rx mode therefore no switching is needed. The block diagram is simplified as figure (if transmitter mode is set to false, then the receiving VI works by using another antenna). CSMA__Transceiverp.png

The problem is, since we are using if structure, there is noway that transmitting and receiving can work concurrently. However, nodes always receive the signal it sent in the last while loop round. For example, after receiving a DATA packet from another node, this node sends a ACK back, and then the transmitter mode are switching to false then I can receive next packet. However, after sending the ACK, and switching to reception mode, I can receive the ACK I sent myself! That is my question, how does fetch Rx Data VI works?

 

Thank you very much!

0 Kudos
Message 1 of 9
(7,418 Views)

1. Rx Fetch data just get the samples from the PC memory when you call it, and the USRP will send the data continuous to PC memory through the Ethernet once you inite Rx session.

 

2. If you adopt burst transmission, the Rx to Tx delay is almost 55ms, and the Tx to Rx delay is 10ms, the CSMA protocol is not suit to realization on the USRP plantform if you can't program the FPGA.

 

3. Yun can ignore the Ack of youself through the control of the Rx session, you can abort it before your transmission ,and inite it after the transmission.

 

4. I hope NI or Ettus can give the parameters about the hardware such as the switch delay, bus delay, buffer delay , hardware abort,inite delay,  so we can know exactly what we can do with USRP.

 

5. Would you please post your Vi code, so I can know how can we improve the performace ?

Message 2 of 9
(7,411 Views)

Hi HustLiliAn,

 

Thank you very much for you quick reply. I have to say sorry that my code is only partially belonging to me so I cannot distribute all of them, beg your understanding:)

 

To overcome the delay, I open both Tx and Rx session at the beginning of the code so I don't need to initial and abort session before and after using respectively. It could save a lot of time (I measure the same delay as you shown). I read from WBX application notes (http://files.ettus.com/uhd_docs/manual/html/dboards.html) that if the system is working in the duplex mode, then antenna TX/RX is using for transmission and RX2 is using for reception. I simply tested it and it seems true.

 

Since two antennas are working concurrently, the receiving antenna (RX2) can receive packet even it is sent by TX/RX. My problem is, in software level I have used the if structure to make transmission and reception work successively, RX2 can still receive signal sent by TX/RX. That is the real problem. Probably we can write some compensation VI which we can remove it by using the transmitted signal, but I still want to know is there any official solution for it.

 

BTW, I use the modulation toolkit. Its demodulation VI is also quite slow.

 

Thank you for your reading. I am not a native English speaker, so if my post make you confuse, please let me know and I would like to elaborate it again.

0 Kudos
Message 3 of 9
(7,400 Views)

1. You mentioned you open the Tx and Rx session at the same time, I just wonder if you wirte the data into USRP slowly, whether  there will appear the underflow error ? To avoid this, I have to use the burst mode, making the "end of data"  property of write data.vi true. How can you avoid this if your process time of the receiving data is long?

 

2. You can not avoid the interference from software or hardware, maybe we can remove it by using TDMA(burst), FDMA(different carrier frequency) and CDMA.

 

3. The same feeling about the modulation toolkit, it is really very slowly. 30-50 ms to demodulate a 4096kbits packet. 

0 Kudos
Message 4 of 9
(7,396 Views)

I never had the underflow error before... What is that? I seperate the processing and receving functions into two while loops, therefore they can work concurrently.

 

BTW, I am still confused about the End of Data property. TRUE or FALSE make no sense In my code.

0 Kudos
Message 5 of 9
(7,393 Views)

when your vi switch to the receving state, after the Tx session send all data, and if there is no more data write into Tx buffer, the underflow error will appear.  

https://decibel.ni.com/content/docs/DOC-29883 you can refer this demo if you want to know the "end of data"

0 Kudos
Message 6 of 9
(7,390 Views)

Thanks! I will learn from the material you uploaded.

 

However, I found a post from you half years ago, http://forums.ni.com/t5/USRP-Software-Radio/Buffer-clear/m-p/2257844/highlight/true#M508

 

I think that is the exactly problem I want to ask. Do you get any idea from this post? Is there anyway to clear the buffer?

0 Kudos
Message 7 of 9
(7,384 Views)

Yes, I adopt the way of abort and inite as I mentioned before.

0 Kudos
Message 8 of 9
(7,379 Views)

Smiley Mad

 

Since I couldn't accept the delay of initial and abort, I started to find a way to overcome it. It seems that I turn back to the starting point. Thank you very much:) Xiexie!:)

0 Kudos
Message 9 of 9
(7,371 Views)