Week 12: Interface and Application Programming

The assignment for this week is to write an application that interfaces with an input and/or output device. The communication should occur with any of the devices that we have made earlier. Since our lab will be closed due to a Thanskgiving, I will unfortunately will not be able to mill a new DAC board, and so I will have to stick to my original clapper board. This gives me only an audio input and a turn on/off output.

Without much choice, and no fabrication tools at my disposal, I propose an application that outputs a sound waveform (in a nice continuous fashion), and displays it as a function of time in a nice way with a high number of frames per second (unlike in the Neil's example, which is somewhat slow and doesn't seem to coherently represent the real-time sound data). I also decided to add the fft transform to visualize the average periods of the sound data.

Interface code

I'm a fan of Python and I think a great way to display this type of problem is to use the "matplotlib" library, which can produce images of super high quality. However, I've struggled with running it at a sufficient number of frames per second, and decided to search for something else. Rather then going to C++, which would definitely in higher FPS (at the expence of a more cumbersome code), I have decided to go with the "pyqtgraph" library, which is known for high response rates. A great related discussion and a useful code snippet can be found here.

Pyqtgraph library relies on the object-oriented programming capabilities of Python. After defining two block for plotting graphs, I have filled out the main portion of the code in the def _update module of the App class.

Defining interface in pyqtgraph

Generating the data for the sound intensity and its fft vs time

In the main code, I average out 75 samples of audio data and add it to the main data plot in a rolling fashion. The realtime graph consists of 24s of data with 1000 samples. The fft frame covers 24s of data that consists of 501 samples. Note that in the x axis of fft, I plot the average time period.

Hardware code

The hardware code is very similar to the original Neil's code . However, a few notable differences are:

• I increased the Baud rate from 9600 to the maximum value, which is 115200
• I decreased the bit precision for ADC by extracting only the higher bits (by skipping a call of ADCL register). Note that this act will require to shift from the right-adjusted bit readout to the left-adjusted one, which can be accomplished by filling ADLAR part of the ADMUX register.
• Only one variable is saved at a time rather than an entire array.

Hardware code

Results

The resulting graph looks nicely, with the 50-60 frames per second. This increases to 300fps for smaller sample sizes! This probably indicates that the limiting factor here is the intrinsic speed of the read-out of the serial data in python.

Real time (above) and fourier transform (below) of the sound data (as a function of time and average period).

Issues that I faced

• No tool is available on the Thanksgiving week. This was something that I wasn't ready for, and I couldn't fabricate any new boards with other sensors, which I really wished for.
• Many of the common Python's UI libraries have a slow frame rate.
• The microphone board kept on resetting and abruptly shifting the baseline. The problem can be resolved by extracting only the first 8-bit of the ADC register by reading only the ADCH register, while skipping the ADCL (don't forget to modify the Attiny45's ADLAR register in order to switch from the left-adjusted to the right-adjusted bits).

Files

• Python pyqtgraph code
• C-code
• Main code