Thank you all, I will try out all the suggestions and keep you all posted on my progress. On another note, was just playing around with on the idea to preserve/save the complex FFT, and thought of it would be nice if we can have a stokes calculator block also, this idea came out by looking at the power block. So, I designed the attached block (slx file of the block attached), which looks logically fine to me but being new to this I could use some aid in verification of the design.
Regards, Nitin On Wednesday, 3 June 2026 at 13:12:25 UTC+5:30 Kaj Wiik 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/f767a496-c10d-4150-bf83-f87897aa1034n%40lists.berkeley.edu.
full_stokes_engine.slx
Description: Zip archive
