2
\$\begingroup\$

I've built a toy oscilloscope with an Arduino, acquiring the samples with the ADC and plotting the spectrum on my computer. The spectrum is the output of the FFT algorithm. You can see a video here of the program in action.

The yellow line is the actual value of each sample as the output from the Arduino's ADC. The red line is the magnitude of each complex number as the output from the FFT function, and the green plot is the angle of each of those complex numbers. The first spike is noise from the AC main power line, which is 50 Hz.

The red plot shows the "energy" of each frequency. What information does the angle shows? Is there an intuitive explanation?

\$\endgroup\$

2 Answers 2

1
\$\begingroup\$

In this case, the absolute angle you are plotting is relative to the phase at which you are taking samples with your ADC. By the way, it looks like your sample rate isn't very stable, judging from how much the speed of the waveform moving across the display varies.

It would probably be more useful if you were to provide a triggering function for your oscilloscope, so that you get a stable waveform display to begin with, and then display relative phase, perhaps taking the phase of the largest magnitude peak as your "zero" reference angle.

Keep in mind that the phase information in FFT bins that have low magnitude values is mostly the result of low-level noise, and won't be very relevant to the overall signal analysis.

\$\endgroup\$
5
  • \$\begingroup\$ You can hardly conclude that from a YouTube video made from screen captures. Though the video is jerky, the wave cycles look about the same length, which they wouldn't be if the sample rate visibly varied w.r.t a steady signal. \$\endgroup\$
    – Kaz
    May 1, 2013 at 14:33
  • 1
    \$\begingroup\$ @Kaz: I'm also looking at how "noisy" the phase data is. \$\endgroup\$
    – Dave Tweed
    May 1, 2013 at 14:40
  • 1
    \$\begingroup\$ Hmm. I think the phase jumps around wildly because the program is basically taking FFT's of sliding windows over the data, and phase isn't coherent from one window to the next. The frequency peak, however, seems to be perfectly frozen on one pixel width. \$\endgroup\$
    – Kaz
    May 1, 2013 at 14:57
  • \$\begingroup\$ The quality of the video is not the best. Also, the piece of code that updates the graphics is not "real time" strictly speaking, there are a few buffers in between the data paths that delays the visual representation of the signal and the FFT. I like your suggestions, I'll see what my little timeframe allows me to do, thanks! \$\endgroup\$
    – user2798
    May 2, 2013 at 1:09
  • \$\begingroup\$ Also, the signal is real actual noise coming from my finger right into the ADC pin of the ATmega328. That would be one thing to consider about the noise in the phase data. \$\endgroup\$
    – user2798
    May 2, 2013 at 1:11
0
\$\begingroup\$

The magnitude of a frequency is not enough to identify the signal, because a frequency is an oscillating wave which exhibits phase. A cosine of amplitude \$A\$ and frequency \$f\$ cannot have the same Fourier transform as a sine of amplitude \$A\$ and frequency \$f\$ because then the inverse Fourier would be ambiguous.

A real time spectrum analyzing program works by looking at windows of samples. These windows usually overlap. For instance, the FFT might be computed from, say, 1024 samples. Then it is computed again, by sliding down the stream, say, 256 samples and taking another 1024 samples to update the next frame of the FFT display. But an arbitrary step by a number of samples usually has no relation to the phase of the signal being tested. In each window, the wave starts on a different phase. Thus the phase angle real time display changes rapidly.

\$\endgroup\$
1
  • \$\begingroup\$ Yes, I've already done all that. That's how the program shown in the video works (I wrote that program). \$\endgroup\$
    – user2798
    May 2, 2013 at 1:02