Re: [Discuss-gnuradio] Changing interp rate dynamically?

[Brian Padalino]

On 9/14/07, Michael Dickens <address@hidden> wrote:
> I've created an "analog repeater" that's just:
>
> usrp source -> amp -> usrp sink
>
> and I'd like to control the "bandwidth" that's repeated
> dynamically ... on the fly via a GUI slider.  I have created all of
> this, and on init everything works just fine.  But the moment I
> change the bandwidth value to -anything-, including the original
> values, the TX stops.
>
> I'm also displaying the output of the 'amp' on a waterfall scope, so
> I can see that the USRP source is generating data all of this time.
> It seems like the decim rate of the source is being changed properly.
>
> I've tracked this down through Python and C++, and everything looks
> OK .. nothing else is touched in the process of setting the sink's
> interp rate.  In usrp_standard_tx::set_interp_rate, an FPGA register
> is changed to reflect the new interp rate; I haven't tried tracking
> down that side of things, since I've never investigated FPGA code and
> really don't have time to right now.
>
> Hence the question for folks who hopefully know better: Can the
> interp rate be changed dynamically ... after its original init?  I
> should think this would be OK, but obviously it's not working for
> me.  Thanks in advance! - MLD

For informational purposes, the interpolation strobes and filtering
modules are found here:
    
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/master_control.v
    
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/cic_interp.v
    
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/strobe_gen.v

The register is a simple register updated once the serial data is
properly written (read: atomic operation).  The strobe_gen is a
downcounter which resets to the input of whatever that rate register
is feeding the module when the counter gets down to 0.

>From a quick look, I don't see any reason why it couldn't be
dynamically changed.  It might cause some strange results while the
pipeline still has things sampled at two different sample frequencies,
but I don't think it should hang.

Brian