Hi Nitin & Kaj, Kaj your point seems interesting but I am ambiguous about it as cross correlation is essentially XY* --> where X is FFT of signal-1 and Y is FFT of signal-2 if both are same then it will be auto-correlation which is power spectra. So, I don't know how phase can be preserved with cross-correlation? What I am thinking is how much FFT phase preservation you are looking at, one thing I can think of is calculating magnitude or power and phase separately, then accumulating and saving it. But, still that will induce errors in your phase readings, you can try out Dan's idea of sending data through high speed ethernet.
Best, Harsha On Wed, Jun 3, 2026 at 1:12 PM Kaj Wiik <[email protected]> wrote: > Hi Karl, > > Interesting point, I haven't thought of that! > > To the original question: if you need complex spectrum for measuring > phase differences, you can use cross correlation and average the product. > > Thanks, > Kaj > > On 02/06/2026 23:39, Karl Warnick wrote: > > Minor side point, if both the signal of interest and noise are > > incoherent, then it makes sense to average spectral power density. But > > if the signal is has long term phase coherency, complex FFT outputs can > > be averaged. This is done with FMCW radar in Doppler processing. The > > first FFT does range compression, and the second FFT puts the signal > > into Doppler bins and dramatically increases SNR. Stationary objects are > > lost in the zero Doppler clutter (which is why my car forward radar sees > > moving cars fine but misses cars at a stoplight). > > > > Best, > > Karl > > > > > > On 6/2/2026 1:33 PM, 'Dan Werthimer' via [email protected] > wrote: > >> > >> hi nitin, > >> > >> since you don't want to add complex FFT outputs together, > >> and you instead want to gain access to the complex outputs of the FFT, > >> you could connect the FFT frequency domain complex output to a > >> snapshot block to capture the output from one or a few spectra, > >> and then after the data are captured, you can read the contents of the > >> snapshot block into a computer. > >> > >> if you need to capture a continuous stream of complex data, then you > >> will run out of memory using a snapshot block, > >> so it's better to connect the complex data from the FFT output into a > >> high speed ethernet block, > >> and stream the high speed ethernet data to a computer. > >> > >> best wishes, > >> > >> dan > >> > >> > >> > >> > >> > >> > >> On Tue, Jun 2, 2026 at 6:35 AM Nitin Purohit > >> <[email protected]> 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]. > >> 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/ > >> CAA9jdz%2BSTundixDjfWMv%2Bv6K%3D%3DDE7w1dc5GVCSpCuyJ- > >> mQe6%3Dw%40mail.gmail.com <https://groups.google.com/a/ > >> lists.berkeley.edu/d/msgid/casper/ > >> CAA9jdz%2BSTundixDjfWMv%2Bv6K%3D%3DDE7w1dc5GVCSpCuyJ- > >> mQe6%3Dw%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > > > -- > > Karl F. Warnick > > Parkinson Engineering Research Professor > > Department of Electrical and Computer Engineering > > Brigham Young University > > 450 Engineering Building > > Provo, UT 84602 > > (801) 422-1732 > > > > > > > > > > > > > > -- > > 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/75aa0691-a787-4cab-ae9d- > > af139d037cd9%40ee.byu.edu <https://groups.google.com/a/ > > lists.berkeley.edu/d/msgid/casper/75aa0691-a787-4cab-ae9d- > > af139d037cd9%40ee.byu.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/f3c777c1-29e5-4460-bdd2-3e4d1f6fee25%40utu.fi > . > -- 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/CAL9jYq24Ag22R-DgjCjb8ZLZHmJshY6Qrrj1zGHmwn2AM9Ytbg%40mail.gmail.com.
