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
