Xlate FIR filter broken in gr 3.7

Hi, made an attempt to test my python scripts with new 3.7.0 of GR
and what i am seeing xlate fir filter is broken

previously xlate worked perfect with 3.6 version

tested with waterfalls and i see wrong xlating
i think developers should pay attention to this issue

also there is small bug in tcp.py dist-package but patch has been
already
announced

On Wed, Aug 07, 2013 at 01:00:32PM +0400, Anton K. wrote:

i think developers should pay attention to this issue
Hi Anton,

can you please elaborate on this bug. Ideally, could you post an issue
on our tracker: http://gnuradio.org/redmine/projects/gnuradio/issues

Specify what you configured, what the expected outcome was and what
happened instead.

Thanks,
MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

Ok, i’ve attached very simple grc chart
with slider you can change the frequency, two waterfalls shows spectrums
before and after xlating.
So i had test it in apco25 env and took apco signals as a reference. So
when i saw signal e.g. at 451.378 MHz and tuned to it i saw no signal
after
xlating nevertheless it was the same time on waterfall before xlating.

You can test this chart with you radio environment.

Then i testing the same logic with gr 3.6 (code is not compatible i have
to
redraw it…) and here it is! xlating worked like a charm.

On Wed, Aug 7, 2013 at 7:56 AM, Anton K. [email protected]
wrote:

redraw it…) and here it is! xlating worked like a charm.
Try reversing the sign of the center frequency value for the xlating
filter. I’ve been using this block for some tests of my own this week
and it’s working as expected.

Tom

Specify what you configured, what the expected outcome was and what
Research Associate
National Laboratory of the Helmholtz Association
[email protected]
Discuss-gnuradio Info Page


Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

Hi Anton,
it is really hard to capture apco25 signals in Germany.
Could you really open a ticket, attach a few captured samples saved
using a file sink,
and the 3.6 and 3.7 flowgraphs; or provide some kind of test case with
GNU Radio Signal sources
that simulate a signal. Be sure to attach screenshots of your waterfall
plots.
It is really hard to guess what goes wrong otherwise.

Greetings,
Marcus

Am 07.08.2013 13:56, schrieb Anton K.:

Marcus, am i supposed to share e.g. 10 seconds of captured spectrum so
you
can play with it on your side?

Tom it was the first i have done, did not worked for me

Ok, but it is not clear for me how to open a ticket in gr bug tracker…

Yes, please attach it to your ticket.

Am 07.08.2013 14:28, schrieb Anton K.:

Who can help me to open a ticket?

On Thu, Aug 08, 2013 at 05:04:10PM +0400, Anton K. wrote:

Who can help me to open a ticket?

  1. (If you don’t have one:) Create an account on gnuradio.org (tell us
    your user name)
  2. Go to http://gnuradio.org/redmine/projects/gnuradio/issues
  3. Click ‘New Issue’ in the nav bar
  4. Fill out the form

MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

Martin
i registered
opened issues page
cannot find New Issue link
i see Filter, Options and list of issues

Ok, done with bug submit, actually done it for the first time so might
look
ugly…
http://gnuradio.org/redmine/issues/580

On Thu, Aug 8, 2013 at 6:04 PM, Johnathan C.

On 08/08/2013 06:57 AM, Anton K. wrote:

i registered
opened issues page
cannot find New Issue link
i see Filter, Options and list of issues

I upgraded your account to allow reporting issues, so you should see the
New Issue link now.

Is it just me or did the polarity of the frequency offset in
freq_xlating_fir_filter get reversed between 3.6 and 3.7?

It’s not just you, I noticed this too. This change broke gr-atsc ( but I
fixed that ).
The problem is on line 80 of
gr-filter/lib/freq_xlating_fir_filter_XXX_impl.cc.t: the 2 was not
negative
in 3.6 but is now, i’m not sure why.

Andrew

On Thu, Aug 8, 2013 at 12:16 PM, Stephen Harrison

On 08/08/2013 01:01 PM, Andrew D. wrote:

It’s not just you, I noticed this too. This change broke gr-atsc ( but I
fixed that ).
The problem is on line 80 of
gr-filter/lib/freq_xlating_fir_filter_XXX_impl.cc.t: the 2 was not
negative in 3.6 but is now, i’m not sure why.

Good catch, thanks.

The “old style” version of the block in gnuradio-core in 3.6.5.1 works
correctly. The “new style” version of the block in gr-filter in 3.6.5.1
has the sign change. When all the old-style blocks were removed for
3.7, this of course left only the changed one.

Since it was Tom who did the conversion on that block, I’ll wait until
he chimes in on whether his change was an accident or intentional.

Hi,

The “old style” version of the block in gnuradio-core in 3.6.5.1 works
correctly. The “new style” version of the block in gr-filter in 3.6.5.1
has the sign change. When all the old-style blocks were removed for
3.7, this of course left only the changed one.

Personally I always thought that the previous block (in 3.6) was
“weird” because the parameter was named “Center freq” but you in fact
had to give it the frequency shift you wanted. The new one behaves
more like I expect.

Cheers,

Sylvain

On 08/08/13 21:14, Johnathan C. wrote:

The “old style” version of the block in gnuradio-core in 3.6.5.1 works
correctly. The “new style” version of the block in gr-filter in 3.6.5.1
has the sign change. When all the old-style blocks were removed for
3.7, this of course left only the changed one.

Since it was Tom who did the conversion on that block, I’ll wait until
he chimes in on whether his change was an accident or intentional.

I’ll defer to those who know the code better than I, however I will note
that the fact that it was “reverse” (ie negative values went “up” in
frequency within the filter" confused me at first…

…But then I spoke to others that used other SDRs, and found that they
had the same behaviour. So I stuck a sign in front, and carried on,
believing it was some strange function of the way things worked deep
in SDR theory, and didn’t worry about it any more.

Would suggest that if others do it this way (ie negative values in the
FIR filter go up), it may be worth to keep that behaviour for
convention’s sake if there’s no better reason to change it

Best Regards

Iain

I agree… the new way is more intuitive but then again it broke a bunch
of
my GRC patches… :slight_smile: