I wanted a solution for getting digital music from my iPad to my stereo and/or speakers. The iPad doesn’t have a toslink or mini-toslink jack which is a bit of a shame, only offering an analog output (on the other hand, do you really want your iPad tethered to a stereo? no). So the solution is to go wireless and get the music out digitally via itunes.

I didn’t have a decent receiver (curse you, Onkyo, and your buggy TX-NR708). Thus, I decided I’d throw my own amplifier together from a few custom (and not-so-custom components). The design goals:

• Must get music from iPad to Amp digitally
• Remote power on/off from computer (i.e. via IP)
• Remote volume from computer
• Visualization (VU meters)
• Low power in standby and operational mode

So let’s take a look at what we got:

and, a view with some captions describing the components:

So, let’s describe the parts:

IN-13 driver boards. These came from Marc BAREILLE at http://m.bareille.free.fr/vu-in13/vumeter_in13.htm. Marc supplies the circuit boards, you supply all the components. The IN-13s themselves came from eBay, from some place in Russia or Ukraine. These board work pretty good and have the high voltage power supply integrated with them.

DC-DC Converter. Right above the IN-13 driver boards is a DC-DC converter. The op-amps on the boards needed +/0 15v to operate, and it was most convenient for me to use the converter to convert over the 24V supply that’s used for the amplifier.

MiniDSP Stack. This includes MiniDigi, MiniDSP, and MiniAMP. These boards come from minidsp.com. It’s a great little digital amplifier, accepting 2x toslink and 2x coaxial inputs. I’m only using 1 toslink at the moment, but future plans (and those unused buttons on the front) may go toward more inputs and a prop-based switching mechanism.

MotorPot. Regular potentiometers aren’t very interesting. Alps makes some nice motorpots, which are pots with motors attached. This one is a 2 channel linear pot. One channel goes to the MiniDSP to control volume. The the other channel is used as feedback to the microcontroller, so that we can see the motorpot to a known position (motorpot presets!)

24V Power Supply. I went with a small commercial switching supply. The idea was to keep power usage low and size compact. It supplies power for the DC-DC converter (IN-13s) and the MiniDSP stack. The 24V supply is switched via a relay controlled by the microcontroller. Power for the Microcontroller is supplied by a separate 5V switching supply, hidden below the Microcontroller board.

Propeller Microcontroller. This is one of my standard “clock” boards from the clock I never made, repurposed to yet another use. It features on-board ethernet via an ENC28J160 chip. The prop then provides built-in web server support allowing amplifier to be turned on/off and volume set remotely. A LTC1298 ADC is used for reading the position of the motorpot, and a L293D H-Bridge is used to operate the motor. Although the motor says it requires 5.5V for stable operation, it seems to operate pretty well from the 5V passed through the L293D (which drops it two diodes worth, to about 3.5V at the motor).

Code:

I’ll probably do more of a write-up of the code when I get some more spare time. The TCP Stack is PropTCP by Harrison Pham, with a bit of customization (it floats around from project to project, getting a bit more modified as time goes by). The PWM code for running the H-Bridge came from the Propeller Book, in the dancebot (Hanno) section. I wrote a custom controller to operate the motor to seek to specific places with feedback; it’d probably be better replaced with a PID controller.

Apple Airport Express. The Airport Express is the digital music receiver. It receives music from the iPad via AirPlay, converts it to toslink digital output, where it feeds into the MiniDSP stack. There just wasn’t a good way to get the music over ethernet without going with a commercial solution. Fortunately, the AE is small and easily hidden in the case.

Here’s a picture of the web page. It’s rather simple at the moment:

One goal was low power utilization. A kill-a-watt measured power-on at 15.7 watts and standby at 5.4 watts respectively. The lion share of the standby power is probably the airport express. I could eliminate that by adding another relay to switch the AE on and off. Problem is the AE has a significant boot time, and I don’t want to be waiting a minute or two every time I turn on my amplifier before the iPad can connect to it. Un-powering the AE also breaks the AirPlay connection requiring it to be re-established. Better to just leave it on and be done with it.

In addition to the Ipad, I can also listen to arbitrary sources via airfoil:

