discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Question about USRP2 Tx procedure


From: Pan, Luyuan
Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
Date: Sat, 14 Apr 2012 20:40:14 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1

------------------------original mail----------------------------------
Message: 11
Date: Fri, 13 Apr 2012 08:25:36 -0700
From: Josh Blum<address@hidden>
To:address@hidden
Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
Message-ID:<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1


On 04/13/2012 06:54 AM, Pan, Luyuan wrote:

Hi everyone,
     I now have some trouble in understanding how the usrp2 sent out the
data. My scenario of the test is:
We tried to control the usrp2 to transmit in a fixed time slot, such as
5 seconds. The code is:
     tb = usrp.transmit_path()       # Create the path
     t1 = time.time()
     tb.start()
     while (time.time() - t1<   5):
         ..............              # The code to send out the data
         continue;
     time.sleep(0.65)                # to ensure all the data are sent
truly out......... Question?????? WHY
     tb.stop()
     tb.wait()
My question lies in line time.sleep(0.65). if we don't use time.sleep(),
we can not receive all the packets, every time the receive side will
lose about 50 packets(each one is 1500 bytes), and if
time.sleep()<0.65s, it will still lose but less than 50. So, I want to
know why it need such a time(about 650ms)? And we have some hypotheses:
     1. The usrp did not send out data instantly at tb.start(), it need
time to build the flow graph. But we do an experiment to get the time we
received the first packet, and found the truth is not that. The time
tb.start and (in the recv side)the time we received the packet is almost
the same. So, It send out immediately.
     2. But we encountered another dilemma, if we let it send an
extremely short time, like while (time.time() - t1<   0.02) (generally
less than 50 packets), and do not use time.sleep(), it will never send
out the data. Only add time.sleep(), it will success. Why? I really
confused!~
     3. Considering that we only need 650ms, no matter how long we
send(like 10s or more). We guess there is a fixed size cache in the usrp
and it send the cached data at a precise-controlled time, but I can not
persuade myself.
Can anyone interpret the strange phenomenon? Any suggestion is
appreciated, thank you!!

The is buffering in the USRP2, about 1 MB. Give your sample rate and 4
bytes per sample you can approximate the sleep time.

The more proper way to do this is to send an end-of-burst tag with the
last sample and to wait on the async message queue for a burst ACK packet.

About the TX tags for the sink block:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n52

Also see the async message source:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_amsg_source.h

-josh

----------------------------------------------------------
Hello,
    In order to find out the reasons, today we did another test, we used 
wireshark to capture the data through the wEthernet card. But, we guess the 
problem may lies in the FIFO in the software side, the scenarios are:
1. we use while (time.time() - t1<  0.05) and no time.sleep(), then the receive 
side can get only one packet. the useful data through the Ethernet is about 55 
packets(not take into account the packet less than 1498 bytes, we consider them as 
the control info).
2. we use while (time.time() - t1<  0.05) and time.sleep(0.65), so we can 
receive all the data(10 packets). And the data through the Ethernet is nearly 600 
packets. For the fact 1/10 almost equals 55/600, we think USRP2 send the data out 
immediately after he get it from the host PC. The main problem now is for some 
unknown reason the PC did not pass the data to USRP2, so he has nothing to send.
Did I misunderstand something or some other reasons? Thank you for your help!

--
Best regards,
Pan, Luyuan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]