I missed the gnuradio mailing list. On Mon, May 6, 2013 at 10:37 AM, Josh Blum <[email protected]> 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
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