The above picture shows me connected via VNC to my Linux Server in the other room. It’s running VMWare and a Virtual Machine that’s running Windows XP SP2. On this VM is airfoil and XMicroplayer. XMicroplayer is one of my own programs (http://www.sb-software.com/xmplayer) that allows you to stream Sirius and XM. This gives me a great way to stream Sirius Internet Radio onto the amp. XMicroplayer is much more stable than the crappy Sirius iPad App, or I’d probably use the iPad for the task. Best of all, it’s all using spare cycles on hardware (my Linux VM server) that is already running for other purposes.

Future Plans -

• Input switching. There’s two coaxial digital and one toslink remaining on the miniDigi. I’d like to rig the prop to switch the miniDigi between inputs. Shouldn’t be too hard. Three buttons on the front are unused and could be used to switch sources (three buttons, four sources? I’ll have to get inventive…)
• Auto-on. The AE only outputs toslink optical when it’s receiving a signal. It should be possible to split off the toslink to a photodetector and allow the prop to turn the amp on and off automatically when a signal is detected.
• Composite TV output. My standard clock board has composite output already on it. Can’t think of a good reason why I’d want to watch the prop on the TV, but what the heck, might as well utilize it. I’ve got cogs to spare.

The youtube video (music used was Royalty Free songs from danosongs.com):

In this tutorial, I’m going to show how to interface a Dekatron tube to a Parallax Propeller microcontroller. This is similar technique to what I used in the Packetron-9000 project, although in that project I used mosfets. MPSA42 transistors are much cheaper and a lot easier to interface.

Circuit Description

Above you can see several things. On the top left, we have the high voltage power supply described here. The power supply was modified by substituting a 5.6k resistor for  R1 (the resistor between the pot and ground). This allowed me to get a bit of extra range out of the power supply since it takes about 425V to properly work the dekatron.

Below the power supply is a breadboard with a couple of current limiting resistors and a voltage divider. The voltage divider supplies (22/180)*425 = 52V that is used for the cathodes on the dekatron. The guides must be driven to at least 30 volts below the cathodes to make the dekatron count. -30V is hard to come by, but it’s much easier to just raise the cathode voltage a bit. 52V is close enough.

My original voltage divider used two 180K resistors for a total of 360K resistance on the anode. After experiencing a dekatron failure in a related project, I’ve raised the resistance to 1M. Better safe than sorry.

Below the voltage divider breadboard is of course, a dekatron tube. It’s a russian OG-4 dekatron tube, and is installed in a standard octal relay socket. These sockets are relatively cheap and easy to work with.

On the right, we have a propeller microcontroller from a propeller education kit. The Dekatron’s guide pins are operated using a pair of MPSA42 transistors. The emitter goes to ground, collector goes to the dekatron guide, and base is connected via a 22k resistor to the propeller’s IO pins.

Schematic

All of this is illustrated in the schematic below:

I’ve only illustrated the parts relevant to the dekatron interface — there’s some other mandatory propeller components like the eeprom, reset circuitry, crystal, etc that aren’t shown.

Program Listing

Below is the listing for the propeller program. It’s pretty simple, the guts of it are to pulse the two guide pins on and off. First, P1=On, P2=Off, P1=Off, P2=Off. Repeat that sequence over and over again and the dekatron will spin.

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

  GUIDE_MS = 10
  STEP_MS = 250
  P1=15
  P2=14

PUB main
  dekaSpinTest

PUB dekaSpinTest
  dira[P1] := 1
  dira[P2] := 1
  repeat
      outa[P1]:=1
      waitcnt(clkfreq/1000 * GUIDE_MS + cnt)
      outa[P2]:=1
      waitcnt(clkfreq/1000 * GUIDE_MS + cnt)
      outa[P1]:=0
      waitcnt(clkfreq/1000 * GUIDE_MS + cnt)
      outa[P2]:=0
      waitcnt(clkfreq/1000 * (GUIDE_MS + STEP_MS) + cnt)

Youtube Video

Finally, here is a youtube video that describes all of the above, and more!

Clearly, something better is needed.

We need an indicator that one can tell at a glance exactly how much traffic is coming or going from the Internet.

We need 1960s vacuum tube technology.

We need dekatrons.

Thus, I give you: The Packetron 9000.

Four Soviet OG-4 Dekatron Tubes. Shipped to me from Odessa, Ukraine.

One Parallax Propeller microcontroller with ENC28J60 ethernet interface.

FOUR HUNDRED and TWENTY FIVE volts of pure DC power.

Mosfets, 8 of them, they’re not even supposed to work at 3.3V.

This device requires a youtube video to demonstrate its full potential.

Here’s a view of the internal components of the Packetron 9000:

The nice thing about this project is that almost everything was a surplus design from one of my other projects. In order from left to right, we have:

• Transformer and rectifier board. The transformer is a 12.6v center tapped. I full-wave rectified the 12V to use as a power source for the high voltage power supply, and then pulled off the center tap for powering the logic board. For reasons I’ll never understand (I’m sure it has to do with RMS voltage and calculus), this yielded around 18V and 8.6V.
• Logic Board. It’s a parallax propeller microcontroller with a ENC28J60 for ethernet. The nice thing about the prop is its multicore design. Two “cogs” operate the ethernet, two operate the dekatrons, two run an optional video out for debugging, and a remaining cog operates as a central controller. The Logic board is a leftover from my NTP clock project.
• Voltage divider and current limiter Board. The dekatrons need 300-500 ua or so of current. This little perfboard uses some current limiting resistors (I think I used a pair of 180 ohm resistors per dekatron, that’s probably a bit too much current). Experience a dekatron failure with only 360k resistance per anode, so I upped the resistance to 1M per anode. The current limiting resistors supply the anode power to the dekatrons. A voltage divider is used to derive about 30-60 volts DC for the cathodes. Technically the datasheets tell you to run the guides at -30 to -60 volts, but we can run the cathodes at +30 to +60 and the guides at zero and nobody will be the wiser. It’s all relative.
• High voltage power supply. It’s the standard power supply detailed elsewhere in my blog. I had to tweak the resistors a little bit to set a higher output  voltage of 425 volts. Also made sure the capacitor is suitably rated at 450 volts. I’d have preferred an even higher rated capacitor for safety, but 450v was the largest I could find.
• Driver board. Each OG-4 dekatron has two guide pins. These pins need to be pulsed in a specific sequence to cause the dekatron to count. I used IRF840 mosfets to do this. This presents a problem as the IRF840 does not drive reliably from 3.3 volt logic. I had two different brands of mosfet. The “made in china” ones entered a linear state driving the guide pins to approximately 56 volts (open state was measured at about 132 volts). The “made somwhere else” ones behaved normally, driving the guide pins to zero volts. The china ones had to be cut out of the circuit and replaced. Choosing something else (MPSA42 transistors would probably suffice, or alternatively choose a logic-level mosfet) would be a good idea. New board to try out MPSA42s are already on order from batchpcb.
• Relay board. If we simply turn the dekatrons on with all cathodes connected, then they’ll start up in some random state. The dekatrons have two pins for cathodes — Cathode_zero and Cathode_1_to_9. So, we can boot it up with only cathode zero connected. This ensures all dekatrons start pointed straight up. Then we kick on the relay and apply cathodes 1 to 9. Since cathode zero is already lit, activating the others won’t alter the state. This lets us bootstrap the cathodes in a known state.

So, how does this all work? The control module is implemented in a cog and does the following:

1. The propeller sends a constant stream of SNMP requests to my cisco router. These requests are for four counters on the WAN interface: in-unicast, in-nonunicast, out-unicast, and out-nonunicast. The nonunicast packets I presume are broadcasts as they’re arriving on the WAN interface regardless of whether legitimate work is being done. I suspect they’re DHCP or something similar from the comcast network or the neighborhood. out-nonunicast is effectively zero, so I optimized it out.
2. The in-unicast and in-nonunicast are summed to get the total number of incoming packets. The number of outgoing packets is simply out-unicast since out-nonunicast is zero.
3. I keep a circular buffer that holds the timestamp and count of incoming and outgoing packets. There’s 5 slots in the buffer.
4. Every time the buffer is updated, I compute the delta = (current_count – oldest_count), elapsed = (current_time – oldest_time) and rate = delta/elapsed. This creates a sort of average over 5 samples and smooths out a little bit of burstiness.
5. Depending on the position of the selector switch, I feed either in_rate, out_rate or in_rate+out_rate to the dekatron module, so that the dekatrons will increment at that frequency.

The dekatron module is composed of two cogs:

• The first cog loops at a specific frequency (as determined by the parameter passed to it) and increments a counter. For example, if there are 1000 packets per second, then the frequency is set to 1000 Hz, and the counter will be incremented 1000 times per second. The prop can handle this loop in spin up to a few hundred thousand Hz which is plenty for our purposes.
• The second cog wakes up every 1 ms and looks at the counter, checking each digit. If the ones digit has changed, then the lowest dekatron is kicked over a tick. If the tens digit has changed, then the next-to-lowest dekatron is ticked. Ticking a dekatron involves a simple sequence of G1, G2, ~G2, ~G1. A hundred microseconds between transitions is more than sufficient. The OG-4 dekatrons are only good to a few kilohertz, and that’s the reason for this added bit of complication. By updating every 1000ms, we guarantee we are never spinning a dekatron faster than one kilohertz. The user won’t really be able to tell the difference. The higher order dekatrons preserve correctness in counting, so the most significant digits are accurate.

The remaining cogs serve some utility functions:

• CRT driver. The standard prop video out driver.
• Updater. Takes the current state and outputs it to the video driver, for debugging. This could probably be integrated into the main loop, but it is kinda slow and affects timing, so it was easy enough to push it off to another cog.
• Ethernet driver. Harrison Pham’s proptcp driver, with a good deal of customization. I stored four static SNMP request packets in it (in_unicast, in_nonunicast, out_unicast, out_nonunicast) and send them out via UDP. UDP packets are demultiplexed and SNMP counters are adjusted accordingly. Wrote the UDP checksum and header stuff myself, was kind of a pain to get it right (involved some tcpdump’ing to a linux box to see where I’d messed up the checksums). Also wrote the ARP stuff myself a few years ago, as it did not exist in the proptcp driver at that time. Probably should rewrite all of my code to make use of the newer proptcp stack.
• SPI driver. Part of the proptcp stack.

So, what I really wanted was a Chumby with an ambient light sensor. So…. I set out to make one:

Yes, using a propeller professional development board is a little overkill for the project, but it’s what I had on hand and will suffice until I can make something a little smaller.

The first part of the hack is a small program for the prop that samples a photocell every so often and sends either a “L” or a “D” out the serial port. The photocell is connected in series with a 0.1uf capacitor to pin 23 on the prop, and the PDB’s serial port’s tx is connected to pin 21. The PDB’s serial port is connected via a USB/Serial adapter to the USB port on the back of the Chumby. Here is the prop program:

OBJ
  serial: "FullDuplexSerial"
CON
  _clkmode = xtal1 + pll16x
  _xinfreq        = 5_000_000
  'settings on scott's PDB board
  photoPin = 23
  txPin = 21
  rxPin = 22
  ' settings on scott's USB proto board
  ' photoPin = 0
  ' txPin = 30
  ' rxPin = 31
VAR
  long parameter
  long time
  long wtavg
  long dark

pub main
  serial.start(rxPin, txPin, 1, 115200)

  init_sensor

  repeat
     read_sensor

     parameter := wtavg

     if wtavg > 200000
        dark :=1
        serial.tx("D")
     else
        dark := 0
        serial.tx("L")

     ' do some work
     waitcnt(clkfreq/1000*100 + cnt)

pub init_sensor
  wtavg := 0

  ctra[30..26] := %01000
  ctra[5..0] := photoPin
  frqa := 1

pub read_sensor
  time := (phsa - 624) #> 0
  wtavg := (wtavg * 90 / 100) + time/10 

  dira[photoPin] := outa[photoPin] := 1
  waitcnt(clkfreq/100_000 + cnt)
  phsa~
  dira[photoPin]~

The second part of the hack is a small bash script that runs on the chumby. It reads from a USB-Serial adapter at /dev/ttyUSB0. If it reads an “L”, then it sets the display to bright. If it reads a “D”, then it sets it to dim.

#! /bin/bash
stty -F /dev/ttyUSB0 cs8 115200 ignbrk -brkint -icrnl -imaxbel -opost -onlcr -is
ig -icanon -iexten -echo -echoe -echok -echoctl -echoke noflsh -ixon -crtscts -hup
while [[ 1 ]]; do
  ch=`head -c 1 /dev/ttyUSB0`
  if [[ $ch == "L" ]]; then
      echo 100 > /sys/devices/platform/stmp3xxx-bl/backlight/stmp3xxx-bl/brightness
  fi
  if [[ $ch == "D" ]]; then
      echo 30 > /sys/devices/platform/stmp3xxx-bl/backlight/stmp3xxx-bl/brightness
  fi
done

I placed the script in /mnt/storage/dimmer.sh on the chumby and started it with:

nohup bash /mnt/storage/dimmer.sh < /dev/null > /dev/null &

There are ways to automate execution of the script on startup and I’ll probably do that. In the meantime, my chumby is battery-backed-up during outages, so it’ll never get rebooted anyway.

A video of the hack in action:

Using the PDB’s on-board serial-usb converter

A short follow up… In my tinkering I was also able to use the PDB’s on-board serial-usb converter by using pins 30 and 31 for tx/rx. These are the same pins used by the programming interface. It also works fine using a prop-plug for serial-USB conversion. So, one could probably implement this with as few components as:

propeller microcontroller
eeprom
prop-plug (ttl-serial to usb)
crystal
3.3v power supply
photocell
0.1uf capacitor

Everything needed to do it except the photocell is in the propeller education kit… I might try to prototype it on the PEK, just to show the minimalist approach. The photocell actually used to be in the PEK, but was removed due to ROHS restrictions. Nevertheless I got mine before then. I guess I like to live dangerously.

Update – Implemented on Parallax Propeller USB Proto-Board

The USB Proto-Board is a great deal, and only costs $25 – $30 depending on quantity. It already has almost all of the components we need, including the propeller microcontroller, usb to serial, voltage regulators, etc. The only components needed to be added are the photocell and 0.1uf capacitor. Here is a picture of the circuit prototyped out on the proto-board:

The remaining thing that needs to be done is to turn off the annoying blinky light on the USB-Serial. The proto-board uses an FTDI FT232R chip, and FTDI produces a tool called ft_prog that can be used to reconfigure the lights. I set the output for C1 to CBitBangI/O and that appeared to turn off the LED. You don’t need to mess with C0, as that LED is only used when data is received by the prop, which only happens (in our case) during programming.

Using the USB proto-board, we have a nice little implementation of the circuit.

Anyhow, onward to the schematic: (click schematic for full-size view)

Click on the schematic for a full-size view.

The circuit is a switch-mode power supply based on the popular TL494. I recommend grabbing a dozen or more of these chips from your favorite supplier, as it’s also the chip used in my plasma speaker projects.

The voltage is controlled by the potentiometer, allowing a range of XX to YY (todo: measure this) with the default components. The original design used a 250V output capacitor, but after burning one of those out with a carelessly high voltage setting, I think it’s wise to have the extra leeway afforded by a 450V cap if you have one.

The jumper for deadtime should have a jumper installed to enable the supply.

Below is a picture of the completed board:

So what is a plasma speaker? A plasma speaker (aka “singing arc”) is a speaker that uses a plasma arc to produce sound. By varying the intensity of the arc, different pressure waves are created. Pressure waves produce sound. If you google plasma speakers, you’ll probably come across the instructables article — a lot of people have built that circuit, and this one is a variation of it. The problem is there is so much information in the comments of that instructables article that it’s hard to separate the fact from fiction. At one point I even went and built a “full-bridge” driver that I found there that I never could get working. Some more research led to the circuit that I have here.

NOTE: Click on the schematic for the full-size version.

Let’s start with some of the basics.

Flyback. First of all, the flyback transformer. Most of these DIY plasma speakers use a television-style flyback. You can find these things on ebay relatively cheaply, or you can scavenge them from an old television. Flyback transformers are used to create the high voltages used to drive a CRT screen. High voltage is dangerous, so don’t mess with these transformers unless you know what you’re doing. Most people wind their own primary on the flyback. It’s pretty simple — you just wind 8-12 turns of wire around the iron frame.

Mosfet. We’re going to be dumping 5-10 amps of current into a very low resistance primary winding, and we’re going to be doing it at a fairly high frequency. To do this we use a transistor device called a mosfet. I’m not going to go into all the details of how they work, you can google that. The mosfet is the component that will be generating a lot of heat, and it’s going to need a heat sink. Without a heat sink, your mosfet can be ruined in a matter of seconds. The heatsink should have a fan. A leftover CPU heatsink is a good starting place. Commonly used mosfets are the IRF540, IRF840, and IRFP250. The board I made will accommodate any of these, although I chose the IRFP250 because it’s a monster in size compared to the others. By far the greatest problem with these circuits is blown mosfets from letting them get too hot and/or putting too much current through them.

Mosfet driver. One of the places where the instructables article went wrong is the lack of a mosfet driver and a pull-down resistor. Using a mosfet driver like the TC4429 (or MIC4429) is supposed to lead to cleaner turn-on/turn-off transitions on the mosfet, which is supposed to lead to cooler running and less potential for blown up mosfets.

Metal-oxide varistor (from Tobias’ blog). MOVs are used to bypass high voltage spikes to ground. I’m not entirely sure about how this is supposed to work because I had a lot of issues with it. Selecting too low of a MOV (35 volt or 110 volt) bypassed a lot of current through the MOV. This led to a nice cool-running mosfet but a very very hot MOV. I currently have a 450V MOV installed. It doesn’t get hot, but I don’t know if it’s doing anything either. I did blow a mosfet without it. The primary on the flyback will kick back an inductive spike when the mosfet switches off. I think the idea is we use the MOV to shunt that inductive spike to ground rather than letting it beat on our mosfet. More experimentation needed here.

Snubber (from Tobias’ blog). Ok, I’ll admit I don’t know a snubber from a hole in the wall. It was in tobias’ circuit, so I incorporated it into mine. I believe the goal here is also to smooth out some of the voltage spikes. I can’t tell if it’s doing much in my circuit or not.

TL494 chip. The TL494 is a pulse width modulator IC. It’s commonly used in switching power supplies. We’re going to use it to supply the frequency to drive the mosfet, which in turn drives the primary winding of the flyback. Some designs use a 555 timer IC. The TL494 seems to be overkill for the task. The TL494 has two different output control modes. There’s a parallel mode and a push-pull mode. We want the parallel mode, which in my circuit means jumpering OUTC in JP1 to ground.

Audio modulation (technique 1). So, our TL494 can supply a high-frequency drive signal to run our mosfet, which runs our primary winding. Now we need to modulate that frequency so that it produces variations in plasma arc, which will produce sound pressure waves. There’s two ways to do it. The first from the instructables article is to feed the audio into the deadtime control. This technique will change the width of the pulses that the TL494 is producing. By varying the pulse width we supply a different amount of energy to the primary winding, which will result  in variations in plasma arc, resulting in our sound.

Audio modulation (technique 2). Tobias’ blog shows a different technique. He runs with a fixed dead time, but applies the sound via an op-amp to the RC section of the TL494. This will alter the frequency of the wave going into primary winding. By altering the frequence, we can produce different plasma arcs, creating different sound pressure, and producing our audio. I’m having a bit of trouble with this technique as it keeps throwing my mastech power supply into short-circuit protection mode. Have to work on it a bit, as I think it’s going to be the better technique.

Now, some pictures of my completed board:

And, with some arrows showing the parts:

A couple of waveforms from the Rigol digital scope. Both waveforms are at 10V input to the flyback. The yellow trace is 10V/div and the blue trace is 10V/div. Yellow is the TL494 output to the mosfet driver. Blue is the wire feeding to the flyback primary (taken from one of the legs of the Mov). The first waveform is with the spark gap separated and no arc. The second is with the arc occurring. Frequency in both cases is about 96 Khz. No audio modulation in effect.

(click the waveforms to bring up full-size versions)

Ok, so the voltage on yellow is about 10.8 V peak-to-peak, which sounds about right for our TL494 driven at 12V. The voltage in the blue shows spikes in the range of 160V (pic w/o arc) and 230V (pic w/ arc). The TC4429 is an inverting driver, so when the yellow line goes high, the line to the mosfet goes low, and the mosfet turns off. I’m guessing the blue spikes are the inductive kickback from the primary, but someone with more electronic knowledge than me can confirm this.

Following Tobias’ suggestion, I added some capacitors in parallel with the flyback primary. Some experimentation is necessary here to find the correct capacitance. Adding capacitance may allow you to get a steadier arc at a higher frequency, so some back-and-forth tuning is necessary. I ended up using a pair of 0.01uf/1.6KV capacitors. My first attempts using caps rated at 250V led to quite hot capacitors; it could be because the inductive spike was in the neighborhood of 300V. 600V rated caps would probably be just about right.

Below are some screenshots of the waveforms with arc, at 30VDC, 2 amps on the flyback primary. Frequency was upped to about 130 Khz. The one on the left has no caps, the one on the right has two 0.01uf/1.6KV caps in parallel with the primary:

(click the waveforms for a bigger view)

Adding the capacitors allowed me to get a higher frequency (130Khz) at 30 VDC and a lower current draw (2 amps instead of 4). The mosfet is now running much, much cooler than it did before, and I’m no longer running a hot MOV either. Sound is good, a definite improvement.

Version 2.0: The push-pull driver board:

Started work on the push-pull driver board today (9/20/2010). Below is a picture of the newly completed push-pull driver board on the left, a separate snubber/capacitor board on the right, and an old-school flyback from ebay in the back. Taking the rest of the evening off to watch an episode of House (yes, you heard it here first, Dr. Gregory House, MD, is better than a plasma speaker) so trying out the circuit will have to wait a couple days.

Resumed work on the push-pull board today (6/26/2011). Has it really been nine months? I suppose it has. In that time I managed to completely rebuild a VW sandrail (see other blog posts) and build some cool dekatron gizmos, and actually get some real-world work done to earn a paycheck.

First, let’s have a look at the push-pull driver board schematic (it’ll be too small, so click for a much bigger view):

Push-pull driver board. Click for a big view.

This board incorporates a lot of options. There are jumpers — JP4 and JP6 that allow each driver section to be jumpered independently (they should both be in place for push-pull operation). JP1 selects push-pull (1-2) or parallel (2-3). JP11 is for me to connect an external frequency pot (jump 2-3 to use the on-board pot). JP10 lets me use the op-amp for either frequency (1-2) or deadtime (2-3) modulation. JP7 is an input to the opamp. JP3 is for direct deadtime modulation, similar to the instructables article.

The snubber circuitry has been duplicated for two windings, and moved to a separate board.

The first thing I did was obliterate my new flyback transformer. I purchased some new transformers from ebay that were supposed to be some old-school ones that eliminated the diodes and extra windings and all the crap that the new transformers have. Unfortunately, I managed to quickly burn out the wiring on it, so I went back to the trusty old flyback from the original experiment.

So, a few things are evident with this board – 1) I don’t seem to be getting the frequency range that I used to. 2) I seem to have to run the deadtime pot maxxed out. I don’t remember the original board being that way; perhaps its a property of the push-pull circuit. I really should re-read the datasheet and remind myself how the TL494 worked.

I’m also pulling more power than before. To get a good sounding arc (and it does sound good), I’m pulling 6-7 amps at around 12-14 VDC. I can’t even drive the circuit beyond 17 VDC, because I’m quickly maxxing out the current capacity of my power supply. Being a little careful because I don’t want to burn out more mosfets (so far, so good). I’m sinking the mosfets with just a couple pieces of aluminum angle iron. Here’s a quick view of the experimental setup:

So, anyway, things to figure out for next time — why is this pulling so dang much current? perhaps I should use longer windings on the primary? I’m also going to have to remind myself whether I was frequency modulating, deadtime modulating, or something else on the old board.

References. There’s a lot of research that I did (getting this thing to work has been over 2 years work!). The two primary references I used are:

• The instructables article: http://www.instructables.com/id/Build-A-Plasma-Speaker/
• Tobias’ Blog: http://tobiasmugge.wordpress.com/projetos/plasma-speaker/

Finally, a youtube video of my plasma speaker, as it currently functions:

One of the less popular types of nixie tubes are the bargraph display tubes. The part numbers are IN-9 and IN-13. What’s nice about these tubes is that you can get a continuous bargraph display — it makes a nice alternative to a discrete LED display. People have used them in VU meters and similar circuits.

The IN-13 is the easier of the two tubes to drive, and it’s surprisingly simple. The hardest part is that you’ll need a good 150 VDC supply to power it. I build a little boost converter that runs off 12vdc to provide the 150 VDC. The control the indicator, a simple transistor driver is used using a MJE340 transistor, a resistor, and a pot.

