Project MOPTAW

Electret microphone preamp

2010-04-23T22:48:16-07:00

I'm working on a very preliminary electret mic preamp circuit for use with a TI eval board, the ADS1278 8-channel 24-bit ADC.

I'm currently investigating noise levels due to power supply and interconnect, so I have the microphone out of the circuit.

At 48 kHz, high-res mode, 8192 samples, onboard amp disabled, the histogram parameters are as follows, in units of least significant bits:

Differential input shorted:
ENOB 19.29
noise-free bits 16.57

Differential input to prototype board, mic disconnected:
ENOB 15.56
noise free bits 12.83

Same as above, but with more circuitous ground path on protoboard:
ENOB 15.43,15.6,13.06*,15.67
noise free bits 12.7,12.87,10.34*,12.95

*DSP board glitched

Same as above, but with shielded twisted pair connection to dev board:
ENOB 15.34, 15.37, 15.32, 15.52
NFB 12.62, 12.65, 12.59, 12.8

Same as above, but with my preamp's input grounded instead of seeing the 3.3V regulated supply through a decoupling cap:
ENOB: 16.39, 16.15, 16.08, 16.67
NFB 13.66, 13.43, 13.35, 13.95

So, limiting factor is currently the 3.3v regulator.

Looking back to the capacitor-coupled 3.3v regulator input, I see noise at 12.45 Hz and harmonics. Then there are other spikes centered at 216.8 Hz with 12.6 Hz spacings. Curious. The amplitudes are far too low to see on my scope, even after amplification. Looking at the signal in the time domain makes it pretty obvious I'm seeing artifacts from the switching regulator on the dev board making it through the 3.3v. I clearly need a cleaner supply one way or another.

Some quick notes on using a Telit GM862 cellular module with T-Mobile USA

2010-01-17T00:50:59-08:00

I recently got a Telit GM862-GPS module. This is a GSM cellular module with built-in GPS. It took a bit of poking around to get it to work with my T-Mobile SIM card, so here's a quick list of commands that I finally was successful with.

AT#BND=1 # Set US frequency band
OK
AT+CGDCONT=1,"IP","epc.tmobile.com","0.0.0.0",0,0 # Configure GPRS context with T-Mobile's APN
OK
AT+CGQMIN=1,0,0,3,0,0 # Set some default QoS parameters
OK
AT#QDNS="google.com" # Quick test of GPRS using the built-in DNS client
#QDNS: "google.com","74.125.45.104"

OK
AT#SGACT=1,1 # Activate GPRS context 1 for EasyGPRS operation
#SGACT: 25.128.19.217

OK
AT#SD=1,0,80,"www.google.com",0,0 # Connect to google on port 80
CONNECT
GET / # Send CRLF after this
AT#SGACT=1,0 # Deactivate GPRS context
OK

MOPTAW: Halloween edition

2009-11-06T02:33:41-08:00

This was a fun one! Sadly, I ran out of time before getting the eyes to flash, but the iris blink mechanism worked like a charm. I present to you Anne as #3 from 9.

The servo driver is a just a 555, based on this circuit (see section 3). The trigger is a double-throw switch which selects which trimpot controls the position. It's all gorped together with ShapeLock plastic.

May you save the 20 minutes I didn't

2009-09-08T16:19:46-07:00

Platform: Ubuntu 8.10 (intrepid)

$ ruby --version
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]

$ rcov --version
rcov 0.8.1.2 2007-11-22

Problem:

