[Discuss-gnuradio] Fwd: scheduled transmission using tx_timed_samples.cpp

[Sam mite]

I missed the gnuradio mailing list.

On Mon, May 6, 2013 at 10:37 AM, Josh Blum <address@hidden> wrote:

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

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

Hi josh, thanks for your reply.

I created the usrp sink as follows:
uhd_usrp_sink_0 = uhd.multi_usrp_sink("addr=192.168.10.2", uhd.io_type_t.COMPLEX_FLOAT32 , 1)

then I tried to get tx_stream using the following command

stream_args= uhd.stream_args_t("fc32")

tx_stream=tb.uhd_usrp_sink_0.get_tx_stream(stream_args)

but it gives the following error:

tx_stream=tb.uhd_usrp_sink_0.get_tx_stream(stream_args)
AttributeError: 'uhd_usrp_sink_sptr' object has no attribute 'get_tx_stream'

Does this mean "get_tx_stream()" is not available in python? Also, can you please mention any python or GRC example that uses stream tags for transmission time control? That would be great help.

 

> 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

There is a switch involved between the PC and USRP. I think that could also affect the value. Right?

Best Regards,

Sam