A few questions about this: can you wait on the uhd async message queue from a python script that has an instance of top_block? Would you have to override wait() with a custom version that waits on the queue (haven't checked if wait is a virtual function)?
Does UHD also ACK time tags and start-of-burst tags? Thanks, Sean -----Original Message----- From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org] On Behalf Of Josh Blum Sent: Friday, April 13, 2012 11:26 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
