[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
From: |
Josh Blum |
Subject: |
Re: [Discuss-gnuradio] Question about USRP2 Tx procedure |
Date: |
Fri, 13 Apr 2012 08:25:36 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 |
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