Commit 719076af authored by Erik Strand's avatar Erik Strand

Major updates, mostly for final project

parent c3e032b5
This diff is collapsed.
+++
title = "Final Project Idea"
date = "2018-09-12"
menu = "main"
weight = 2
+++
## The Analog Analogue Synthesizer
Every electronic circuit has an analogous mechanical circuit whose motion is governed by an equivalent differential equation. Analog synthesizers are electronic circuits, so analog synthesizers have mechanical analogues -- analog analogue synthesizers.
The heart and soul of any classic subtractive synth is its filter section. Most use a ladder of RC circuits to make a low-pass filter (LPF). It takes a raw waveform with a lot of harsh high frequency content (like a sawtooth or triangle wave), and turns it into something more musical.
![](/img/01_rc_ladder.jpg#c)
Two rungs (pictured) give a two pole filter, and four, well, four. I'd like to make a mechanical analog of one such rung. If things go well, I can make multiple and chain them together, just like in the electronic circuit.
## Will it work?
In a normal analog synthesizer, voltage is used to represent air pressure (or more directly, the displacement of a speaker cone). In my analog analogue synthesizer, voltage will be replaced with force. The common electrical components then each have their own analog:
- resistance <---> damping
- capacitance <---> springiness
- inductance <---> mass
So each rung of the ladder circuit will be, in my mechanical version, a damped oscillator.
To be more precise, a normal RC circuit is described by the following ODE:
$$rc \dot{y}(t) + y(t) = x(t)$$
Here \\(r\\) is the resistance in ohms, \\(c\\) the capacitance in farads, \\(x(t)\\) is the input voltage, and \\(y(t)\\) the output voltage (i.e. what we'll need to solve for).
A driven massless damped oscillator is described by this equation:
$$r \dot{y}(t) + k y(t) = x(t)$$
Here \\(r\\) is the damping coefficient (in Newtons per meters per second), \\(k\\) the spring constant (in Newtons per meter), \\(x(t)\\) the input force, and \\(y(t)\\) the displacement of the oscillator.
For appropriate values of the constants these two systems will clearly have the same behavior. So there's hope!
In order to keep forces and velocities within reasonable ranges, I'll aim to operate 100 times slower than normal audio. So a concert A, instead of being 440 Hz, will be just 4.4.
## How would it be made?
Since we'll represent the waveform-to-filter using force, the input has to be a force control servo. I know this can be done either via current measurement, or with a load cell looped into the controller. How hard could it be?
The damping could be provided with a viscous fluid. But, I don't know of viscous fluid dampers that can adjust their viscosity on the fly, which we'll need to do if we want to sweep the cutoff frequency of our filter. Which obviously we do. I only know of one other way to get a resistance force directly proportional to velocity: eddy braking. So we'll need an electromagnet (vary the current to vary the resistance) and an aluminum rail. What could go wrong?
The capacitor, luckily, just becomes a spring. Phew.
Now a normal RC filter contains no inductor. It would be difficult to make my mechanical filter's moving parts massless<sup>[citation needed]</sup>, but luckily this isn't strictly necessary. All RC circuits contain some self-inductance, as all mechanical circuits contain some mass. I'll just try to keep my filter's mass to a minimum relative to the damping and spring factors.
Finally, instead of measuring the output voltage across the capacitor, we'll be measuring the output force across the spring. So we need a load cell.
All in all, here's a simple sketch of the main components for one stage of the filter. If all goes well I'll build multiple of these.
![](/img/01_mechanical_design.jpg#c)
## Frequency Response Analysis
Since our mechanical oscillator won't be massless, we might as well model it with some mass. At least then we know what to expect. This gives us a second order ODE:
$$m \ddot{y}(t) + r \dot{y}(t) + k y(t) = x(t)$$
(The symbols are defined as above, except for the addition of the mass \\(m\\).)
Let the input function be \\(x(t) = A \sin(\omega t)\\). Then our ODE is solved by:
$$y(t) = \frac{-A r \omega \cos(\omega t) + A (k - m \omega^2) \sin(\omega t)}{r^2 \omega^2 + (k - m \omega^2)^2}$$
It has an amplitude of
$$\frac{A}{\sqrt{r^2 \omega^2 + (k - m \omega^2)^2}}$$
For completeness, the first derivative is
$$\dot{y}(t) = \frac{A \omega (k - m \omega^2) \cos(\omega t) + A r \omega^2 \sin(\omega t)}{r^2 \omega^2 + (k - m \omega^2)^2}$$
and its amplitude
$$\frac{A \omega}{\sqrt{r^2 \omega^2 + (k - m \omega^2)^2}}$$
The output of our filter is the force exerted by the spring, or \\(k y(t)\\). I also care about the maximum displacement, the maximum velocity, and the maximum force exerted by the damping system.
......@@ -81,6 +81,5 @@ Remember when I mentioned that cutting climb vs conventional had a noticeable im
I'm really happy with the end result. Here's my room, before and after. I can't imagine going back.
![](/img/06_before.jpg#c)
TODO: after
![](/img/06_after.jpg#c)
......@@ -12,11 +12,11 @@ This week we're making machines talk to each other. I've used I2C before, so I'm
## Board Design
For part of my final project I want to make my own USB audio recording device. So I'll try to develop all the necessary electronics this week. I have the analog circuitry I need from [inputs week](../10_input_devices). But I don't have a board ready to go with a USB-capable microcontroller (bit-banging will not suffice, since I need the CPU to be available for audio processing). I've heard that [LUFA](http://www.fourwalledcubicle.com/LUFA.php) is much nicer than ATMEL's own USB [libraries](https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591207) so I'll try to use that. I'd like to use an XMEGA board, since they are fast, have a good amount of memory for audio applications, and I've used them [recently](../12_machine_week). LUFA's [XMEGA support](http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__x_m_e_g_a_support.html) is technically experimental, but people have been using it since [2013](https://www.avrfreaks.net/forum/lufa-xmega-hello-world). So I think it should be ok.
For part of my final project I want to make my own USB audio recording device. So I'll try to develop all the necessary electronics this week. I have the analog circuitry I need from [inputs week](../10_input_devices). But I don't have a board ready to go with a USB-capable microcontroller (bit-banging will not suffice, since I need the CPU to be available for audio processing). I've heard that [LUFA](http://www.fourwalledcubicle.com/LUFA.php) is much nicer than ATMEL's own USB [libraries](https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591207) so I'll try to use that. I'd like to use an XMEGA board, since they are fast, have a good amount of memory for audio applications, and I've used them [recently](../11_machine_week). LUFA's [XMEGA support](http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__x_m_e_g_a_support.html) is technically experimental, but people have been using it since [2013](https://www.avrfreaks.net/forum/lufa-xmega-hello-world). So I think it should be ok.
![](/img/13_schematic.png)
On the left I have my microcontroller. I'm using an external 16MHz crystal to give it an accurate clock signal. High speed USB 2.0 requires a 48MHz clock, which I can get by multiplying the crystal's output by 3 using the XMEGA's phase locked loop (PLL). On top I have my power section, including a regulator to bump USB's 5V power down to 3.3V, some filtering capacitors, and a power indicator LED. The two circuit groups with op-amps together amplify and bias the audio input, as I learned in [inputs week](../10_input_devices). Finally I have some headers that provide convenient debugging access to certain signals, and a 0-ohm resistor I needed to connect all my ground signals.
On the left I have my microcontroller. I'm using an external 16MHz crystal to give it an accurate clock signal. High speed USB 2.0 requires a 48MHz clock, which I can get by multiplying the crystal's output by 3 using the XMEGA's phase locked loop (PLL). On top I have my power section, including a regulator to bump USB's 5V power down to 3.3V, some filtering capacitors, and a power indicator LED. The two circuit groups with op-amps together amplify and bias the audio input, as I learned in [inputs week](../09_input_devices). Finally I have some headers that provide convenient debugging access to certain signals, and a 0-ohm resistor I needed to connect all my ground signals.
![](/img/13_board.png)
......
......@@ -5,7 +5,7 @@ menu = "main"
weight = 16
+++
Files: [audio_interface_2.sch](/designs/13_audio_interface_2.sch) [audio_interface_2.brd](/designs/13_audio_interface_2.brd) [lufa](https://gitlab.cba.mit.edu/erik/lufa) (see Demos/Devices/ClassDriver/MIDI and Demos/Devices/ClassDriver/AudioInput)
Files: [audio_interface_2.sch](/designs/13_audio_interface_2.sch) [audio_interface_2.brd](/designs/13_audio_interface_2.brd) [lufa](https://github.com/erikstrand/lufa) (see Demos/Devices/ClassDriver/MIDI and Demos/Devices/ClassDriver/AudioInput)
This week there's a lot on the menu: soft robotics, bioprinting, coil plotting, wire EDM, and many more. I'd like to learn them all, but for now I'll continue my exploration of [LUFA](http://www.fourwalledcubicle.com/LUFA.php). So far I have a virtual serial port example working, but let's see what else I can do. Throughout I'll be using the board that I designed and fabricated [last week](../13_networking).
......@@ -48,5 +48,13 @@ To begin I cleared out the LUFA LED, Button, and ADC code since they're either n
#else
{{< /highlight >}}
Now the compiler complains about invalid registers. Progress! To fix this I need to figure out what the registers they use do on smaller AVR boards, then implement the same thing for XMEGA.
Now the compiler complains about invalid registers. Progress! To fix this I need to figure out what LUFA is doing with these AVR8 registers, then implement the same thing for XMEGA. This ended up being pretty easy since I was already familiar with the XMEGA's ADC.
At this point the code compiles, and the board is recognized as an audio device, but can't transmit any audio. More precisely, the board tries to transmit audio, in that it does generate samples and pass them to a LUFA method that should transmit them... but nothing gets through to my computer. Still, I'm excited that it can present itself as a CDC audio input at all.
![](/img/14_audio_device.png)
It turns out there was one final set of modifications that had to be made, and I still don't understand why. I accidentally stumbled across [this thread](https://www.avrfreaks.net/forum/lufa-xmega-endpoint-size) on AVRFreaks, in which someone mentions getting audio to function by changing certain USB endpoint and buffer sizes. Sure enough, after modifying the relevant numbers I could pass audio data to my computer. I posted a message on the [LUFA support list](https://groups.google.com/d/msg/lufa-support/3xiXBc5gCnc/uJQ4Zqq8BgAJ) asking why these changes do what they do, but no one has responded yet. Endpoint and buffer sizes of 64 and 128 bytes work, but 256 does not.
And it's still not working properly. When I record audio on my computer, the [result](/audio/14_interface_test.mp3) ends up shorter and higher pitched than intended. So something is probably going wrong with the sample rate. (It's also obviously bit-crushed, but that's expected since the XMEGA is only sampling with 12-bit resolution.) My current theory is that the data transfer is not happening over isochronous USB, and this is confusing the host driver. The results sure sound like a throughput issue (i.e. the audio board sends less samples than the computer expects, so the computer squashes them together and pads the ends with zeros), but even without isochronous USB I think I should have enough bandwidth for one channel of audio. Perhaps it also has to do with jitter (non-isochronous USB doesn't make the same guarantees about packet delivery times).
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment