Re: [Discuss-gnuradio] gr_firdes.cc/firdes.cc - window functions - flawe

[Tom Rondeau]

On Mon, Oct 7, 2013 at 12:02 AM, bob wole <address@hidden> wrote:
> We installed gnuradio 3.6.3 using gnruadio build script. We can't change the
> gnuradio version currently. How can we apply this patch to our installation.
> What commands should we run? We don't use git.
>
> --
> Bob

Hi Bob,

You'll use the 'patch' command for this.

1. Download the gnuradio-window-patch.diff from Chris' post (into
directory: ~/Downloads).
2. cd into the GNU Radio source directory (I'll assume the directory:
~/gnuradio-3.6.3)
3. Run: 'patch -p1 < ~/Downloads/gnuradio-window-patch.diff'

If it works, it will say:

patching file gnuradio-core/src/lib/general/gr_firdes.cc
patching file gr-filter/lib/firdes.cc


I just tried these steps on my own system using the 3.6.3 tarball from
our website.

However, I noticed that there is a problem with the patch in the
Kaiser window when the number of taps in the filter is odd. The patch
that I applied to maint/master/next (all 3.7) takes account of this
and works with both even and odd number of taps.

Also, many QA failures will occur with the patch because the Hilbert
transform assumed the use of a rectangular window. The results were
actually calculated using a Hamming window because of the bug, so
using the actual rectangular window will make the results different.
These are the QA failures I get with 3.6.3:

The following tests FAILED:
41 - qa_filter_delay_fc (Failed)
78 - qa_hilbert (Failed)
82 - qa_firdes (Failed)
92 - qa_filter_delay_fc (Failed)
101 - qa_hilbert (Failed)
Errors while running CTest


Again, the patch that I applied last week for 3.7 accounts for this
and fixes the QA code. I think it does so in a more elegant way, too,
and reduces many of our QA tests to comparing against a set of 'gold'
results to actually properly calculating the results.

To summarize. The patch from Chris will be ok (though watch for a
Kaiser window with an odd number of taps) but will cause the QA to
fail. You can safely ignore that as it's expected.

Tom



>  On Sun, Oct 6, 2013 at 12:39 PM, KB3CS - Chris <address@hidden> wrote:
>> (If you just want to cut to the chase, the diff against 3.6.5.1 is
>> attached)
>>
>> How i got here:  Contemplating some filters using gnuradio-companion with
>> a
>> simple flowgraph (simple enough to describe in words alone).  Noticed the
>> frequency response with a Rectangular filter was exactly the same as with
>> a
>> Hamming filter and also the response with a Kaiser filter (while varying
>> Beta) seemed quite wrong.
>>
>> The flowgraph:  noise source -> throttle -> filter -> FFT
>> really basic.  used the "convenience" blocks which are wrappers for
>> firdes.
>>
>> After quite a while of scratching my head at the odd results observed,
>> then
>> checking (and double-checking) Oppenheim[1999] and others, I wrote a
>> little
>> python to have a direct look at the window function coefficients:
>>
>> #!/usr/bin/env python
>> from gnuradio import gr, audio
>> from math import pi
>>
>> sample_rate = 192000
>> ntaps = 16
>>
>> #channel_coeffs =
>> gr.firdes.low_pass(1.0,sample_rate,50e3,4e3,gr.firdes.WIN_HAMMING,beta)
>>
>> #print channel_coeffs
>>
>> #channel_coeffs =
>> gr.firdes.low_pass(1.0,10,1,1,gr.firdes.WIN_HAMMING,beta)
>>
>> #print channel_coeffs
>>
>> print "\n\nRectangular window function for {} samples\n".format(ntaps)
>>
>> win_coeffs = gr.firdes.window(gr.firdes.WIN_RECTANGULAR,ntaps,0)
>>
>> print win_coeffs
>>
>> print "\n\nHamming window function for {} samples\n".format(ntaps)
>>
>> win_coeffs = gr.firdes.window(gr.firdes.WIN_HAMMING,ntaps,0)
>>
>> print win_coeffs
>>
>> print "\n\nKaiser window function for {} samples\n".format(ntaps)
>>
>> alpha = 1.0
>> print "Alpha = {}\n".format(alpha)
>> win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)
>>
>> print win_coeffs
>>
>> alpha = 2.5
>> print "\nAlpha = {}\n".format(alpha)
>> win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)
>>
>> print win_coeffs
>>
>> alpha = 8.0
>> print "\nAlpha = {}\n".format(alpha)
>> win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)
>>
>> print win_coeffs
>>
>> alpha = 20.0
>> print "\nAlpha = {}\n".format(alpha)
>> win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)
>>
>> print win_coeffs
>>
>> print "\nDone\n"
>>
>> .. and here's the essential extract of output from unmodified v3.6.5.1
>> source:
>>
>> Rectangular window function for 16 samples
>>
>> (0.07999999821186066, 0.11976908892393112, 0.23219992220401764,
>> 0.39785218238830566, 0.5880830883979797, 0.7699999809265137,
>> 0.9121478199958801, 0.9899479150772095, 0.9899479150772095,
>> 0.9121478199958801, 0.7699999809265137, 0.5880830883979797,
>> 0.39785218238830566, 0.23219992220401764, 0.11976908892393112,
>> 0.07999999821186066)
>>
>>
>> Hamming window function for 16 samples
>>
>> (0.07999999821186066, 0.11976908892393112, 0.23219992220401764,
>> 0.39785218238830566, 0.5880830883979797, 0.7699999809265137,
>> 0.9121478199958801, 0.9899479150772095, 0.9899479150772095,
>> 0.9121478199958801, 0.7699999809265137, 0.5880830883979797,
>> 0.39785218238830566, 0.23219992220401764, 0.11976908892393112,
>> 0.07999999821186066)
>>
>>
>> Kaiser window function for 16 samples
>>
>> Alpha = 1.0
>>
>> (1.0, 0.9949779510498047, 0.9800193309783936, 0.9554436802864075,
>> 0.9217740297317505, 0.8797227740287781, 0.8301725387573242,
>> 0.7741525173187256, 0.7128111124038696, 0.6473857760429382,
>> 0.5791705250740051, 0.5094824433326721, 0.43962839245796204,
>> 0.3708721101284027, 0.3044034540653229, 0.241310253739357)
>>
>>
>> ... the Rectangular coefficients aren't right.  And sure, it's really
>> weird
>> the coefficients are the same as for the Hamming window.  But look at the
>> Kaiser coefficients!  (this was giving me an awful headache and bothering
>> me
>> to no end).
>>
>> With a little help from octave and some quick cut-n-pastes, I was now
>> contemplating graphs of window functions.  The Kaiser window function
>> didn't
>> look right at all.  It started a 1.0 and tapered toward zero.  No starting
>> near zero and tapering -up- toward 1.0 present. That can't be right, can
>> it?
>> Well, no, it can't.  Hmm!
>>
>> Glossing over the many hours it took from the start of this journey to its
>> conclusion, I present the essential extract of output from v3.6.5.1 source
>> modified by the diff attached to this message:
>>
>> Rectangular window function for 16 samples
>>
>> (1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0,
>> 1.0,
>> 1.0)
>>
>>
>> Hamming window function for 16 samples
>>
>> (0.07999999821186066, 0.11976908892393112, 0.23219992220401764,
>> 0.39785218238830566, 0.5880830883979797, 0.7699999809265137,
>> 0.9121478199958801, 0.9899479150772095, 0.9899479150772095,
>> 0.9121478199958801, 0.7699999809265137, 0.5880830883979797,
>> 0.39785218238830566, 0.23219992220401764, 0.11976908892393112,
>> 0.07999999821186066)
>>
>>
>> Kaiser window function for 16 samples
>>
>> Alpha = 1.0
>>
>> (0.6473857760429382, 0.7741525173187256, 0.8301725387573242,
>> 0.8797227740287781, 0.9217740297317505, 0.9554436802864075,
>> 0.9800193309783936, 0.9949779510498047, 1.0, 0.9949779510498047,
>> 0.9800193309783936, 0.9554436802864075, 0.9217740297317505,
>> 0.8797227740287781, 0.8301725387573242, 0.7741525173187256)
>>
>> Alpha = 2.5
>>
>> (0.2832930386066437, 0.47887080907821655, 0.5863785147666931,
>> 0.6930355429649353, 0.7924286127090454, 0.8780854940414429,
>> 0.9441056251525879, 0.9857622385025024, 1.0, 0.9857622385025024,
>> 0.9441056251525879, 0.8780854940414429, 0.7924286127090454,
>> 0.6930355429649353, 0.5863785147666931, 0.47887080907821655)
>>
>> Alpha = 8.0
>>
>> (0.01416657492518425, 0.083808533847332, 0.16599954664707184,
>> 0.29149267077445984, 0.45759791135787964, 0.6461663842201233,
>> 0.8243628740310669, 0.9529938697814941, 1.0, 0.9529938697814941,
>> 0.8243628740310669, 0.6461663842201233, 0.45759791135787964,
>> 0.29149267077445984, 0.16599954664707184, 0.083808533847332)
>>
>>
>> ... there you have it, folks. I've heard it said "it's a jungle in there"
>> (referring to the gnuradio codebase), to which I replied, "yeah and there
>> are hidden stone walls, too".  I'm glad to have had the opportunity to
>> remove one of the stone walls.
>>
>> [second attempt to post due to recent gnuradio.org domain issue]
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>