discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] tx_empty in fpga


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] tx_empty in fpga
Date: Sun, 14 Jan 2007 13:00:16 -0800
User-agent: Mutt/1.5.9i

On Sun, Jan 14, 2007 at 12:45:48PM -0800, Matt Ettus wrote:
> Eric Blossom wrote:
> >
> >
> > This could work, with two caveats:
> >
> >   (1) you're stuffing 0's into the input of the signal processing
> >       chain, instead of handing the underrun at the output of the
> >       signal processing chain.   With the existing code, you're
> >       probably OK, but in general, if the idea is to zero the output
> >       when there's no input, I'd prefer to do it closer to the DACs.
> >       [ Don't let this comment stop you from trying this ;) ]
> >   
> 
> Have to disagree with you here.  The best place to do this is before the
> signal processing chain, for exactly the reasons you state below...
> 
> >   (2) You're going to get the equivalent of a "key click".  That is,
> >       wide band harmonics in the freq domain from the discontinuity in the
> >       time domain (step function).  It would be better to ramp the last
> >       value down, say be doing the equivalent of an arithmetic shift right
> >       by 2.  This really ought to be done by the code that feeds the DACs.
> >   
> 
> The key clicks will get filtered if you do this before the upconverter. 
> They'll still be there, but they'll only be as wide as the baseband
> bandwidth instead of the full 32 MHz.
> 
> > I think a better place to fix this would be to filter the output of
> > tx_a_a, tx_b_a, tx_a_b and tx_b_b in usrp_std.v based on their
> > previous values and the delayed value of tx_empty.  
> 
> You don't need this filter if you do it before the interpolators.
> 
> > I believe that a
> > delay on the order of 12 clocks is about right.  You'll need to count
> > pipeline stages through the tx path to get it right.
> >   
> 
> The delay through the interpolators is variable -- it depends on the
> intepolation ratio.  Again, this is why this should be done before the
> interpolators.

Agreed as long as the input being pushed into the signal processing
pipeline is interpreted as samples.  I think we're going to need to
visit this problem again when somebody put a modulator into the
FPGA.

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]