The time printed here after the ack is a little larger than 5 seconds,
so you can see that the USRP must have held off transmission until 5
seconds and then send the ACK for the end of burst.
-josh
Thanks josh, I got the idea. Also, I verified by looking at the LED “A” on
USRP N210, which lights almost after 5 seconds. 
I thought this should be discussed on gnruadio, so added gnuradio list.
I
want to convert tx_timed_samples.cpp into python. Can I do that? How can
I
make a “multi_usrp” ? Also, How can I use a block’s data instead of
buffer ?
e.g
tx_stream->send(DATA_FROM_SOME_BLOCK_IN_FLOWGRPAH, samps_to_send, md,
timeout);
Further, what could be the minimum value of “seconds_in_future” ? In my
case, When I set it to 0.3 or below I get following
Waiting for async burst ACK… fail
What does it mean ?
Thanks
–
Regards,
Sam
The gr-uhd blocks that come with gnuradio integrate the USRP streaming
into gnuradio’s data flow. You can create gnuradio blocks or use
existing blocks to interact with the USRP data streams. In addition, the
stream tags are used to control things like transmit time:
I think you will find some of the links here informative:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNU_Radio_UHD#Using-UHD-Software-with-GNU-Radio
Further, what could be the minimum value of “seconds_in_future” ? In my
case, When I set it to 0.3 or below I get following
Waiting for async burst ACK… fail
What does it mean ?
The time delta between time on the device and time on a packet about to
be sent can actually be on the order of 100s of microseconds. However,
in this example, there is an expensive operation of setting up the
transmit streamer thats happening with in the time specified, so I think
thats why you are seeing 300 milliseconds fail. I think the transmit
time in this case has become “late” when the USRP interprets the packet.
-josh