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

On 04/13/2012 06:54 AM, Pan, Luyuan wrote:

    continue;

time to build the flow graph. But we do an experiment to get the time we
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

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

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:

Your message would be a PMT dictionary that you can pop-apart in python:

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

Josh B. wrote in post #1056362:

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:

Your message would be a PMT dictionary that you can pop-apart in python:
grextras/lib/uhd_amsg_source.cc at master · guruofquality/grextras · GitHub

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

Hi,
josh, I am puzzle about when does the data stored in the buffer in the
USRP to be sent out, once there is some data in the buffer or wait until
the buffer to be filled?
If letting USRP 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 not send out the data. but if (time.time() - t1<
  1. (generally more than 50 packets),it send data at once. What
    difference?
    And in the first situation, if I use end-of-burst tag, it will send
    the small amount data at once like the second situation?
    Maybe I must do some experiments first, Hey!
    Thanks very much, have a nice weekend!