Re: [Discuss-gnuradio] reset streaming vector/block

[Josh Blum]

On 08/08/2012 03:28 PM, Kinal, George V. wrote:
> We have an application which uses the uhd.usrp.sink3 block, with
> io_type.COMPLEX_FLOAT32.  The complex vector is converted from a
> text-based I-Q file. It is then sent to the sink with the assignment
> self._src = gr.vector_source_c(z, True).
> 
> As I understand the documentation, the Boolean True parameter means
> that USRP should continually/repeatedly re-transmit the same signal.
> 
> Transmission is started using  tb.start(), time.sleep(1), and
> streaming= True statements.
> 
> Transmission (called "streaming") is stopped with  tb.stop() ,
> tb.wait(), tb.set_vector(), and streaming=False statements.
> 
> (Note tb=my_top_block(), which is gr.top.block class).
> 


Basically, you do not want to use gnuradio like this. Starting and
stopping the flow graph is not a practical thing. And vector source is
really only for test purposes.

It sounds like you want to perform controlled sample bursts. For this,
you will want to create a source block that produces the desired samples
with metadata tags.

There is a good tags demo example to demonstrate this usage:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNU_Radio_UHD#Using-UHD-with-GNU-Radio

And more about tags here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide#Stream-Tags

-josh

> 
> 1. Not sure why the time.sleep(1), or the tb.wait() statements are
> even necessary.
> 
> 2. But more importantly, it seems that if we change the parameters
> which affect the vector (including the filename used as the source),
> the tb.set_vector() statement seems to have no effect on the signal
> when transmission is resumed.  It appears that once the vector has
> been sent to the USRP (once), it cannot be reset except by a complete
> re-start of the entire program/script. In other words, tb.stop is
> really tb.pause .
> 
> Is there a better way ?   (Note:  changing other parameters, such as
> preamp and gain, does have the proper effect.  I surmise that the
> stream is buffered in USRP memory and cannotsimply be  over-written.
> Is that true ?
> 
> 
> George Kinal Lead Engineer MITRE E531 Signal Processing and
> Communications Analysis Phone (703) 983-7585
> 
> ************************************************
> 
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>