Note that R4 and C1 are only necessary if you’re using a microcontroller that does not have analog outputs (such as the propeller). My goal is to interface the display to a a prop microcontroller so I can use it as an indicator in a few projects. So far, I’ve used a simple PWM output circuit to drive the transistor. Below is a youtube video:

Sourcing Componets -

Gyroscope: GWS-PG-03, Power Hobby
Accelerometer: LIS3LV02DQ, Newark Electronics
Accelerometer Proto-Board: Proto-Advantage
H-Bridges: (2) LMD18200, ebay
H-Bridge proto-boards: Spark-fun electronics
Main Board: Parallax Professional Development Boards
Motor: GHM-16, Lynxmotion
Motor Mounts: Lynxmotion
Motor Rotary Encoder: Lynxmotion
Wheels: Lynxmotion
Robot Chassis: Round alumininum, approx 8.25″ diameter x 3/8″ think, from the junk box at the local metal place.

A couple of the components needed special attention. The LIS3LV02DQ is a SMT package in QFN28 package. I used a proto-board from proto-advantage to adapted it to the usual 0.100″ spacing, soldering it with my hot-air gun. The LMD18200 also isn’t breadboard friendly, but some breakout boards from sparkfun electronics solved that.

The first step was to build the platform that the robot would sit on. I found a nice round chunk of aluminum approximate 8.25″ in diameter in the junk box at the local metal supplier. It was a little thicker than I wanted, but otherwise fit the dimensions and only cost me two bucks. Made a template using SmartDraw to figure out where the motor mounts would go (and get them square and true), and mounted the motors and mounts to the platform:

Next, I secured the Propeller Professional Development Board to the top of the platform using a couple of wood blocks. The PDB is only temporary; I’ll probably make a custom board eventually. Constructed a battery bracket from some more aluminum. A couple of pieces of aluminum flat stock were used to make some guard for the PDB so it wouldn’t get smashed if the robot crashed into something. Here are a couple pictures of the initial prototype of the robot:

Finally, here is a picture diagramming the major components:

Finally, a link to the youtube video:

This accelerometer is a 3-axis using and can communicate digitally via I2C or SPI. It can be interfaced to the prop with no external components (well a couple of bypass caps are usually a good idea) which make it pretty easy. It’s cheap, about $10/chip from newark. The problem is…. it’s a 28-pin QFN surface mount package, and I’m not a surface-mount person. The QFN package does not have pins; it just pads underneath the chip. This makes it a little more troublesome to hand-solder than some of the other SMT devices that do have pins.

So, it seems like the appropriate time to dive into surface mount work. I started by getting a hot air gun, an Aoyue 852A++ rework station for sra-solder.com. It cost $139 plus shipping, which came to just over a hundred and fifty bucks shipped. Seems like a bargain. The hot air station is chinese made, but the brand has good reviews on amazon and elsewhere. It features digital controls and also sports a built-in vacuum pickup tool. Here’s a picture of the rework station:

Above is a picture of the station sitting on my very cluttered workbench. There’s two toggle switches. One is a master on/off and the other switches between hot air and cooldown modes. The buttons are used to adjust temperature.

In order to breadboard the accelerometer, I got some QFN28-to-DIP adapter boards from Proto Advantage. These are little circuit boards with the QFN28 pattern on the top and a DIP pattern for standard 0.100 headers on the bottom.

I started by applying some solder to the pads on the board. Cleaned it up a little bit to make sure that I didn’t bridge any of the traces. Applied some flux to the board. Set the QFN28 chip on the board using some tweezers and aligned the pins as well as my eyesight permitted.

After that, I fired up the hot air station to 400 degrees with an air setting of about 12. Start swirling around the chip with the hot air until you notice the solder start to melt and flow. Shut down the hot air and let everything cool. It’s as simple as that. I didn’t record the time, but I’d say it took under 30 seconds to do the job.

To finish off the Proto-Advantage board, you have to solder the 0.100 headers on the back side. If I’d had some solder paste I think this would have also been a near-instant process. However, all I had on hand was my usual rosin-core throughhole solder, so I hand-soldered the 0.100 headers with my xytronic iron. Here is a picture of the finished product:

Although it kind looks like there are pins in the picture, looks are deceiving. The proto-advantage board has extra-long pads (probably to allow hand-soldering with a regular iron), and you’re seeing the excess solder the flowed out from under the chip back onto the pad. If I’d have used a stencil and solder paste, there probably would have been a lot less excess.

