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.


On Fri, Aug 9, 2013 at 4:47 AM, Andrew Davis <glneolistm...@gmail.com>wrote:

> > "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 :) )
>
> Thank you for you consideration,
> Andrew
>
>
> On Thu, Aug 8, 2013 at 5:46 PM, Tom Rondeau <t...@trondeau.com> wrote:
>
>> On Thu, Aug 8, 2013 at 5:51 PM, Marcus D. Leech <mle...@ripnet.com>
>> wrote:
>> > On 08/08/2013 05:01 PM, Andrew Davis 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.
>>
>> > 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.
>> >
>> >
>> > --
>> > Marcus Leech
>> > Principal Investigator
>> > Shirleys Bay Radio Astronomy Consortium
>> > 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
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to