discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] Question about USRP2 Tx procedure


From: Pan, Luyuan
Subject: [Discuss-gnuradio] Question about USRP2 Tx procedure
Date: Fri, 13 Apr 2012 21:54:11 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1

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!!

--
Best regards,
Pan, Luyuan



reply via email to

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