As you may notice, I soldered the chip about 180 degrees rotated from how I probably should have soldered it (the proto-advantage text is upside-down if you orient the adapter with pin1 toward the top). Fortunately, it doesn’t really matter. I’ll just mark pin1 on the adapter with a white dot or some such thing. If that’s the biggest mistake I made on my first SMT attempt, then I’ll be happy.

The next step was to put this thing on the propeller proto-board and see how it works:

I have the three LED displays showing the acceleration on the X, Y, and Z axis respectively. The Z axis points straight up. The X axis runs from the bottom to the top of the proto-board, and the Y axis runs from the left to the right of the proto board. Although it’s indicating 99 (9.9G) on the Z axis, it’s actually measuring 1.0G; I capped it at 9.9 to fit the measurements on the 2-digit display. The X axis is reading 0.1G, probably indicating my computer table is not level. As you tilt the board, the numbers change in the predictable way.

Well that’s it for this post; my SMT attempt was a success. The Aoyue 852A++ hot air station was very easy to use, and I’d recommend it to anyone looking to experiment with SMT work.

Here are a couple of screenshots, one showing the game running on my generic clock controller board, connected to a LED matrix, and the other showing what it looks like on the TV:

The parallax website has another implementation of Game of Life, using the VGA driver and mouse support. I’ve not tried it, but the main loop is in prop assembly rather than spin, and is probably faster than my unoptimized brute-force implementation.

