Re: [Discuss-gnuradio] Filter in rational resampler

2014-10-28 Thread Jeff Long 
On Oct 27, 2014 6:36 PM, Jeff Long willco...@gmail.com wrote:

 On 10/27/2014 04:40 PM, Andy Walls wrote:

 On Thu, 2014-07-31 at 12:01 -0400, discuss-gnuradio-requ...@gnu.org
 wrote:

 Message: 5
 Date: Wed, 30 Jul 2014 18:42:14 +0200
 From: Daniele Nicolodi dani...@grinta.net
 To: GNURadio discuss-gnuradio@gnu.org
 Subject: [Discuss-gnuradio] Filter in rational resampler

 Hello,

 I was studying the code of the rational resampler block in
 gnuradio/gr-filter/pythoin/rational_resampler.py and I have a doubt
 about the low pass filter generated by the design_filter() function.

 It seems that the generated filter does not take into account the
 decimation factor. Is that correct? I don't see how this may result in
 the correct anti-aliasing filter when it is applied by
 rational_resampler_base_xxx.

 Can someone point me to a relevant explanation?

 Thanks a lot. Cheers,
 Daniele


 Daniele,

 I just had occasion to use the rational resampler for a 25 Ksps - 16
 Ksps resampling and low-pass filtering all in one step, with a LPF that
 cut off frequencies higher than 3000 Hz.  I started by using this
 expression for the taps, following the filter design in
 gr-filter/python/rational_resampler.py:

 filter.firdes.low_pass(16.0, 16000.0, 3250.0/16.0, 500.0/16.0,
filter.firdes.WIN_KAISER, 5.0)

 That filter only includes the interpolation factor, 16.0, and seemed to
 do the wrong thing.  The FFT scope showed the rolloff started at around
 ~4700 Hz, about 25/16 * 3000 Hz.

 This expression for the taps, which included the decimation factor of
 25.0, appeared to do the right thing:

 filter.firdes.low_pass(16.0, 16000.0, 3250.0/25.0, 500.0/25.0,
filter.firdes.WIN_KAISER, 5.0)


 Can someone else take a closer look at
 gr-filter/python/rational_resampler.py and confirm it is doing the wrong
 thing?

 Regards,
 Andy


 It looks like the default filter is only valid where interp  decim, and
it's not really meant to have an arbitrary cutoff. As Daniele pointed out,
decim is not taken into account.

 I think that 'interpolation' in design_filter() should be replaced with
'max(interpolation,decimation). If taps are supplied by the caller, it
needs to understand how the taps will be used.

 Andy, to mimic design_filter, you'd need to do:

   low_pass(16.0, 25000.0, 3250.0, 500.0, ...)

 Not that I know if that's right, but that's what design_filter() does.

Andy, ignore that last part. Your params are right and that filter actually
makes sense. The filter is applied after interp and before decim, which is
not obvious from the API.

- Jeff
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filter in rational resampler

2014-10-28 Thread Andy Walls 

From: 
Jeff Long
Subject: 
Re: [Discuss-gnuradio] Filter in
rational resampler
Date: 
Tue, 28 Oct 2014 04:31:30 -0400

 On Oct 27, 2014 6:36 PM, Jeff Long address@hidden wrote:
 
  On 10/27/2014 04:40 PM, Andy Walls wrote:
 
  On Thu, 2014-07-31 at 12:01 -0400, address@hidden
  wrote:
 
  Message: 5
  Date: Wed, 30 Jul 2014 18:42:14 +0200
  From: Daniele Nicolodi address@hidden
  To: GNURadio address@hidden
  Subject: [Discuss-gnuradio] Filter in rational resampler
 
  Hello,
 
  I was studying the code of the rational resampler block in
  gnuradio/gr-filter/pythoin/rational_resampler.py and I have a
 doubt
  about the low pass filter generated by the design_filter()
 function.
 
  It seems that the generated filter does not take into account the
  decimation factor. Is that correct? I don't see how this may
 result in
  the correct anti-aliasing filter when it is applied by
  rational_resampler_base_xxx.
 
  Can someone point me to a relevant explanation?
 
  Thanks a lot. Cheers,
  Daniele
 
 
  Daniele,
 
  I just had occasion to use the rational resampler for a 25 Ksps -
 16
  Ksps resampling and low-pass filtering all in one step, with a LPF
 that
  cut off frequencies higher than 3000 Hz.  I started by using this
  _expression_ for the taps, following the filter design in
  gr-filter/python/rational_resampler.py:
 
  filter.firdes.low_pass(16.0, 16000.0, 3250.0/16.0,
 500.0/16.0, filter.firdes.WIN_KAISER, 5.0)
 
  That filter only includes the interpolation factor, 16.0, and
 seemed to
  do the wrong thing.  The FFT scope showed the rolloff started at
 around
  ~4700 Hz, about 25/16 * 3000 Hz.
 
  This _expression_ for the taps, which included the decimation
 factor of
  25.0, appeared to do the right thing:
 
  filter.firdes.low_pass(16.0, 16000.0, 3250.0/25.0,
 500.0/25.0, filter.firdes.WIN_KAISER, 5.0)
 
 
  Can someone else take a closer look at
  gr-filter/python/rational_resampler.py and confirm it is doing the
 wrong
  thing?
 
  Regards,
  Andy
 
 
  It looks like the default filter is only valid where interp  decim,
 and it's not really meant to have an arbitrary cutoff. As Daniele
 pointed out, decim is not taken into account.
 
  I think that 'interpolation' in design_filter() should be replaced
 with 'max(interpolation,decimation).

