LAB 9: Spectrum Analyzer

LAB 9: Spectrum Analyzer

Nasir Ahmed

Objective:

The objective of this lab is to firstly develop a routine that will compute the fast Fourier transform (FFT). Next, after this is correctly functioning, the goal is to use this FFT routine and develop a spectrum analyzer tool. This will be done on the DSP, and the output will be observed on the oscilloscope. The result of this lab will be the development of a spectral analyzer tool. The tool will be developed partially in MATLAB and mostly in code composer. MATLAB will be used to export the coefficients of the hamming window. In Code Composer, code will be developed which uses interrupt service routines, and FFT library function calls. In this lab, we will use the tools developed from the previous labs, along with the lectures we had on the FFT to implement the spectral analyzer.

Matlab Exercises:

Exercise 2.1:

We first ran the MATLAB code that was given in its unmodified form. We saw a spectral peak at 1kHz. The following is the plot we observed;

Next, we added zero padding so that the total number of bits was 4096. The following is the spectrum that we observed:

The main difference between the two plots was the smoothness of the detailed view when zero padding was utilized. The zero-padding produces higher resolution of the spectrum of the signal, but it also increases the amount of computation in the FFT.

Exercise 2.2 (windowing):

1)We did the plot(boxcar(256)) command, and observed that the result was a straight line (zero slope) of height 1.

2)Using the boxcar described above, and M=4096, we obtain the same spectrum shown in exercise 2.1.

3)Next, we plotted the spectrum of the hamming window, we obtained the following:

4)Next, we used a hamming window (when M=4096) instead of a boxcar window. The following is the spectrum we observed:

With the boxcar case, around 1khz, there was a drop off, but also the frequency spectrum did not continue to drop off, it rose for a bit (a side lobe). This resembled a sinc function in the frequency domain (since the boxcar is a rect in time, this makes sense). However, with the hamming window, the frequency spectrum at 1 kHz dropped off smoothly, unlike the boxcar window.

5) The problem of the boxcar window is the side lobes that are introduced in the frequency spectrum. The advantage of the Hamming window is that there is little side lobe behavior. However, with the boxcar, the side lobe is much greater, but the main lobe appears to be narrower. So, there is a tradeoff between the boxcar and hamming window. There is a tradeoff between widths of side lobe/main lobe. For FFT implementation, we will use the hamming window because we do not wish to have a large side lobe.

DSP Implementation:

Exercise 2.3 (Spectrum Analyzer):

In this part of the lab, we will implement the spectrum analyzer in the DSP. We used the Texas instruments DSP library, specifically the following three functions to implement our FFT:

Bitrev_cplx

Digitrev_cplx

Radix2

The main idea of the code is as follows. Firstly, the interrupt service routine buffers the input data, until there are 64 samples. Next, it transfers this buffered data to an FFT routine. However, before it does this, it transfers the contents of a buffer to second buffer. In this way, while the FFT computation takes place, the ISR can simultaneously collect samples for the next FFT computation. After completion of the FFT, the contents of the FFT output buffer is transferred to a CODEC output buffer, which puts the contents of the buffer to the serial port. In this manner, the FFT can continue to be calculated, without corrupting the FFT output calculated previously. This is the reason for the use of the four buffers, to allow for real time processing. The output of the serial port is fed to an oscilloscope (with a low pass filter in between) to view the spectrum analyzer. Our result was correct and as expected. If we increased the frequency of the tone generator, the spacing between the two spikes in the FFT increased, as expected.

The code for our spectrum analyzer is shown on the course web page. The implementation worked correctly. However, we did run into a couple of strange issues. Firstly, the spectrum on the oscilloscope had DC offset, which was strange. Secondly, the spectrum was inverted on the oscilloscope. This was also strange because we observed the FFT output prior to sending it to the CODEC, and it was positive. For some reason, it gets inverted on its path to the oscilloscope. This may be a problem in the CODEC, but we were unable to resolve this issue.

Conclusions:

In this lab, we successfully learned how to develop a spectrum analyzer in code composer. Firstly, we experimented with zero padding, and windowing in MATLAB. Then, we imported a hamming window from MATLAB, and used it in our FFT implementation on the DSP. The program was written with four buffers and an interrupt service routine. The buffers were needed so that when one FFT was being computed, the interrupt routines could buffer up the next 64 samples. This way, there were no loss in samples, and the spectrum analyzer behaved in ‘real time’. The behavior of our spectrum analyzer was as expected, except for the inversion problem previously discussed.

Suggestions:

This lab took us quite a while, on the order of 6 hours. One major problem we had was including the math library. Initially, we thought that if it was included in the project make file, then this was sufficient. However, we learned that we must actually include the math.h file in the C code. Even when we didn’t include the header, no compilation errors occurred, but our FFT was incorrect. Secondly, we had a problem with the optimization options in the compiler. We experienced strange behavior when the compiler tried to fully optimize the code. As a result, our code output became unpredictable. When we removed the optimization options, the code worked correctly. My only suggestion for this lab would be to explicitly state in the lab manual that the programmer needs to include the math.h file in the code itself. I also liked how the lab was broken down into sections. The idea to first make sure the FFT was working correctly was a very good one, and saves a lot of debugging headaches. This I feel was the most useful lab that we did (in C). It was the first time we interacted our ISR with the main loop of the program, and introduced new programming issues (synchronization) that were not present in the previous labs.