Xlate FIR filter broken in gr 3.7

On Thu, Aug 8, 2013 at 1:37 PM, Stephen Harrison
[email protected]wrote:

I agree… the new way is more intuitive

I have to admit that when the OP filed the bug I went and tested the
block
with a quick GRC flowgraph, and intuitively put in the “center freq”
value
without thinking about it, and saw that it worked correctly. So maybe
the
change by Tom was intentional in order to correct to the current way of
doing it. Going from 3.6 to 3.7 would have been a good time to do it.

Center frequency of the received signal or center where I want to move
it
to? It’s not intuitive ether way, the parameter name should be changed
to
what it actually is: ‘frequency_shift’ and it should behave exactly like
multiplication does, you multiply a positive frequency you get a
positive
shift, negative frequency, down shift by that much, simple.

Andrew

On Thu, Aug 8, 2013 at 4:37 PM, Stephen Harrison
[email protected] wrote:

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

Yes, this change was made on purpose for exactly that reason. As
Johnathan noted, the new block after the 3.7 API change had this new
way of handling the parameter, but the old block didn’t change (for
API compatibility reasons). I think the new way is more intuitive as
well since I, too, always messed it up myself. As Sylvain said, we
called it ‘center frequency’ but it was being treated as the value
used to actually shift the signal, not the center frequency of the
channel.

The real mistake here was not announcing this as a change in our 3.6 -
3.7 conversion document.


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

Also, this change breaks a very important and very used part of hundreds
of
projects over the last ten years to make a variable name make slightly
more
since, when you could just change the variable name to ‘frequency_shift’
and leave the functionality the way it was.

Andrew

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

Also, this change breaks a very important and very used part of
hundreds of projects over the last ten years to make a variable name
make slightly more since, when you could just change the variable name
to ‘frequency_shift’ and leave the functionality the way it was.

Andrew

I have to agree. It’s one thing to muck with the API semantics of a
block that is “new” and hardly anyone has used. It’s quite another to
make a change like this on a block that has been in use for many
years, with folks having figured out the semantics, despite the odd
naming.

I would vote for making copious use of the section in every
block’s XML file.

For example, as a beginner, I spent a lot of time fiddling with “Stream
to Vector” to figure out the parameters were opposite from what I
thought they were. It is frustrating to open up a block’s sheet and find
it “empty”.

On 08/08/2013 05:01 PM, Andrew D. wrote:
Also, this change breaks a very important and very used part of hundreds of
projects over the last ten years to make a variable name make slightly more since,
when you could just change the variable name to ‘frequency_shift’ and leave the
functionality the way it was.

Andrew

I have to agree. It’s one thing to muck with the API semantics of a block that
is “new” and hardly anyone has used. It’s quite another to
make a change like this on a block that has been in use for many
years, with folks having figured out the semantics, despite the odd
naming.

“center_frequency” /always/ refers to the frequency of the incoming
signal.

So what if i’m transmitting, or just “shifting” a signal “frequency” for
another reason?

I understand that “center freq” maybe should mean what you think it
does,
but wouldn’t it make more sense to change the internal parameter name to
one that makes more intuitive sense instead of changing the whole block
functionality and breaking backwards compatibility just to match the
internal variable’s name?

Google “freq xlating fir filter” you can see just how many papers,
projects, videos, tutorials, etc… will need to be fixed less
they cause more confusion and no one can figure out which way it works.

If your decision is firm, we need to at least fix the internal Gnuradio
demo apps that may need fixed or their tuning sliders reversed.

Sorry if this post sounded like a rant ( API breaks bug me :slight_smile: )

Thank you for you consideration,
Andrew

On Thu, Aug 8, 2013 at 5:51 PM, Marcus D. Leech [email protected]
wrote:

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

Also, this change breaks a very important and very used part of hundreds of
projects over the last ten years to make a variable name make slightly more
since, when you could just change the variable name to ‘frequency_shift’ and
leave the functionality the way it was.

Andrew

Referring to an earlier comment, “center_frequency” /always/ refers to
the frequency of the incoming signal. It would/could/should never be
confused as the center frequency of the signal used to down convert
the incoming signal. This was a bug in the original code and I took
the opportunity to fix it in the 3.7 block.

http://www.sbrac.org
With everything else that we’ve changed in 3.7, changing a + to a -
seems like a pretty simple thing. The fix will stay.

I have updated the wiki page that discusses the changes needed to go
from 3.6 to 3.7 to include this omission
(http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7).


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

Ok, so as a summary.
In 3.7 version xlating changes its sign.

When i test it with myself for the first time i mistakenly also changed
sample rate for the xlate filter and did not get result.