Right, or something similar.  Basically design_filter() should design
the narrower of the required anti-image postfilter or anti-alias
prefilter.

Section 12.6 on page 691 of this book has a nice explanation:
http://www.ece.rutgers.edu/~orfanidi/intro2sp/
http://www.ece.rutgers.edu/~orfanidi/intro2sp/orfanidis-i2sp.pdf

I'll submit a bug to the issue tracker.

  If taps are supplied by the caller, it needs to understand how the
 taps will be used.
 
  Andy, to mimic design_filter, you'd need to do:
 
low_pass(16.0, 25000.0, 3250.0, 500.0, ...)
 
  Not that I know if that's right, but that's what design_filter()
 does.
 
 Andy, ignore that last part. Your params are right and that filter
 actually makes sense.

Yeah.  I experimentally knew what I had was right.  I just needed to go
back and confirm it, by reading my Orfanidis book to refresh my memory
on what I learned over 17 years ago. :P

FWIW, after the upsampling, for my specific case, the Fs of the filter
is 16 * 25000 sps.  So to get my desired 3000 Hz cutoff, which is
narrower than both the required anti-image and anti-alias filter
cutoffs, I should have used:

 low_pass(16.0, 16.0*25000.0, 3250.0, 500.0, ...)

but 

 low_pass(16.0, 16000.0, 3250.0/25.0, 500.0/25.0, ...)

is equivalent.

  The filter is applied after interp and before decim, which is not
 obvious from the API.
 
 - Jeff

Thanks for looking at this!

Regards,
Andy



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filter in rational resampler

2014-10-28 Thread Jeff Long 

On 10/28/2014 07:47 AM, Andy Walls wrote:


From:
Jeff Long
Subject:
Re: [Discuss-gnuradio] Filter in
rational resampler
Date:
Tue, 28 Oct 2014 04:31:30 -0400


On Oct 27, 2014 6:36 PM, Jeff Long address@hidden wrote:


On 10/27/2014 04:40 PM, Andy Walls wrote:


On Thu, 2014-07-31 at 12:01 -0400, address@hidden
wrote:


Message: 5
Date: Wed, 30 Jul 2014 18:42:14 +0200
From: Daniele Nicolodi address@hidden
To: GNURadio address@hidden
Subject: [Discuss-gnuradio] Filter in rational resampler

Hello,

I was studying the code of the rational resampler block in
gnuradio/gr-filter/pythoin/rational_resampler.py and I have a

doubt

about the low pass filter generated by the design_filter()

function.


It seems that the generated filter does not take into account the
decimation factor. Is that correct? I don't see how this may

result in

the correct anti-aliasing filter when it is applied by
rational_resampler_base_xxx.

Can someone point me to a relevant explanation?

Thanks a lot. Cheers,
Daniele



Daniele,

I just had occasion to use the rational resampler for a 25 Ksps -

16

Ksps resampling and low-pass filtering all in one step, with a LPF

that

cut off frequencies higher than 3000 Hz.  I started by using this
_expression_ for the taps, following the filter design in
gr-filter/python/rational_resampler.py:

 filter.firdes.low_pass(16.0, 16000.0, 3250.0/16.0,

500.0/16.0, filter.firdes.WIN_KAISER, 5.0)


That filter only includes the interpolation factor, 16.0, and

seemed to

do the wrong thing.  The FFT scope showed the rolloff started at

around

~4700 Hz, about 25/16 * 3000 Hz.

This _expression_ for the taps, which included the decimation

factor of

25.0, appeared to do the right thing:

 filter.firdes.low_pass(16.0, 16000.0, 3250.0/25.0,

500.0/25.0, filter.firdes.WIN_KAISER, 5.0)



Can someone else take a closer look at
gr-filter/python/rational_resampler.py and confirm it is doing the

wrong

thing?

Regards,
Andy



It looks like the default filter is only valid where interp  decim,