$ rake spec
34 examples, 0 failures, 5 pending
...
/usr/lib/ruby/1.8/rexml/formatters/pretty.rb:131:in `[]': no implicit conversion from nil to integer (TypeError)
...

Aha. It seems the 'rcov' gem is badly out of date. This bug has been reported since 2007.

Install this alternate version:

$ gem sources -a http://gems.github.com
http://gems.github.com added to sources

$ gem install relevance-rcov
...
Successfully installed relevance-rcov-0.9.0
...

$ rake spec
...
34 examples, 0 failures, 5 pending
$

Success!

EL wire experimentation

2009-08-25T13:20:10-07:00

I took a bit of EL wire and stripped off its outer jacket to reveal just the phosphor-coated copper wire, and used an alligator clip holding a single strand of wire to make the connection usually made by the tiny spiraled copper wires. Experiment details are after the video.

I used a signal generator set to 20 Vpp connected to a 1:10 (approximately) step-up transformer. Note that although I held the amplitude of the signal generator constant the voltage impressed across the wire assembly varied by about a factor of 3, almost certainly due to resonance effects involving the capacitance of the EL wire and the transformer secondary. It would be interesting to re-run the tests with feedback control keeping the secondary AC voltage constant as the drive frequency changes.

I was expecting the brightness and color change effects. I unjacketed the wire specifically to see how much of it would glow based on a single secondary contact, but I was not expecting the length of the glowing region to change. It's also somewhat curious that there appeared to be "breaks" in the phosphor in that if the secondary wire was on one side of the break it would not glow on the other wide even if well within the range of glow effect expected given the frequency. (I put "break" in scare quotes because I couldn't actually see anything different in the wire with my naked eye.)

Future experiments:

Regulate transformer secondary voltage, not primary, to remove the resonant voltage boost as a confounding factor in determining brightness.
Examine effects of harmonic content. Getting these through the transformer may be a challenge. I was using a wall wart transformer backward to get the voltage boost, so using a transformer optimized for a wider frequency range may help with this. Driving with a square wave instead of a sine wave produced brighter output, but I was not correcting for the increase in RMS voltage.
Examine a longer segment of wire to see if the "breaks" in the phosphor are a regular occurrence, possibly due to manufacturing technique.
Crease the wire to see if I can induce a "break" in the phosphor.
See if varying the frequency of intact wire can induce a "candy-cane" striping effect with the glow only following the course of the secondary wires. (Please, if you experiment with this and come up with an effect that's the rage at burning man next year or something, drop me a kind word, preferably publicly. Thanks!)

Generalizing the FFT (again)

2009-07-31T20:44:26-07:00

Turns out the twiddle factor pattern, which I had thought was complicated, is actually simple. It looked complicated only because rounding error was nudging the argument of the twiddles back and forth between +/- pi.

The graph shows arg(twiddle)/pi for each twiddle factor for the FFT and the CS-SCHT.

The CS-SCHT's factors are just the FFT's factors quantized to [1, i, -1].

Generalizing the FFT

2009-07-31T00:12:35-07:00

I've been looking at an article in IEEE signal processing: Conjugate Symmetric Sequency-Ordered Complex Hadamard Transform by Aung, Ng, and Rahardja.

Basically they define a transform which shares a lot of properties with the Discrete Fourier Transform but only requires addition and subtraction to implement. In that respect it's like a sequency-ordered Walsh-Hadamard transform, but this one operates in the complex domain and shares symmetries with the DFT. It's kind of cool, but it doesn't have quite enough sidelobe rejection to be very useful for pitch detection above 16 bands or so.

While I was poking at implementing it, though, I noticed that although the transform is defined recursively for a fast implementation in the article, there seems to be a VERY close connection to the decimation-in-time FFT which I didn't see called out in the paper. (It may very well have been and I just missed it.)

Anyway, in a radix-2 DIT FFT the transform of length N is defined as a permutation operation followed by a pair of length N/2 DFTs followed by the "twiddle factors", which are just complex exponentials spaced at multiples of e^(-i*pi/(n/2)). (I'm too tired to look up the LaTeX embedding syntax right now.)

The interesting part is that the CS-SCHT transform in the article above can be expressed identically except that the twiddle factors are different. In the DFT the twiddle factors are a simple sequence of points on the unit circle. In the CS-SCHT all of the factors are +/- 1, except for one that's -i. (It's that property that makes it possible to implement without multiplication). I haven't figured out the pattern yet, but I'm curious to see what it is.

What this gives me, though, is a nice compact way of specifying FFT-like transforms in terms only of the requisite twiddle factors. That gives me a very powerful design technique for integer-friendly FFT-like transforms. More to follow someday.

Pitch estimation

2009-07-12T21:32:45-07:00

I'm working on a more sophisticated pitch estimation algorithm. The one used by the violin mod worked, more or less, but was pretty hacky in order to run in real time on an AVR.
Here's a comparison of the two on the same input clip. As you can see, the old one gave a rough-ish estimate of pitch, but very very noisily.
Old algorithm:

New algorithm:

The old algorithm took the signal and ran it through complimentary low and high pass filters, and estimated the pitch as the ratio between the (approximated) power levels of the two. The new one is FFT based with interpolation between adjacent frequency bins. It works pretty well except at the lowest and highest frequency bands. Currently I'm just brute forcing this problem by using enough bins that the lowest one is close enough to DC that I don't care. With 128 bands I only need to run about 84,000 real multiplies per second at my sampling rate, so that should work for now.

HBL LED Driver working

2009-06-14T01:03:49-07:00

It's officially working! It's kind of hard to see the colors but my camera ran out of battery just after taking this. Each of the 5 LEDs has full RGB color control, 12 bits per channel. The CPU is a 70 MHz ARM7, and the whole thing is an inch square.

The old revision was working too but this incorporates some important fixes. The most important fix is that it no longer cooks the LEDs if you turn it on without valid code flashed. The flaw was that I had the BLANK line of the TLC5941 hooked directly to the CPU. The CPU powers up with the GPIOs in high impedence mode. The BLANK line tended toward a low value, enabling the LED outputs, but since GSCLOCK wasn't running the LEDs were either hard on or hard off. The current programming resistor was high enough that hard on was enough to cook the LEDs I had hooked up. Oops.

Random tip: linking 32-bit c++ binaries on 64-bit Ubuntu

2009-04-29T11:02:14-07:00

Platform: Ubuntu 8.10 (intrepid) 64-bit

Error:
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libstdc++.a when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libstdc++.a when searching for -lstdc++

Solution:
apt-get install g++-4.3-multilib

Random Tip: wine doesn't like a closed file descriptor on stdin

2009-02-24T16:28:06-08:00

I wanted to run a wine process in a daemon context, so I closed the stdin file descriptor. On versions 1.0.1 and 1.1.15, at least, this doesn't work.

This fails:
$ ( exec <&- ; wine cmd /c echo hello ) wineserver: chdir to config dir : Not a directory wine: for some mysterious reason, the wine server failed to run.

Use /dev/null instead.
This works:
$ ( exec < /dev/null ; wine cmd /c echo hello ) hello

Useful ARM processor links

2009-02-19T14:27:18-08:00

For AVR processors, avrfreaks.net has a pretty good parametric device search. I had a bit more trouble finding one for ARM processors. Having done so, maybe I can save other folks a little bit of time:

Parametric List of ARM7/ARM9/Cortex Devices
Parametric search

Next step: make ARMs as hobbyist-accessible as AVRs.

LED Boost Controller

2008-11-15T23:20:14-08:00

The LEDs pictured require at least 8 volts to light in series, but they're being driven by less than 3, through a boost converter. The converter is a TI TPS61161, and was surprisingly easy to solder despite its small size and the thermal pad underneath, even with no solder mask and no solder paste. Surface tension really helps here. I just tinned the board using an iron and reflowed using a hot air gun.

I made the board using Pulsar's PCB Fab-in-a-box kit and direct-rub etch technique. Once I followed the correct set of directions it mostly worked, although I need to refine my technique quite a bit. They advertise 6 mil trace/space capability, but I didn't really get success until up to about 10.

The kit starts with a regular toner transfer pass, using a laminator instead of an iron. Then, you make a second pass with a green film that adheres to the toner, but clings much more tenaciously to the copper. The etching is performed by directly rubbing with a rough sponge rather than submerging. Direct agitation and abrasion causes the coper to be removed quite a bit faster than a regular etch tank.

LED Driver, first prototype assembled

2008-11-01T22:30:15-07:00

I verified the power supply and that the CPU's oscillator is driving the crystal. It'll be a bit longer before I can test the other portions of the system. I used solder paste for the first time when assembling this, which went really well. It made the LQFP 48 and even the QFN 32 packages a breeze. The latter I had expected to be trick or even beyond my capabilities because it doesn't have any pins as such, just pads on the bottom. I just put a bead of solder paste all around the pads on the PCB and used a hot air gun to melt it and it seemed to work fine. I won't know for sure until I have software running on it, of course.

Shameless bragging

2008-10-30T15:46:35-07:00

The violin project made #1 in Fantasy Magazine's Top 10 Steampunk Gadgets!