Hi Nitin,
I agree with Ross and Dave, averaging complex FFT spectrum is very
seldom useful.
Consider a FFT bin, if you set a sinusoid at the center of the bin, the
phase of the result is stopped and you can average it and get a sensible
result. If you move the sinusoid one Hertz off the center, the phase
rotates 360 degrees every second. If you average one second the result
is zero. I hope this makes the problem clear.
Curiously, I *have* an application where I use complex average :-):
extraction of calibration tones. I perform the FFT for other purposes
and compute power spectrum normally. But for certain bins where the
calibration tones sit at the center, I calculate the complex average and
voilá: I have a matched (optimal) filter for the sinusoids.
I hope this helps,
(not a prof. :-) Kaj
On 02/06/2026 16:35, Nitin Purohit wrote:
Dear Prof. Ross and Prof. David,
Thank you for your valuable insights.
As both of you correctly pointed out, I understand the bandwidth
implications associated with accumulating complex voltages rather than
power spectra. However, I am currently working on an interesting project
that requires access to the *complex FFT outputs* from not one, but
*three ADC channels*.
To begin with, I modified the existing single-channel spectrometer
design into a two-channel version, which appears to be functioning as
intended. During this process, I realized that the output data being
accumulated and transmitted is the *power spectrum* rather than the
underlying *complex FFT data*, which is what I ultimately require for
the application.
As suggested by Prof. David, I will explore theturn on the Simulink
option to show the signal data types to analyse the data flow and will
keep the group updated on the progress of the project.
In the meantime, any additional suggestions, references, or example
designs would be greatly appreciated, as I am still trying to gain a
deeper understanding of the CASPER blocks and their implementation details.
Thanks you,
Nitin
On Tuesday, 2 June 2026 at 10:46:33 UTC+5:30 David Harold Edward
MacMahon wrote:
Hi, Nitin,
I think you have two questions. One about bit width management and
one about accumulating the FFT output.
For the bit width question, the first thing I recommend is to turn
on the Simulink option to show the signal data types. Then when you
do an “Update diagram” the data types of each signal will be
displayed. Some blocks will just output the sensible output type
(bit width/binary point, e.g. "Fix18_17") given the input types, but
many blocks let you specify the output bit width and binary. Blocks
of this type usually have options to specify what to do when bits at
the high end are “lost”/“dropped” (aka overflow) and what to do when
bits al the low end are lost/dropped (aka quantization). The
options for overflow are “wrap” (i.e. just blindly drop the overflow
bits) or “saturate” (i.e. clamp at max/min value). The options for
quantization are “truncate” (i.e. just blindly drop the extra bits
at the low end) or one of several different rounding modes. Wrap
and truncate are “free” because they don’t require any extra logic,
whereas saturation and rounding do require extra logic. You can
check out the distinction between the “reinterpret” block and the
“cast” block for more insights.
As for accumulating FFT output, Martin is right. If you accumulate
the complex voltages of the FFT you will effectively be reducing the
bandwidth of each FFT channel. If you add two consecutive N channel
spectra together channel-by-channel then you will have essentially
computed the even channels of a 2N channel FFT.
Hope this helps,
Dave
On Jun 1, 2026, at 08:15, Nitin Purohit <[email protected]> wrote:
Dear all,
I have a question regarding obtaining complex outputs from the
wideband spectrometer.
While going through the spectrometer design in detail, I noticed
that the power block appears to compute the magnitude-squared of
the complex FFT output by squaring the real and imaginary
components and then summing them.
<Screenshot from 2026-06-01 18-38-30.png>
In the complex spectrometer design, the FFT output consists of:
* First 24 bits: Real component (MSB first)
* Next 24 bits: Imaginary component (LSB side)
Since each component is multiplied by itself, the resulting
products are 48 bits wide. After the summation, the output becomes
approximately 49 bits (48 + 1 carry bit).
My difficulty is understanding how this output relates to the
subsequent *simple_bram_vacc* block, which is configured with:
* BitWidth = 64
* Binary Point = 34
How are these parameters derived from the incoming data stream?
A similar question arises in the real spectrometer design. There,
the real and imaginary components appear to be 18 bits each,
resulting in a power computation width of approximately 36 + 1
bits. However, the *simple_bram_vacc* parameters appear to remain
unchanged. I am therefore trying to understand the rationale
behind the BitWidth and Binary Point settings of the accumulator.
<Screenshot from 2026-06-01 19-01-33.png>
From examining the *simple_bram_vacc (figure above the para)* and
*delay_bram* *(figure above the para) *block diagrams, my current
understanding is that:
* A pulse is generated every /vector_length/ samples (512 in
this case).
* During the accumulation period, the delay BRAM stores data at
incrementing addresses.
* The accumulation continues until the count reaches
approximately /(DelayLen − bram_latency − 1)/.
However, I am unsure whether this interpretation is correct.
<Screenshot from 2026-06-01 19-11-38.png>
My current goal is to modify the spectrometer to preserve and
output the complex FFT values instead of computing power. If I
bypass the power calculation and directly pass the complex FFT
output into the accumulation stage:
1. How would *simple_bram_vacc* store the incoming complex values?
2. Would separate accumulators be required for the real and
imaginary streams?
3. Is there an existing CASPER block or example design that
demonstrates accumulation of complex spectra rather than power
spectra?
I would greatly appreciate any explanation or pointers to relevant
documentation regarding this.
Hoping for a response soon,
Thank you,
Sincerely,
Nitin
--
You received this message because you are subscribed to the Google
Groups "[email protected]" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
To view this discussion visit https://groups.google.com/a/
lists.berkeley.edu/d/msgid/casper/0b14ee1f-3011-4def-
a85d-8565937b855en%40lists.berkeley.edu <https://
groups.google.com/a/lists.berkeley.edu/d/msgid/
casper/0b14ee1f-3011-4def-a85d-8565937b855en%40lists.berkeley.edu?
utm_medium=email&utm_source=footer>.
<Screenshot from 2026-06-01 19-01-33.png><Screenshot from
2026-06-01 18-38-30.png><Screenshot from 2026-06-01 19-11-38.png>
--
You received this message because you are subscribed to the Google
Groups "[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To view this discussion visit https://groups.google.com/a/
lists.berkeley.edu/d/msgid/casper/
f3224389-036d-4056-9bf3-61ad3a076f20n%40lists.berkeley.edu <https://
groups.google.com/a/lists.berkeley.edu/d/msgid/casper/
f3224389-036d-4056-9bf3-61ad3a076f20n%40lists.berkeley.edu?
utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/8741daba-18a8-4242-b7e4-672ecae03376%40utu.fi.
