Re: [Discuss-gnuradio] Question about USRP2 Tx procedure

[Nowlan, Sean]

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: address@hidden [mailto:address@hidden On Behalf Of Josh Blum
Sent: Friday, April 13, 2012 11:26 AM
To: address@hidden
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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio