2008-03-19

74AC240 Resonant EL Inverter

Tonight, somewhat to my surprise, I put together a breadboarded low-power inverter for electroluminescent (EL) wire, using a 74AC240 inverter, LM339 comparator, and a 100 mH inductor. I was planning on just playing with series resonance a bit, but after I got the circuit working with a 100 nF capacitor I realized there was no reason not to try it with a 20' length of EL wire.

Nice sine!





I've been trying to design a flexible full-power multi-channel EL inverter, but while the parts are on order this can be a testbed for the series resonant topology. Two inverters from the AC240 play the role of a full-bridge, driving 100 mH in series with 24 nF to +/- 5V. The resonance increases the voltage across the EL wire with each swing, limited in the end by the current that one output of the AC240 can deliver. I measured 18 mA RMS, 33 V RMS, 3200 Hz, which closely matches a theoretical ideal 100mH+24nF series resonant circuit. The neat thing about the resonance is that it turns 5V*40mA = 200mW of input power into about 600 mVA of "reactive power". The power dissipation could be much lower if lower-resistance switches were used for the bridge, or if it wasn't being driven at full duty cycle right up to the resistive limits of the AC240 chip. If we assume that the AC240 is a 20mA current source, then we'd expect to dissipate at least 100mW in the steady state even if every other component is ideal, because the AC240 only stops being able to deliver more power when the full 5V is dropped across it. 5V * 20 mA = 100 mW.

The feedback loop for this circuit is a bit dodgy. To drive a series-resonant tank using a switched voltage, you need to switch the driving voltage in phase with the output current. Because the load is almost completely reactive, the current is 90 degrees out of phase with the voltage. Either you could measure the voltage, then add 90 degrees of phase shift with some kind of filter, or you can measure the current. Many sine-wave oscillators use a transformer winding to sample the current; there's no transformer here so we can't do that. Instead, I measured the voltage drop of the AC240 inverter output, comparing it to another inverter with the same input but driving a light resistive load. When the current switches sign, the comparator trips and flips the full bridge.

In this scheme, the common-mode voltage swings from near 0V to 5V as the bridge flips, but in theory the differential voltage isn't suppose to change sign during the flip. In practice, extra transitions can be a problem. The first circuit I build, using a single inverter to drive side of the bridge, worked right away. When I tried to increase the output current by ganging together three inverters for each side, the circuit became highly unstable. The solderless breadboard probably plays a part, because the inductance of the tangle of jumpers created major ringing on fast transitions. I discovered that I could occasionally get the second circuit to work by touching the feedback network with my fingertips in just the right spot, adding some leakage resistance and capacitance that just happened to stabilize it. Unstable resonant circuits apparently make great proximity detectors and touch sensors.

It might be possible to regain stability with careful compensation of the comparator and feedback network, but I think it would be a better idea to redesign the feedback circuit, either with a sense resistor to make the differential measurement reliable, or with voltage measurement and a 90-degree phase shift. An inexpensive PLL like a 74HC4046 might help, too, by overriding temporary sense glitches and ensuring that the oscillator starts up.

So here's yet another use for the ubiquitous, BEAM-beloved 74AC240 chip.

2008-01-27

HyperPlex lives!

Digi-Key shipped my back-ordered LEDs on Thursday, and USPS delivered them mid-day on Saturday, so I was able to complete the HyperPlex prototype last night.

It works!



I had confidence in the theory, but I'm still thrilled and somewhat surprised to see it translated faithfully into concrete physical form.

HyperPlex construction album

The main purpose of this experiment was to demonstrate the viability of "hyperplexing", which is a topology for multiplexing LEDs using symmetric complementary drive. Using 16 tri-state microprocessor I/O pins and no other support hardware (no resistors, even), this board drives 64 LEDs without any pin needing to source or sink more than about 15 mA of current. At any given time, up to 8 LEDs are lit, so it uses 1/8th duty cycle multiplexing; visually and electrically, it's similar to the standard 8x8 row/column multiplexing, but it doesn't require any transistors or high current sources or sinks.

Might it be of practical use? Sure! If you want to drive more LEDs than you have pins, but you don't want to add extra driver chips or transistors, and you want more brightness than you'd get out of "weak charlieplexing", then one of the hyperplex topologies might be just the ticket. I'll post more on the math and the design space soon. Or if you want to build a dot-matrix display using through-hole techniques, and you don't want to solder any more components than you have to, then the HyperPlex board in its current form might appeal to you.

Since the 16 output lines used up nearly all the pins of the 20-pin ATtiny2313 microcontroller I'm using, I needed a demonstration program that would be interesting without any interactivity. The program also needed to fit comfortably into less than 1k, because the auto-generated display multiplexing code alone takes up half of the 2kBytes of flash memory in the AVR.

Life to the rescue! I'm a life-long (ha) fan of Conway's Game of Life, and it can be coded quite compactly. To keep things from dying out too quickly, I added an implicit constant checkerboard border around the display, so the boundaries and corners are hospitable to life cells. The life board is seeded from a 23-bit maximum-period Linear-Feedback Shift Register, and the tortoise-and-hare algorithm is used to detect cycles. In my early tests, it seems to go quite a long time between resets; at 5 minutes per life experiment, that's 80 years before a repeat. There are many more things to play with in the software, but I'm tempted to design and build a second revision of the hardware with an In-System Programming header before going too crazy with software -- it's hazardous to my fingers to keep pulling and re-inserting the chip every time I want to try new software.

2008-01-22

Backwards again!

The prototype HyperPlex printed circuit boards arrived in the mail today from BatchPCB. This is the first PCB I've designed, and it's exciting to see it become physical reality. There's just one small problem...




Backwards again! This image is reversed, the invoice is normal but the PCB is mirror-reversed. It turns out that Eagle, the PCB layout editor I'm using, defaults to producing mirrored Gerber files for PCB production. The HyperPlex board is so regular that I didn't catch the error on previews.

Fortunately I can still assemble the prototype HyperPlex correctly, I just have to switch sides; the only minor downside is that the silkscreen (vanity text and component placement hints) will be on the top side, hidden by the LEDs.

It'll be lucky indeed if this is the only problem! This turned out to be quite a finicky design, and I expect it'll be hard to build too with everything packed so tightly. I was prepared for the small overall size of the board (1.6" square) but didn't anticipate just how small those pads and traces would end up.

I'm still waiting for the LEDs to ship (they're on back-order), but I'll probably try a test assembly later this week with a few LEDs and a spare socket I have on hand.

2008-01-21

Fixing the Marware Squeak, Take 3


I recently switched from a PowerBook to a MacBook Pro (a little faster, a lot flakier), but I'm still using my minimalist MarWare Sportfolio Deluxe to lug it around. The MarWare case is great, but it has a signature annoyance: the shoulder strap mounting clips squeak incessantly. I've tried oil (nope), I've tried scotch tape (works until it wears out, looks ugly), but I may finally have found the cure:

Heatshrink! A short length of 3/8" black heatshrink tubing around the clip seems to have cured the squeak. I hope the tubing will last until Apple changes notebook form factors again.

Design Sketch: PLL Pulse-Width Demodulator

One of the enjoyable hazards of reading The Art of Electronics is the urge to build something based on what I just learned.

Yesterday, that meant Phase-Locked Loops (PLLs).

It occurred to me that a PLL might be the key to a couple of other things I wanted to try:
  1. Layering a digital data signal onto a DC power signal or current loop, so I could power and communicate with a sensor or other small embedded system over a single pair of wires.
  2. Doing something cool with the Sci-Toys Freespace Laser Communicator.
Both situations require modulating and demodulating an AC signal riding on a DC bias.

Let's abstract away the physical layer, and just assume that we want to send a bitstring over a carrier signal somewhere in the 25 kHz to 1MHz range. We can use a PLL chip, e.g. a 74HC4046, to lock on to the carrier signal. When we capacitively couple the input signal to the '4046, we can size the capacitor for a high-pass filter to get rid of low frequency noise. If we're lucky, interfering signals will be much lower frequency than the signal we're sending (e.g. 60 Hz hum, fluorescent lighting, nearby LED multiplexing, etc.), so we can get away without needing to build a highly-selective bandpass filter.

Frequency-shift keying (FSK) would be a natural choice for the modulation scheme, as used in early modems. We'd pick a pair of frequencies close enough that the PLL can switch from one to the other quickly, and assign them to 0 and 1. The demodulator circuitry would determine which frequency was received by looking at the VCO (voltage-controlled oscillator) control signal from the PLL chip. Generating the signal on the sending end would be easy, using another VCO or a PWM (pulse-width modulated) output from a microcontroller.

Simple FSK has some downsides, though:
  • It isn't naturally self-clocking: you'd need a synchronizing mechanism, and an encoding layer on top of FSK that ensured enough frequency transitions to stay in sync.
  • The PLL has to re-lock with every bit change; making it agile enough for an acceptable bit rate might compromise its stability and noise resistance.
Fortunately there's an easier, more "digital" alternative: pulse-width modulation (PWM). Instead of varying the frequency, we vary the duty cycle of the carrier. For example, we can send a 0 bit with a 1/3 duty cycle pulse, and a 1 bit with a 2/3 duty cycle pulse. A cool feature of the '4046 PLL is that it can be set up to synchronize only on the rising edge of the signal, and we've kept those rising edges at a single stable frequency, so the PLL can acquire lock and stay locked on regardless of what bits we send. If we can send one bit per carrier cycle, it's synchronous and self-clocking -- the rising edge of the signal is the clock, the falling edge timing gives the data.

Ideally we'd read the duty cycle by checking the signal input at the time the PLL output falls: the PLL always outputs a 1/2 duty cycle. But there's a catch: the '4046 PLL chip doesn't output the amplified version of the signal, so we don't have direct access to it. We could do out own amplification and buffering before passing the signal to the '4046, but that seems like a waste of circuitry.

Instead, we can kludge it by repurposing the unused "Phase Detector I" output from the PLL, which gives [ signal XOR vco ]. This output will produce a pulse that either falls (receiving logical 0) or rises (receiving logical 1) at the time that the VCO output falls. It's unfortunate that it's changing at the same time as our clocking VCO signal (we'd much rather have the original signal, which is stable for a long time around this transition), but we can work around that with an RC (resistor capacitor) low-pass filter to delay the pulse a bit, and a Schmitt trigger to clean it up: that'll give us an sigal which is high for logical 0 and low for logical 1, and which stays valid for some appropriate number of nanoseconds after the underlying transition (to let the subsequent gates and latches get set up). The RC might be unnecessary, but it depends on the delays inside the PLL and I wouldn't want to bet on it (at least not without an oscilloscope to confirm all the timings).

At this point we have 3 outputs from the PLL section:
  • LOCK - digital ouput indicating PLL lock (cleaned up with comparator or Schmitt trigger)
  • VCO - local oscillator square wave, rises in sync with input signal, falls to clock bit
  • BIT - bit read from duty cycle indicator, clocked by falling VCO
Great! What could we do with this bitstream?

Well, we could feed it into a microcontroller (µC), but that's kind of boring; since we're having fun with discrete logic, let's see how far we can take it.

Let's feed the BIT input into a series of two 74HC164 serial-in/parallel-out 8-bit shift registers, so we can recognize 16-bit command words in the input stream. That ought to be long enough (if we pick our command words well) that we won't see too many commands in noise if the PLL locks onto a spurious signal and starts spouting garbage bits.

To recognize some constant words, we'll use a pair of 74HC688 identity comparators. Some really interesting combinatorial analysis would probably yield a vocabulary of codewords with maximal robustness against errors, but (for once) I don't feel like doing the analysis.

Let's try a simple scheme like '01110101WWXXYYZZ'. We get 16 commands, with redundancy to protect again single-bit errors (and many double-bit errors), and no translation collisions. One '688 can match the first byte, the other one can test the redundancy coding in the second byte (with 4 comparisons to spare, in case other constraints are needed).

Finally, let's do something stateful with these commands; since there's no handshaking, the sender will need to send a command many times to make sure it's received, so we want to make them idempotent operations. With 16 commands, we can control 8 on-off outputs, and the 74HC259 8-bit addressable latch is just what we need. Handily, we can clock the '259 from the rising edge of VCO, with no worries about set up time or propagation delay. By setting up capacitors appropriately, we can make sure the '259 is cleared on power up.

I think that's it for the digital logic. We've sketched an 8-channel on/off command receiver using:
  • 1 x 74HC4046 PLL
  • 1 x 74HC132 quad Schmitt-trigger NAND (used diversely for delay buffering, AND, and inversion)
  • 2 x 74HC164 8-bit SIPO shift register
  • 2 x 74HC688 8-bit identity comparator
  • 1 x 74HC259 8-bit addressable latch
This looks an awful lot like an IR remote control receiver, and in practice you'd probably do better to use a cheap IR demodulator and a microcontroller -- it would be cheaper and smaller and simpler. The main advantage of this circuit is that it could (in theory) run at 1Mbps and up. But I have to admit you don't really need to send remote codes at 1Mbps.

Will I build one? Doubtful at this point, given the existence of much simpler IR remote control circuits. If I get a chance to play with an oscilloscope it might be a good test project.

Update: Keith's Electronics Blog covers a similar PLL application, with diagrams.