discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] High Pass and Low Pass performance not inverse


From: CEL
Subject: Re: [Discuss-gnuradio] High Pass and Low Pass performance not inverse
Date: Tue, 13 Mar 2018 16:58:56 +0000

Andy,
hm, should we at least be warning about HPFs that cut off below f_s/2?

John,

I might argue that in this specific application, the idea of "hey,
let's just subtract what we don't want" wouldn't be the worst idea;
Simply something like


input --+-->LPF---+---> Sig1
        |         |
        |         v⁻
        \-Delay->(+)---> Sig2

should work, if your LPF is linear phase and you set your Delay block
to its group delay (i.e. half order).

Best regards,
Marcus

On Tue, 2018-03-13 at 09:41 -0400, Andy Walls wrote:
> > From:       John Ackermann N8UR
> > Date:       Tue, 13 Mar 2018 09:15:33 -0400
> > I'm setting up a measurement program to look at the channel power
> > inside and outside a defined bandwidth centered at zero. The idea is
> > to get the ratio of the power within a low pass filter (nominally 500
> > Hz), and the power in the rest of the spectrum (192 kHz) with that
> > same 500 Hz chunk notched out. Attached are a screenshot of the the
> > flowgraph and of an FFT showing the results.
> > 
> > 
> > What puzzles me is that the low pass filter has a defined flat-top,
> > while the high pass filter shows a very narrow notch. I would expect
> > the two to have a similar shape. (I'm using rectangular windows
> > because I want to get the actual noise power for the given
> > bandwidth.)
> > 
> > 
> > Any thoughts on why this is happening, or on ways to make the two
> > responses more precisely mirror each other?
> 
> I think this is the skirt of the HPF (with real taps) folding at DC,
> i.e. an alias.
> 
> Try with the equivalent 1-sided HPF (with complex taps) and see if it's
> more vertical on the transition.  If it is, then you know.  But,
> unfortunately cascading two 1-sided HPFs (one for positive freqs, one
> for negative freqs) won't fix your problem.
> 
> Regards,
> Andy
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

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