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: baobaonanpo D
Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
Date: Wed, 25 Apr 2012 20:45:40 +0800

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


Dear josh,

  Thanks for your help very much!

  But I still have puzzles about the extra time such as 0.65s when I set the bit rate to 1M. we set the program to send 4s, and use wireshark and find the data through the network card continued for 4.65s, it indicates that the data be sent the last 0.65s is still in PC, in GNU-Radio's FIFO, not in USRP's buffer. Is it?

  If so, why we use half the time, that is the time changed from 0.65s to 0.32s when we set the bitrate from 1M to 2M?  the data proceed in PC should be fixed and unrelated to the transmission rate, and much lower than the transmission rate, so the time processing the same amount data which stored in gnuradio's FIFO must be still 0.65s, is it?

Thanks very much again!

Best regards and good luck!




reply via email to

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