[Dspforum] Lab #6 STFT issues

[Ryan Merton]

Doug,

I've done much of what you suggested regarding the debugging, though
perhaps I should do it again with some fresh sleep in me and pay very
close attention.  I will probably just wait until the lab time.  I've
spent way too much time already trying to "get ahead" on this one!

I am using (Q)DMA, and that proved to be rather complicated to figure
out (though I did eventually get it).  I read ahead in the notes and
the SPRUs.  I will mention, for anyone else who is reading this, that
one of the option fields for the DMA register lets you set the
word-width.  This is not related to the array/frame count short, nor
the element count.  Not paying attention, the code I copy/pasted from
a TI example set this to 32-bit words, whereas I was doing the float
to bytes calculation with sizeof(float), and was thus pulling 4 times
the memory from ext. ram into local RAM, and overwriting a ton of
stuff in the process.

Thanks,
Ryan

On Mon, Oct 13, 2008 at 1:31 PM, Wenstrand, Doug S.
<Douglas.Wenstrand at jhuapl.edu> wrote:
> Ryan,
> I have definitely seen all sorts of issues related to the FFT.  This is why we have the week-1 benchmark to first verify that an FFT of data in internal memory produces exactly the right answer.  With that out of the way, all the other issues can be debugged.
>
> It does seem interesting that the problem is with the first and last couple FFTs, its as if the data you are passing to the FFT is wrong and/or you are simply placing it back into external memory wrong.  It is actually real hard to tell though from the graph, thats just too many things aggregated together to know what is actually wrong.
>
> *** Note, we are going to discuss DMA in class this week, which will be the preferred way to speed up this lab.  You may already be doing this.. not sure ***
>
> I'd recommend a very methodical approach to debugging this.  Since you have the chirp sitting in memory, it should be pretty easy to do this step by step.
>
> First, get your chirp in external memory.
>
> Second, look at the first bunch of data using the graphing capabilities of Code Composer Studio -- just check out the graph of your data and make sure it looks right (i.e. a tone in the real side, 0's in the imaginary)
>
> Third, step through your code to the point where you are about to take the first FFT
>
> Check the data that you are going to operate on one more time.
>
> Run the FFT routine, and look at the results.  Make sure that there are no #NANs or anything in the results.  Is the answer right? your impulse should show up in two places since the input signal is real...
>
> If the first FFT is wrong, check some of the issues that could be causing trouble.  Is the twiddle table correct?  What does it look like?  What about alignment?  Are the twiddles and/or data aligned on the proper boundaries?
>
> If the first FFT is right, then where is that data getting corrupted?  The second iteration perhaps overwriting the answer from the first?
>
>
> In any case -- this is a ton of very general suggestions.  My recommendation would be to work simply on getting the week-1 milestone working, and then taking what we learn in class (as well as the lab time) to get the whole assignment going.  I think we'll have alot more luck debugging together in class.  (There won't be an additional lab assigned this week)
>
> Alternatively, send me your project directory and I could offer more specifics.
>
> Doug
>
>
> -----Original Message-----
> From: dspforum-bounces at echelonembedded.com on behalf of Ryan Merton
> Sent: Mon 10/13/2008 11:48 AM
> To: dspforum at echelonembedded.com
> Subject: [Dspforum] Lab #6 STFT issues
>
> I don't believe my STFT is working correctly in lab 6.  I have
> generated a synthetic chirp in external RAM going from 1000 to 11000
> Hz over a 10 second interval.  I pulled this from the board via CCS
> and plotted the spectogram in matlab [ specgram(data, 8192, 48000) ]
> and created good_spectrogram.jpg.  I also pulled the STFT data from
> external RAM as well and plotted the results in matlab as
> dsp_stft.jpg.  While I was at it I emulated the behavior of the DSP
> STFT in matlab like this:
>
> function do_stft(in)
>
> q = zeros(8192, 100);
> for x = 1:100,
>    startIdx = 4096*(x-1) + 1;
>    q(:,x) = fft( in(startIdx:(startIdx + 8192)), 8192 );
> end
> figure;
> imagesc(20*log10(abs(q)));
>
> Running do_stft(data) in matlab results in matlab_stft.jpg.
>
> There appears to be issues on the DSP with the first and last 1 or 2
> frames of FFT data.  There is also something wrong with the imaginary
> half of the spectrum.  Is this a problem that you have seen before?  I
> have spent quite a bit of time on it and haven't been able to make any
> further headway.
>
> Thanks,
> Ryan
>
>
> _______________________________________________
> Dspforum mailing list
> Dspforum at echelonembedded.com
> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>
>