Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
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! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
Oooh, is there a configurable parameter for that in GRC yet? On Wed, 25 Apr 2012 11:33:34 -0700, Josh Blum wrote: Also, I want to point out: There is a hook to control the size of these buffers in gnuradio (presumably to reduce flow graph latency). You may be interested in modifying this number and experimenting: void start(int max_noutput_items=10); http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63 [1] -Josh Links: -- [1] http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
On 04/25/2012 11:53 AM, mle...@ripnet.com wrote: Oooh, is there a configurable parameter for that in GRC yet? Not yet. It would fit well in the options block. Pretty easy to add, but it would be a little more change to get the parameter into the WX gui top block class. Qtgui and nogui mode both directly call the flow graph start/run method, so the code change is purely in the generator. -josh On Wed, 25 Apr 2012 11:33:34 -0700, Josh Blum wrote: Also, I want to point out: There is a hook to control the size of these buffers in gnuradio (presumably to reduce flow graph latency). You may be interested in modifying this number and experimenting: void start(int max_noutput_items=10); http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63 [1] -Josh Links: -- [1] http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63 ___ 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
Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
original mail-- Message: 11 Date: Fri, 13 Apr 2012 08:25:36 -0700 From: Josh Blumj...@ettus.com To:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure Message-ID:4f884570.5010...@ettus.com 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about USRP2 Tx procedure
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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
Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
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
Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
On 04/13/2012 08:36 AM, Nowlan, Sean wrote: 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)? Yes, you can wait on the message queue. In pseudo code: top_block.start() while True: sleep(.01) # just a bit msg = the_msg_queue.delete_head() if not msg: continue if parse(msg) == ACK: break top_block.stop() top_block.wait() The msg is kind of a blob of bytes with this struct, so you have to write parse(): http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1async__metadata__t.html --- I have a version of the async message source that uses the PMT message passing feature, so its a little more graceful: https://github.com/guruofquality/grextras/blob/master/include/gnuradio/extras/uhd_amsg_source.h Your message would be a PMT dictionary that you can pop-apart in python: https://github.com/guruofquality/grextras/blob/master/lib/uhd_amsg_source.cc#L68 Does UHD also ACK time tags and start-of-burst tags? Just the end of burst. I can image that it might be useful to know when the USRP began triggering the transmission. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
