Important Events in Our DSP Work

Started by Rick Lyons 4 weeks ago2 replieslatest reply 4 weeks ago212 views

I believe there are two equally important events we can experience in our DSP work.

The first kind of important event is when we examine the results of our designed DSP process and shout, “It’s working!”

The second kind of important event is when we examine the results of our designed DSP process and quietly whisper, “Hmm, that’s funny.” In this second event we’re on the verge of discovering something we didn’t know before.

[ - ]
Reply by neiroberJune 18, 2024

Hi Rick,

It's best if this second event happens before the design is potted in silicon!

-- Neil

[ - ]
Reply by CharlieRaderJune 18, 2024

There's a third important event we can experience. Sometimes a process requires two different actions, each of which has a difficult part. But sometimes, the difficult part of the first action and the difficult part of the second action can be combined into a third action which, unexpectedly, is much simpler than the two difficult parts.

A great example of this was when two long sequences need to be convolved. Convolution of an N element sequence and an M element sequence, without the FFT, take O(NM) multiply and add steps. With the FFT, the cost goes down to O(K log K) M.A.D. steps, but there is the nuisance of bit reversal after (or before) each FFT step. I remember how exciting it was to realize that by using decimation in time for one FFT and decimation in frequency for the other, each bit reversal step undid the other!

Another great example was when I was learning to use recursive digital filters. For an Nth order filter, I used N delays to realize the poles and N more delays to realize the zeroes. Suddenly I realized that the delays could be put between the part of the filter that realized the poles and the part that realized the zeroes, saving half the necessary delay elements.

A few years ago, I wanted to take a long sequence of data arriving one sample at a time, divide it into blocks of N samples, and reverse the sample order in each block, still outputting one sample each clock time. It was obvious that a last in first out (LIFO) buffer could reverse a block of N samples, but it was busy with the odd numbered blocks so a second LIFO buffer was needed for the even numbered blocks. It was very exciting to discover that one LIFO buffer could handle both odd and even numbered blocks at the same time, by loading the odd numbered  block data into one end of the LIFO buffer and taking it out from that same end, and doing the same thing at the other end of the LIFO buffer for the even numbered blocks.