Below is the source code in spin (the parts for controlling the LED matrix are omitted, as they’re pretty specific to my hardware):

' Conway's Game of Life
' Implemented for the Parallax Propeller by Dr Scott M Baker
' http://www.smbaker.com/

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

OBJ
  text  : "TV_Text"

CON
  rows = 8
  cols = 8
  pitch = cols+2
  screensize = (rows+2) * (cols*2)

VAR
  ' The current screen will be held in an array called "cur".
  ' It is large enough to hold (rows x cols) with an additional 1-cell border
  ' all the way around. The one-cell border is so that we can easily reflect
  ' the opposite side to get an infinite playfield.
  byte cur[ screensize ]
  byte work[ screensize ]
  long rnd

PUB main
  text.Start(24)
  text.out($00)

  init
  tvloop

PUB init | i, x
  repeat i from 1 to screensize
     byte[@cur + i] := 0

  ' glider
  'byte[@cur + 3*pitch + 5 ] := 1
  'byte[@cur + 4*pitch + 3 ] := 1
  'byte[@cur + 4*pitch + 5 ] := 1
  'byte[@cur + 5*pitch + 4 ] := 1
  'byte[@cur + 5*pitch + 5 ] := 1  

  ' toad
  'byte[@cur + 3*pitch + 3 ] := 1
  'byte[@cur + 3*pitch + 4 ] := 1
  'byte[@cur + 3*pitch + 5 ] := 1
  'byte[@cur + 4*pitch + 2 ] := 1
  'byte[@cur + 4*pitch + 3 ] := 1
  'byte[@cur + 4*pitch + 4 ] := 1

  ' just do something random
  repeat i from 1 to 25
     x := ?rnd
     if (x<0)
         x:=-x
     byte[ @cur + (x // screensize) ] := 1

' copy reflect the edges of the game to the opposite sides (top goes to
' bottom, left to right, etc)
PUB copyborder | i
  repeat i from 1 to cols
     byte[ @cur+ 0*pitch + i ] :=           byte [ @cur+ rows*pitch + i ]
     byte[ @cur+ (rows+1)*pitch + i ] :=    byte [ @cur+ 1*pitch + i ]
  repeat i from 1 to rows
     byte[ @cur+ i*pitch + 0 ] :=           byte [ @cur+ i*pitch + cols ]
     byte[ @cur+ i*pitch + (cols+1) ] :=    byte [ @cur+ i*pitch + 1 ]

  byte[ @cur+ 0*pitch + 0 ] :=              byte [ @cur+ rows*pitch + cols ]
  byte[ @cur+ 0*pitch + (cols+1) ] :=       byte [ @cur+ rows*pitch + 1 ]
  byte[ @cur+ (rows+1)*pitch + 0 ] :=       byte [ @cur+ 1*pitch + cols ]
  byte[ @cur+ (rows+1)*pitch + (cols+1)] := byte [ @cur+ 1*pitch + 1 ]      

' update the game by applying the game of life rules.
PUB update | r, c, live, liven, i, livec, changes, ptr
  copyborder

  livec := 0
  changes := 0

  repeat r from 1 to rows
      repeat c from 1 to cols
          live := byte [ @cur+ r*pitch + c ]

          ' count the number of live neighbors, starting with the top left corner
          ptr := @cur + (r-1) * pitch + (c-1)
          liven := byte[ptr] + byte[ptr+1] + byte[ptr+2] + byte[ptr+pitch] + byte[ptr+pitch+2]
          liven := liven + byte[ptr+pitch*2] + byte[ptr+pitch*2+1] + byte[ptr+pitch*2+2]

          if (live==1) and (liven>1) and (liven<4)
              ' if a live cell has 2-3 live neighbors, it stays live
              byte[ @work+ r*pitch + c ] := 1
              livec := livec + 1
          elseif (live==0) and (liven == 3)
              ' if a dead cell has exactly three neighbors, it becomes live
              byte[ @work+ r*pitch + c ] := 1
              livec := livec + 1
              changes := changes + 1
          elseif (live==1)
              ' otherwise if a live cell has less than 2 it dies of starvation
              ' or greater than 4, it dies of overcrowding
              byte[ @work+ r*pitch + c ] := 0
              changes := changes + 1

  ' copy the work array back into the screen array
  repeat i from 0 to (screensize-1)
      byte[@cur + i] := byte[@work + i]

  ' if the whole game is dead, or if nothing is changing, restart
  if (livec == 0) or (changes == 0)
      init

PUB tvloop | r, c, count
  count := 0
  repeat
      update
      text.str(string($A, 1, $B, 1, "Conways Game of Life, www.smbaker.com"))
      text.str(string($A, 1, $B, 2, "Iterations:"))
      text.dec(count)
      text.out(13)
      repeat r from 1 to rows
          repeat c from 1 to cols
              text.dec( byte[ @cur + r*pitch + c ] )
          text.out(13)

      count:=count+1

      waitcnt( clkfreq/20 + cnt )