Re: [casper] Green FFT fixed
These were accumulated (a few hundred FFT output specra). A single FFT output would never look so clean, which makes it hard to see an actual spectrum. Jason On 23 Jun 2010, at 02:01, wrote: Hi Jason: The plots you sent is a accumulated result or it is a single FFT output. Thanks Wan -Original Message- From: Jason Manley [mailto:jasonman...@gmail.com] Sent: Thursday, 17 June 2010 7:31 PM To: Cheng, Wan (CASS, Marsfield) Cc: casper@lists.berkeley.edu Subject: Re: Green FFT fixed No, the FFT redraw scripts used i and j internally, which broke things too. So you're affected! You need to recompile your FFT. Jason On 17 Jun 2010, at 11:27, wrote: Hi Jason: I guess if I build my own blocks with 'i' or 'j' as a loop, it would be a problem. But if I If I did not write any matlab scripts and only use the casper library standard green block, I would not be affect. Is this right? And could you clarify in which case user can overwrite the casper library 'i' with their own? Thanks Wan -Original Message- From: Jason Manley [mailto:jasonman...@gmail.com] Sent: Thursday, 17 June 2010 5:09 PM To: casper@lists.berkeley.edu Lists; Cheng, Wan (CASS, Marsfield) Subject: Green FFT fixed Hello CASPERites Many of you will be aware of a long-standing bug in the FFT libraries which caused degraded performance. We believe that we've fixed it. Andrew Martens and myself performed some repairs earlier this week and have checked-in our script changes to the CASPER subversion (now git) repository. All CASPER "Green block" FFTs are affected. The blocks in the library are not yet updated and so you will need to force a redraw to fix 'em (just delete all the contents of the FFT block and change a parameter). We'll update the casper_library.mdl as soon as we figure out the new git repo. The problem amounted to complex numbers that were not being interpreted correctly by the mat2str/eval command combinations because users overwrote Matlab's "i" with their own variable (typically in a "for" loop, including some in the library scripts themselves). This meant that the twiddle coefficients within the FFT were incorrect. We've bypassed this problem by using our own tostring function along with Matlab's num2str/eval functions. We recommend developers use this tostring function for string type conversion (placing numbers into string fields) during development of all new CASPER green blocks. Also, this would never have been a problem if nobody used "for i" or "for j" loops (which are exactly the characters used to identify complex components) - please rather give your for loop variables sensible names. The problem manifested itself in various ways but was most often observed as bumps or jumps in the noisefloor. To demonstrate it, a low- level wideband noise source was coupled with an independent band- limited noise source. Attached are two plots showing the problem before and after the fix (apologies for different axes scales; linear vs log and different number of FFT channels). Notice the regularly spaced steps in the power spectrum's noise floor where no signal should be present in the "badness" plot and its absence in the "goodness" plot (also present here is an inserted CW tone for reference). Evaluation is on-going to ensure correct operation, but we recommend all library users update their SVN checkouts and recompile any designs that make use of any of the green FFT blocks. Also, lookout for an update from Andrew in the next few days for additional modifications to improve redrawing speed and add some tuning params. Jason
Re: [casper] Green FFT fixed
Hi Jason: The plots you sent is a accumulated result or it is a single FFT output. Thanks Wan -Original Message- From: Jason Manley [mailto:jasonman...@gmail.com] Sent: Thursday, 17 June 2010 7:31 PM To: Cheng, Wan (CASS, Marsfield) Cc: casper@lists.berkeley.edu Subject: Re: Green FFT fixed No, the FFT redraw scripts used i and j internally, which broke things too. So you're affected! You need to recompile your FFT. Jason On 17 Jun 2010, at 11:27, wrote: > Hi Jason: > > I guess if I build my own blocks with 'i' or 'j' as a loop, it would > be a problem. > But if I If I did not write any matlab scripts and only use the > casper library standard green block, I would not be affect. Is this > right? > > And could you clarify in which case user can overwrite the casper > library 'i' with their own? > > Thanks > > Wan > > > -Original Message- > From: Jason Manley [mailto:jasonman...@gmail.com] > Sent: Thursday, 17 June 2010 5:09 PM > To: casper@lists.berkeley.edu Lists; Cheng, Wan (CASS, Marsfield) > Subject: Green FFT fixed > > Hello CASPERites > > Many of you will be aware of a long-standing bug in the FFT > libraries which caused degraded performance. We believe that we've > fixed it. > Andrew Martens and myself performed some repairs earlier this week > and have checked-in our script changes to the CASPER subversion (now > git) repository. All CASPER "Green block" FFTs are affected. The > blocks in the library are not yet updated and so you will need to > force a redraw to fix 'em (just delete all the contents of the FFT > block and change a parameter). We'll update the casper_library.mdl > as soon as we figure out the new git repo. > > The problem amounted to complex numbers that were not being > interpreted correctly by the mat2str/eval command combinations > because users overwrote Matlab's "i" with their own variable > (typically in a "for" loop, including some in the library scripts > themselves). This meant that the twiddle coefficients within the FFT > were incorrect. > We've bypassed this problem by using our own tostring function along > with Matlab's num2str/eval functions. We recommend developers use > this tostring function for string type conversion (placing numbers > into string fields) during development of all new CASPER green blocks. > Also, this would never have been a problem if nobody used "for i" or > "for j" loops (which are exactly the characters used to identify > complex components) - please rather give your for loop variables > sensible names. > > The problem manifested itself in various ways but was most often > observed as bumps or jumps in the noisefloor. To demonstrate it, a > low- level wideband noise source was coupled with an independent > band- limited noise source. Attached are two plots showing the > problem before and after the fix (apologies for different axes > scales; linear vs log and different number of FFT channels). Notice > the regularly spaced steps in the power spectrum's noise floor where > no signal should be present in the "badness" plot and its absence in > the "goodness" plot (also present here is an inserted CW tone for > reference). > > Evaluation is on-going to ensure correct operation, but we recommend > all library users update their SVN checkouts and recompile any > designs that make use of any of the green FFT blocks. > > Also, lookout for an update from Andrew in the next few days for > additional modifications to improve redrawing speed and add some > tuning params. > > Jason > >
Re: [casper] Green FFT fixed
"for i in [set]" is probably one of the most universally recognized constructs in all of computer science! (Unsubstantiated generalization alert:) Anyone who's been programming for more than a couple of weeks who sees a variable named "i" inside of a loop instantly knows its general purpose and behavior. If Matlab's implementation makes it so that you can't safely use this construct, you gotta do what you gotta do, but the problem is Matlab's, not the programmer's. I agree entirely. And that's probably why I'm so annoyed - many of my own scripts use i/j as loop variables. :( Jason
Re: [casper] Green FFT fixed
Moral: Use str2num or str2mat. I don't know why we need a custom tostring function. Sometimes this function needs to accept strings themselves and just pass these through. The "tostring" function just wraps num2str in certain cases. It's nothing special, but it helps to maintain scripts if all developers are using the same function call. Right now, there are num2str and mat2str calls strewn throughout the init functions and each has slightly different behaviour. Jason
Re: [casper] Green FFT fixed
Hi Jason: Thanks. This will also explain why the latest casper library cannot work with me. But it seems that FFT block can always work when I setup it up at first time. But I cannot modify it because it will be broken. Cheers Wan -Original Message- From: Jason Manley [mailto:jasonman...@gmail.com] Sent: Thursday, 17 June 2010 7:31 PM To: Cheng, Wan (CASS, Marsfield) Cc: casper@lists.berkeley.edu Subject: Re: Green FFT fixed No, the FFT redraw scripts used i and j internally, which broke things too. So you're affected! You need to recompile your FFT. Jason On 17 Jun 2010, at 11:27, wrote: > Hi Jason: > > I guess if I build my own blocks with 'i' or 'j' as a loop, it would > be a problem. > But if I If I did not write any matlab scripts and only use the > casper library standard green block, I would not be affect. Is this > right? > > And could you clarify in which case user can overwrite the casper > library 'i' with their own? > > Thanks > > Wan > > > -Original Message- > From: Jason Manley [mailto:jasonman...@gmail.com] > Sent: Thursday, 17 June 2010 5:09 PM > To: casper@lists.berkeley.edu Lists; Cheng, Wan (CASS, Marsfield) > Subject: Green FFT fixed > > Hello CASPERites > > Many of you will be aware of a long-standing bug in the FFT > libraries which caused degraded performance. We believe that we've > fixed it. > Andrew Martens and myself performed some repairs earlier this week > and have checked-in our script changes to the CASPER subversion (now > git) repository. All CASPER "Green block" FFTs are affected. The > blocks in the library are not yet updated and so you will need to > force a redraw to fix 'em (just delete all the contents of the FFT > block and change a parameter). We'll update the casper_library.mdl > as soon as we figure out the new git repo. > > The problem amounted to complex numbers that were not being > interpreted correctly by the mat2str/eval command combinations > because users overwrote Matlab's "i" with their own variable > (typically in a "for" loop, including some in the library scripts > themselves). This meant that the twiddle coefficients within the FFT > were incorrect. > We've bypassed this problem by using our own tostring function along > with Matlab's num2str/eval functions. We recommend developers use > this tostring function for string type conversion (placing numbers > into string fields) during development of all new CASPER green blocks. > Also, this would never have been a problem if nobody used "for i" or > "for j" loops (which are exactly the characters used to identify > complex components) - please rather give your for loop variables > sensible names. > > The problem manifested itself in various ways but was most often > observed as bumps or jumps in the noisefloor. To demonstrate it, a > low- level wideband noise source was coupled with an independent > band- limited noise source. Attached are two plots showing the > problem before and after the fix (apologies for different axes > scales; linear vs log and different number of FFT channels). Notice > the regularly spaced steps in the power spectrum's noise floor where > no signal should be present in the "badness" plot and its absence in > the "goodness" plot (also present here is an inserted CW tone for > reference). > > Evaluation is on-going to ensure correct operation, but we recommend > all library users update their SVN checkouts and recompile any > designs that make use of any of the green FFT blocks. > > Also, lookout for an update from Andrew in the next few days for > additional modifications to improve redrawing speed and add some > tuning params. > > Jason > >
Re: [casper] Green FFT fixed
I agree, too. But years ago when I started programming in C, I wanted
to keep i & j available for other purposes without confusing myself, so
early
on I formed the habit of using k, l, & m as loop variables. I still do
so to
this day.
Dana
Andrew Lutomirski wrote:
On Thu, Jun 17, 2010 at 12:47 PM, Peter Williams
wrote:
On Thu, 2010-06-17 at 15:54 +0200, Jason Manley wrote:
...
1st year comp.sci classes taught us to use descriptive variable names.
That includes iterators. It's sound advice that could have avoided a
lot of trouble and saved a lot of time. I think we should avoid using
i and j as variables of any kind in matlab to avoid problems like this
in the future.
"for i in [set]" is probably one of the most universally recognized
constructs in all of computer science! (Unsubstantiated generalization
alert:) Anyone who's been programming for more than a couple of weeks
who sees a variable named "i" inside of a loop instantly knows its
general purpose and behavior.
I agree completely.
If Matlab's implementation makes it so that you can't safely use this
construct, you gotta do what you gotta do, but the problem is Matlab's,
not the programmer's.
Bah. MATLAB's eval function was not meant for this purpose at all,
and str2num is just silly. Try this function:
- begin test.m -
function x=test
i = 3;
disp('str2mat:')
str2mat('i + 5')
disp('str2num:')
str2num('i + 5')
disp('str2double:')
str2double('i + 5')
disp('eval:')
eval('i + 5')
eval('disp(''evil'')')
- end test.m -
It outputs (not unexpectedly):
test
str2mat:
ans =
i + 5
str2num:
ans =
5. + 1.i
str2double:
ans =
5. + 1.i
eval:
ans =
8
evil
Moral: Use str2num or str2mat. I don't know why we need a custom
tostring function.
--Andy
Re: [casper] Green FFT fixed
That's a great idea, Jonathan! I was going to suggest adding "i = sqrt(-1);" to scripts that need to ensure that i had not been redefined, but I like this convention better. It's too bad that Matlab didn't start out enforcing this from the start and instead allowed an unadorned, uninitialized use of i to mean 1i. :-( Dave On Jun 17, 2010, at 11:06 , Jonathan Landon wrote: Recent versions of Matlab encourage use of a modified variable name for sqrt(-1) -- i.e., 1i and 1j instead of i and j. Using i,j as loop variables is fine as long as complex numbers everywhere else are 1i or 1j. Users familiar with Matlab have learned never to use i,j as loop variables since it overwrites sqrt(-1). I'm not sure that older versions of Matlab support the use of 1i/1j, so I think I'm with Jason in suggesting the use of loop variables with names other than i,j. Jonathan
Re: [casper] Green FFT fixed
One could also use the complex() function to avoid ambiguity. Mark On Thu, Jun 17, 2010 at 11:06 AM, Jonathan Landon < silicondiode2...@yahoo.com> wrote: > Recent versions of Matlab encourage use of a modified variable name for > sqrt(-1) -- i.e., 1i and 1j instead of i and j. Using i,j as loop variables > is fine as long as complex numbers everywhere else are 1i or 1j. Users > familiar with Matlab have learned never to use i,j as loop variables since > it overwrites sqrt(-1). I'm not sure that older versions of Matlab support > the use of 1i/1j, so I think I'm with Jason in suggesting the use of loop > variables with names other than i,j. > > Jonathan > > >
Re: [casper] Green FFT fixed
Recent versions of Matlab encourage use of a modified variable name for sqrt(-1) -- i.e., 1i and 1j instead of i and j. Using i,j as loop variables is fine as long as complex numbers everywhere else are 1i or 1j. Users familiar with Matlab have learned never to use i,j as loop variables since it overwrites sqrt(-1). I'm not sure that older versions of Matlab support the use of 1i/1j, so I think I'm with Jason in suggesting the use of loop variables with names other than i,j. Jonathan
Re: [casper] Green FFT fixed
On Thu, Jun 17, 2010 at 12:47 PM, Peter Williams
wrote:
> On Thu, 2010-06-17 at 15:54 +0200, Jason Manley wrote:
>> ...
>> 1st year comp.sci classes taught us to use descriptive variable names.
>> That includes iterators. It's sound advice that could have avoided a
>> lot of trouble and saved a lot of time. I think we should avoid using
>> i and j as variables of any kind in matlab to avoid problems like this
>> in the future.
>
> "for i in [set]" is probably one of the most universally recognized
> constructs in all of computer science! (Unsubstantiated generalization
> alert:) Anyone who's been programming for more than a couple of weeks
> who sees a variable named "i" inside of a loop instantly knows its
> general purpose and behavior.
I agree completely.
>
> If Matlab's implementation makes it so that you can't safely use this
> construct, you gotta do what you gotta do, but the problem is Matlab's,
> not the programmer's.
>
Bah. MATLAB's eval function was not meant for this purpose at all,
and str2num is just silly. Try this function:
- begin test.m -
function x=test
i = 3;
disp('str2mat:')
str2mat('i + 5')
disp('str2num:')
str2num('i + 5')
disp('str2double:')
str2double('i + 5')
disp('eval:')
eval('i + 5')
eval('disp(''evil'')')
- end test.m -
It outputs (not unexpectedly):
>> test
str2mat:
ans =
i + 5
str2num:
ans =
5. + 1.i
str2double:
ans =
5. + 1.i
eval:
ans =
8
evil
Moral: Use str2num or str2mat. I don't know why we need a custom
tostring function.
--Andy
Re: [casper] Green FFT fixed
On Thu, 2010-06-17 at 15:54 +0200, Jason Manley wrote: > ... > 1st year comp.sci classes taught us to use descriptive variable names. > That includes iterators. It's sound advice that could have avoided a > lot of trouble and saved a lot of time. I think we should avoid using > i and j as variables of any kind in matlab to avoid problems like this > in the future. "for i in [set]" is probably one of the most universally recognized constructs in all of computer science! (Unsubstantiated generalization alert:) Anyone who's been programming for more than a couple of weeks who sees a variable named "i" inside of a loop instantly knows its general purpose and behavior. If Matlab's implementation makes it so that you can't safely use this construct, you gotta do what you gotta do, but the problem is Matlab's, not the programmer's. Peter -- Peter Williams / pwilli...@astro.berkeley.edu Department of Astronomy, UC Berkeley
Re: [casper] Green FFT fixed
Hi Jason, wow . reminds me of when I used IF in a script on the control computer at hatcreek several decades ago, and all hell broke loose, which required re-booting, because I had unwittingly destroyed the operating system by redefining IF, THEN, ELSE logic. Now IF is a very sensible name for the IF frequency.-:) cheers, Mel. On 6/17/10, Jason Manley wrote: > No, the problem is not with scope. You can build designs with two > different FFTs no problem. The issue was that some of the scripts > would use i and j as iterators, and then something like a=1+2*i > wouldn't return the complex number expected. We've side-stepped the > problem by saying "a=1+2i" instead, which matlab recognises as a > complex number no matter what. But the standard matlab mat2str > functions output the former format, so it would be preferable to keep > that convention where possible. > > 1st year comp.sci classes taught us to use descriptive variable names. > That includes iterators. It's sound advice that could have avoided a > lot of trouble and saved a lot of time. I think we should avoid using > i and j as variables of any kind in matlab to avoid problems like this > in the future. > > Jason > > > On 17 Jun 2010, at 15:47, Glen Langston wrote: > >>> Hello CASPERites >>> >>> Many of you will be aware of a long-standing bug in the FFT libraries >>> which caused degraded performance. We believe that we've fixed it. >>> Andrew Martens and myself performed some repairs earlier this week >>> and >>> have checked-in our script changes to the CASPER subversion (now git) >>> repository. All CASPER "Green block" FFTs are affected. The blocks in >>> the library are not yet updated and so you will need to force a >>> redraw >>> to fix 'em (just delete all the contents of the FFT block and >>> change a >>> parameter). We'll update the casper_library.mdl as soon as we figure >>> out the new git repo. >>> >>> The problem amounted to complex numbers that were not being >>> interpreted correctly by the mat2str/eval command combinations >>> because >>> users overwrote Matlab's "i" with their own variable (typically in a >>> "for" loop, including some in the library scripts themselves). This >>> meant that the twiddle coefficients within the FFT were incorrect. >>> We've bypassed this problem by using our own tostring function along >>> with Matlab's num2str/eval functions. We recommend developers use >>> this >>> tostring function for string type conversion (placing numbers into >>> string fields) during development of all new CASPER green blocks. >> >>> Also, this would never have been a problem if nobody used "for i" or >>> "for j" loops (which are exactly the characters used to identify >>> complex components) - please rather give your for loop variables >>> sensible names. >> >> What do you mean by "sensible names"? It seems that really there >> is an issue with the scope of variable names, and that if we all >> used the same "sensible names" we would have the the same problem. >> I think by sensible names, you mean "unique names". >> >> We've been struggling with a Roach FFT issue, where we have >> two pairs of PBF and FFTs in the same design. Since these >> probably use the same underlying code, will these designs build >> correctly, in the new scheme? >> >> Thanks >> >> Glen >>> >>> The problem manifested itself in various ways but was most often >>> observed as bumps or jumps in the noisefloor. To demonstrate it, a >>> low- >>> level wideband noise source was coupled with an independent band- >>> limited noise source. Attached are two plots showing the problem >>> before and after the fix (apologies for different axes scales; linear >>> vs log and different number of FFT channels). Notice the regularly >>> spaced steps in the power spectrum's noise floor where no signal >>> should be present in the "badness" plot and its absence in the >>> "goodness" plot (also present here is an inserted CW tone for >>> reference). >>> >>> Evaluation is on-going to ensure correct operation, but we recommend >>> all library users update their SVN checkouts and recompile any >>> designs >>> that make use of any of the green FFT blocks. >>> >>> Also, lookout for an update from Andrew in the next few days for >>> additional modifications to improve redrawing speed and add some >>> tuning params. >>> >>> Jason >>> >>> >>> >>> >>> >>> >> >> > > >
Re: [casper] Green FFT fixed
No, the problem is not with scope. You can build designs with two different FFTs no problem. The issue was that some of the scripts would use i and j as iterators, and then something like a=1+2*i wouldn't return the complex number expected. We've side-stepped the problem by saying "a=1+2i" instead, which matlab recognises as a complex number no matter what. But the standard matlab mat2str functions output the former format, so it would be preferable to keep that convention where possible. 1st year comp.sci classes taught us to use descriptive variable names. That includes iterators. It's sound advice that could have avoided a lot of trouble and saved a lot of time. I think we should avoid using i and j as variables of any kind in matlab to avoid problems like this in the future. Jason On 17 Jun 2010, at 15:47, Glen Langston wrote: Hello CASPERites Many of you will be aware of a long-standing bug in the FFT libraries which caused degraded performance. We believe that we've fixed it. Andrew Martens and myself performed some repairs earlier this week and have checked-in our script changes to the CASPER subversion (now git) repository. All CASPER "Green block" FFTs are affected. The blocks in the library are not yet updated and so you will need to force a redraw to fix 'em (just delete all the contents of the FFT block and change a parameter). We'll update the casper_library.mdl as soon as we figure out the new git repo. The problem amounted to complex numbers that were not being interpreted correctly by the mat2str/eval command combinations because users overwrote Matlab's "i" with their own variable (typically in a "for" loop, including some in the library scripts themselves). This meant that the twiddle coefficients within the FFT were incorrect. We've bypassed this problem by using our own tostring function along with Matlab's num2str/eval functions. We recommend developers use this tostring function for string type conversion (placing numbers into string fields) during development of all new CASPER green blocks. Also, this would never have been a problem if nobody used "for i" or "for j" loops (which are exactly the characters used to identify complex components) - please rather give your for loop variables sensible names. What do you mean by "sensible names"? It seems that really there is an issue with the scope of variable names, and that if we all used the same "sensible names" we would have the the same problem. I think by sensible names, you mean "unique names". We've been struggling with a Roach FFT issue, where we have two pairs of PBF and FFTs in the same design. Since these probably use the same underlying code, will these designs build correctly, in the new scheme? Thanks Glen The problem manifested itself in various ways but was most often observed as bumps or jumps in the noisefloor. To demonstrate it, a low- level wideband noise source was coupled with an independent band- limited noise source. Attached are two plots showing the problem before and after the fix (apologies for different axes scales; linear vs log and different number of FFT channels). Notice the regularly spaced steps in the power spectrum's noise floor where no signal should be present in the "badness" plot and its absence in the "goodness" plot (also present here is an inserted CW tone for reference). Evaluation is on-going to ensure correct operation, but we recommend all library users update their SVN checkouts and recompile any designs that make use of any of the green FFT blocks. Also, lookout for an update from Andrew in the next few days for additional modifications to improve redrawing speed and add some tuning params. Jason
Re: [casper] Green FFT fixed
> Hello CASPERites > > Many of you will be aware of a long-standing bug in the FFT libraries > which caused degraded performance. We believe that we've fixed it. > Andrew Martens and myself performed some repairs earlier this week and > have checked-in our script changes to the CASPER subversion (now git) > repository. All CASPER "Green block" FFTs are affected. The blocks in > the library are not yet updated and so you will need to force a redraw > to fix 'em (just delete all the contents of the FFT block and change a > parameter). We'll update the casper_library.mdl as soon as we figure > out the new git repo. > > The problem amounted to complex numbers that were not being > interpreted correctly by the mat2str/eval command combinations because > users overwrote Matlab's "i" with their own variable (typically in a > "for" loop, including some in the library scripts themselves). This > meant that the twiddle coefficients within the FFT were incorrect. > We've bypassed this problem by using our own tostring function along > with Matlab's num2str/eval functions. We recommend developers use this > tostring function for string type conversion (placing numbers into > string fields) during development of all new CASPER green blocks. > Also, this would never have been a problem if nobody used "for i" or > "for j" loops (which are exactly the characters used to identify > complex components) - please rather give your for loop variables > sensible names. What do you mean by "sensible names"? It seems that really there is an issue with the scope of variable names, and that if we all used the same "sensible names" we would have the the same problem. I think by sensible names, you mean "unique names". We've been struggling with a Roach FFT issue, where we have two pairs of PBF and FFTs in the same design. Since these probably use the same underlying code, will these designs build correctly, in the new scheme? Thanks Glen > > The problem manifested itself in various ways but was most often > observed as bumps or jumps in the noisefloor. To demonstrate it, a low- > level wideband noise source was coupled with an independent band- > limited noise source. Attached are two plots showing the problem > before and after the fix (apologies for different axes scales; linear > vs log and different number of FFT channels). Notice the regularly > spaced steps in the power spectrum's noise floor where no signal > should be present in the "badness" plot and its absence in the > "goodness" plot (also present here is an inserted CW tone for > reference). > > Evaluation is on-going to ensure correct operation, but we recommend > all library users update their SVN checkouts and recompile any designs > that make use of any of the green FFT blocks. > > Also, lookout for an update from Andrew in the next few days for > additional modifications to improve redrawing speed and add some > tuning params. > > Jason > > > > > >
Re: [casper] Green FFT fixed
No, the FFT redraw scripts used i and j internally, which broke things too. So you're affected! You need to recompile your FFT. Jason On 17 Jun 2010, at 11:27, wrote: Hi Jason: I guess if I build my own blocks with 'i' or 'j' as a loop, it would be a problem. But if I If I did not write any matlab scripts and only use the casper library standard green block, I would not be affect. Is this right? And could you clarify in which case user can overwrite the casper library 'i' with their own? Thanks Wan -Original Message- From: Jason Manley [mailto:jasonman...@gmail.com] Sent: Thursday, 17 June 2010 5:09 PM To: casper@lists.berkeley.edu Lists; Cheng, Wan (CASS, Marsfield) Subject: Green FFT fixed Hello CASPERites Many of you will be aware of a long-standing bug in the FFT libraries which caused degraded performance. We believe that we've fixed it. Andrew Martens and myself performed some repairs earlier this week and have checked-in our script changes to the CASPER subversion (now git) repository. All CASPER "Green block" FFTs are affected. The blocks in the library are not yet updated and so you will need to force a redraw to fix 'em (just delete all the contents of the FFT block and change a parameter). We'll update the casper_library.mdl as soon as we figure out the new git repo. The problem amounted to complex numbers that were not being interpreted correctly by the mat2str/eval command combinations because users overwrote Matlab's "i" with their own variable (typically in a "for" loop, including some in the library scripts themselves). This meant that the twiddle coefficients within the FFT were incorrect. We've bypassed this problem by using our own tostring function along with Matlab's num2str/eval functions. We recommend developers use this tostring function for string type conversion (placing numbers into string fields) during development of all new CASPER green blocks. Also, this would never have been a problem if nobody used "for i" or "for j" loops (which are exactly the characters used to identify complex components) - please rather give your for loop variables sensible names. The problem manifested itself in various ways but was most often observed as bumps or jumps in the noisefloor. To demonstrate it, a low- level wideband noise source was coupled with an independent band- limited noise source. Attached are two plots showing the problem before and after the fix (apologies for different axes scales; linear vs log and different number of FFT channels). Notice the regularly spaced steps in the power spectrum's noise floor where no signal should be present in the "badness" plot and its absence in the "goodness" plot (also present here is an inserted CW tone for reference). Evaluation is on-going to ensure correct operation, but we recommend all library users update their SVN checkouts and recompile any designs that make use of any of the green FFT blocks. Also, lookout for an update from Andrew in the next few days for additional modifications to improve redrawing speed and add some tuning params. Jason
Re: [casper] Green FFT fixed
Hi Jason: I guess if I build my own blocks with 'i' or 'j' as a loop, it would be a problem. But if I If I did not write any matlab scripts and only use the casper library standard green block, I would not be affect. Is this right? And could you clarify in which case user can overwrite the casper library 'i' with their own? Thanks Wan -Original Message- From: Jason Manley [mailto:jasonman...@gmail.com] Sent: Thursday, 17 June 2010 5:09 PM To: casper@lists.berkeley.edu Lists; Cheng, Wan (CASS, Marsfield) Subject: Green FFT fixed Hello CASPERites Many of you will be aware of a long-standing bug in the FFT libraries which caused degraded performance. We believe that we've fixed it. Andrew Martens and myself performed some repairs earlier this week and have checked-in our script changes to the CASPER subversion (now git) repository. All CASPER "Green block" FFTs are affected. The blocks in the library are not yet updated and so you will need to force a redraw to fix 'em (just delete all the contents of the FFT block and change a parameter). We'll update the casper_library.mdl as soon as we figure out the new git repo. The problem amounted to complex numbers that were not being interpreted correctly by the mat2str/eval command combinations because users overwrote Matlab's "i" with their own variable (typically in a "for" loop, including some in the library scripts themselves). This meant that the twiddle coefficients within the FFT were incorrect. We've bypassed this problem by using our own tostring function along with Matlab's num2str/eval functions. We recommend developers use this tostring function for string type conversion (placing numbers into string fields) during development of all new CASPER green blocks. Also, this would never have been a problem if nobody used "for i" or "for j" loops (which are exactly the characters used to identify complex components) - please rather give your for loop variables sensible names. The problem manifested itself in various ways but was most often observed as bumps or jumps in the noisefloor. To demonstrate it, a low- level wideband noise source was coupled with an independent band- limited noise source. Attached are two plots showing the problem before and after the fix (apologies for different axes scales; linear vs log and different number of FFT channels). Notice the regularly spaced steps in the power spectrum's noise floor where no signal should be present in the "badness" plot and its absence in the "goodness" plot (also present here is an inserted CW tone for reference). Evaluation is on-going to ensure correct operation, but we recommend all library users update their SVN checkouts and recompile any designs that make use of any of the green FFT blocks. Also, lookout for an update from Andrew in the next few days for additional modifications to improve redrawing speed and add some tuning params. Jason
[casper] Green FFT fixed
Hello CASPERites Many of you will be aware of a long-standing bug in the FFT libraries which caused degraded performance. We believe that we've fixed it. Andrew Martens and myself performed some repairs earlier this week and have checked-in our script changes to the CASPER subversion (now git) repository. All CASPER "Green block" FFTs are affected. The blocks in the library are not yet updated and so you will need to force a redraw to fix 'em (just delete all the contents of the FFT block and change a parameter). We'll update the casper_library.mdl as soon as we figure out the new git repo. The problem amounted to complex numbers that were not being interpreted correctly by the mat2str/eval command combinations because users overwrote Matlab's "i" with their own variable (typically in a "for" loop, including some in the library scripts themselves). This meant that the twiddle coefficients within the FFT were incorrect. We've bypassed this problem by using our own tostring function along with Matlab's num2str/eval functions. We recommend developers use this tostring function for string type conversion (placing numbers into string fields) during development of all new CASPER green blocks. Also, this would never have been a problem if nobody used "for i" or "for j" loops (which are exactly the characters used to identify complex components) - please rather give your for loop variables sensible names. The problem manifested itself in various ways but was most often observed as bumps or jumps in the noisefloor. To demonstrate it, a low- level wideband noise source was coupled with an independent band- limited noise source. Attached are two plots showing the problem before and after the fix (apologies for different axes scales; linear vs log and different number of FFT channels). Notice the regularly spaced steps in the power spectrum's noise floor where no signal should be present in the "badness" plot and its absence in the "goodness" plot (also present here is an inserted CW tone for reference). Evaluation is on-going to ensure correct operation, but we recommend all library users update their SVN checkouts and recompile any designs that make use of any of the green FFT blocks. Also, lookout for an update from Andrew in the next few days for additional modifications to improve redrawing speed and add some tuning params. Jason <><>