and it's not really meant to have an arbitrary cutoff. As Daniele
pointed out, decim is not taken into account.


I think that 'interpolation' in design_filter() should be replaced

with 'max(interpolation,decimation).


Right, or something similar.  Basically design_filter() should design
the narrower of the required anti-image postfilter or anti-alias
prefilter.

Section 12.6 on page 691 of this book has a nice explanation:
http://www.ece.rutgers.edu/~orfanidi/intro2sp/
http://www.ece.rutgers.edu/~orfanidi/intro2sp/orfanidis-i2sp.pdf

I'll submit a bug to the issue tracker.


Andy,

I already put a bug report in last night. Fix default filter, plus maybe 
documentation of what user taps really means.


- Jeff




  If taps are supplied by the caller, it needs to understand how the
taps will be used.


Andy, to mimic design_filter, you'd need to do:

   low_pass(16.0, 25000.0, 3250.0, 500.0, ...)

Not that I know if that's right, but that's what design_filter()

does.



Andy, ignore that last part. Your params are right and that filter
actually makes sense.


Yeah.  I experimentally knew what I had was right.  I just needed to go
back and confirm it, by reading my Orfanidis book to refresh my memory
on what I learned over 17 years ago. :P

FWIW, after the upsampling, for my specific case, the Fs of the filter
is 16 * 25000 sps.  So to get my desired 3000 Hz cutoff, which is
narrower than both the required anti-image and anti-alias filter
cutoffs, I should have used:

  low_pass(16.0, 16.0*25000.0, 3250.0, 500.0, ...)

but

  low_pass(16.0, 16000.0, 3250.0/25.0, 500.0/25.0, ...)

is equivalent.


  The filter is applied after interp and before decim, which is not
obvious from the API.

- Jeff


Thanks for looking at this!

Regards,
Andy





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filter in rational resampler

2014-10-28 Thread Lev Serebryakov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 28.10.2014 14:47, Andy Walls wrote:

 Right, or something similar.  Basically design_filter() should
 design the narrower of the required anti-image postfilter or
 anti-alias prefilter.
 
 Section 12.6 on page 691 of this book has a nice explanation: 
 http://www.ece.rutgers.edu/~orfanidi/intro2sp/ 
 http://www.ece.rutgers.edu/~orfanidi/intro2sp/orfanidis-i2sp.pdf
 
 I'll submit a bug to the issue tracker.
 So, I'm not mad, and understand this problem right (see my message
without answer with subject rational_resampler vs pfb_arb_resampler
filter design -- why such strange cut frequencies in both cases?), good.

- -- 
// Black Lion AKA Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJUT4VQXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePlOkP/2bV9N3BYUv3PD8lkw+p9fe9
HQ1p9mnwuKOkhOulZK4bA2Nd00/KsnpsBQ1kNtSdCiH5ikkbvIXNgPvSjXi/5U5I
0kFypk75TAI7Lubvzv9+uoIP3N2CenpbfYv9d1UhYoZA+agdk3aO4vwi1HpcmVwP
DG1SOmpmqNFPh0cVEaF35AuOCFdm1ieLwHQjloBA1uh8IyeMNvpons7upPVmUWOq
Bb2NyuidftOzc8zDtw/GJ2rDMp/MAJuZthoRKE9wZ+3IP7ellec0n+B6bNCnqGAR
aP094kdYgRkd7ydDX9lXRuE3ponSgOILbYQfKrdYtIxfEiTBVgyr6VxNOEXMt5jx
QOqSx1/GT9i7j94mZwOLGU03G2DrgzhhTBJLK9EyLTrOrGb63oa5vUn8Qil3cQna
F3aDEV/x5MwuN/Yhq8h6Vx6uvqIrsoke90kHty0bmuczk4DTMeF0Iy7kAYHKNhq3
jl/urV4eKGYBFjFUTUGFW93BNXjNUsiFM1kMNAmXRbvSlMr33kKAso4tHl+1SmSn
8uj7rVbNrJNa8Cn7Y96GcccVGDpKENXslNj0HtpL+86VhyR9PrBytesBFJVbWFh6
nh3mhD2NZXCEA4T0fKRZNiD2+Sc2M1nDGFrueyD3yfzYheTMW4IbOIKZK9/tDWxa
c5RMvdetxkJb0xE1LMxv
=bZiC
-END PGP SIGNATURE-

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filter in rational resampler

2014-10-27 Thread Andy Walls 
On Thu, 2014-07-31 at 12:01 -0400, discuss-gnuradio-requ...@gnu.org
wrote:

 Message: 5
 Date: Wed, 30 Jul 2014 18:42:14 +0200
 From: Daniele Nicolodi dani...@grinta.net
 To: GNURadio discuss-gnuradio@gnu.org
 Subject: [Discuss-gnuradio] Filter in rational resampler
 
 Hello,
 
 I was studying the code of the rational resampler block in
 gnuradio/gr-filter/pythoin/rational_resampler.py and I have a doubt
 about the low pass filter generated by the design_filter() function.
 
 It seems that the generated filter does not take into account the
 decimation factor. Is that correct? I don't see how this may result in
 the correct anti-aliasing filter when it is applied by
 rational_resampler_base_xxx.
 
 Can someone point me to a relevant explanation?
 
 Thanks a lot. Cheers,
 Daniele

Daniele,

I just had occasion to use the rational resampler for a 25 Ksps - 16
Ksps resampling and low-pass filtering all in one step, with a LPF that
cut off frequencies higher than 3000 Hz.  I started by using this
expression for the taps, following the filter design in
gr-filter/python/rational_resampler.py:

filter.firdes.low_pass(16.0, 16000.0, 3250.0/16.0, 500.0/16.0, 
filter.firdes.WIN_KAISER, 5.0)

That filter only includes the interpolation factor, 16.0, and seemed to
do the wrong thing.  The FFT scope showed the rolloff started at around
~4700 Hz, about 25/16 * 3000 Hz.

This expression for the taps, which included the decimation factor of
25.0, appeared to do the right thing:

filter.firdes.low_pass(16.0, 16000.0, 3250.0/25.0, 500.0/25.0, 
filter.firdes.WIN_KAISER, 5.0)


Can someone else take a closer look at
gr-filter/python/rational_resampler.py and confirm it is doing the wrong
thing?

Regards,
Andy


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filter in rational resampler

2014-10-27 Thread Jeff Long 

On 10/27/2014 04:40 PM, Andy Walls wrote:

On Thu, 2014-07-31 at 12:01 -0400, discuss-gnuradio-requ...@gnu.org
wrote:


Message: 5
Date: Wed, 30 Jul 2014 18:42:14 +0200
From: Daniele Nicolodi dani...@grinta.net
To: GNURadio discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Filter in rational resampler

Hello,

I was studying the code of the rational resampler block in
gnuradio/gr-filter/pythoin/rational_resampler.py and I have a doubt
about the low pass filter generated by the design_filter() function.

It seems that the generated filter does not take into account the
decimation factor. Is that correct? I don't see how this may result in
the correct anti-aliasing filter when it is applied by
rational_resampler_base_xxx.

Can someone point me to a relevant explanation?

Thanks a lot. Cheers,
Daniele


Daniele,

I just had occasion to use the rational resampler for a 25 Ksps - 16
Ksps resampling and low-pass filtering all in one step, with a LPF that
cut off frequencies higher than 3000 Hz.  I started by using this
expression for the taps, following the filter design in
gr-filter/python/rational_resampler.py:

filter.firdes.low_pass(16.0, 16000.0, 3250.0/16.0, 500.0/16.0, 
filter.firdes.WIN_KAISER, 5.0)

That filter only includes the interpolation factor, 16.0, and seemed to
do the wrong thing.  The FFT scope showed the rolloff started at around
~4700 Hz, about 25/16 * 3000 Hz.

This expression for the taps, which included the decimation factor of
25.0, appeared to do the right thing:

filter.firdes.low_pass(16.0, 16000.0, 3250.0/25.0, 500.0/25.0, 
filter.firdes.WIN_KAISER, 5.0)


Can someone else take a closer look at
gr-filter/python/rational_resampler.py and confirm it is doing the wrong
thing?

Regards,
Andy


It looks like the default filter is only valid where interp  decim, and 
it's not really meant to have an arbitrary cutoff. As Daniele pointed 
out, decim is not taken into account.


I think that 'interpolation' in design_filter() should be replaced with 
'max(interpolation,decimation). If taps are supplied by the caller, it 
needs to understand how the taps will be used.


Andy, to mimic design_filter, you'd need to do:

  low_pass(16.0, 25000.0, 3250.0, 500.0, ...)

Not that I know if that's right, but that's what design_filter() does.

- Jeff


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filter in rational resampler

2014-07-30 Thread Marcus D. Leech 

On 07/30/2014 12:42 PM, Daniele Nicolodi wrote:

Hello,

I was studying the code of the rational resampler block in
gnuradio/gr-filter/pythoin/rational_resampler.py and I have a doubt
about the low pass filter generated by the design_filter() function.

It seems that the generated filter does not take into account the
decimation factor. Is that correct? I don't see how this may result in
the correct anti-aliasing filter when it is applied by
rational_resampler_base_xxx.

Can someone point me to a relevant explanation?

Thanks a lot. Cheers,
Daniele

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

The filtering happens *before* resampling.  It has to, or you end up 
with aliases.




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio