Project Completed: My $.99 Christmas LED hat, with ATtiny13 controller

Well, it’s done! Here’s my ATtiny13 controlled Christmas LED hat. It consists of an 8 pin, ATtiny13 microcontroller, a pair of 2N3904 transistors and some 1K resistors, a 7805 voltage regulator with two filter caps, and a switch, all mounted on a Radio Shack perfboard inside an Altoids tin. I’m rather pleased with the way it turned out. I always like it when a project goes from the breadboard to a final mounting in a box.

Addendum: Here’s the schematic for the entire circuit. Nothing too surprising, but you should be able to follow it if you need to.

The “Hello World” of Servo Programming on the Arduino

This morning I woke up around 5:30AM to catch the lunar eclipse. It was pretty nice: totality began around 6:05AM and the moon became incredibly dark and red. But 30 minute later, it had progressed low enough that it entered the offshore clouds that signaled the arrival of the morning fog. So, I came back, and went to bed.

When I woke up, I knew that I wanted to try something easy with my Arduino. A few weeks ago, I was in a Radio Shack (gasp!) and saw that they carried the Parallax servos (rebranded Futaba servos, if memory serves) so I picked one up, thinking “I should hook this to an Arduino, because I’ve never done that.”

Well, so I did.

So… what can I do with this?

I could use it to pan a webcam back and forth, perhaps under control of a web page.

I could hook up an ultrasonic sensor, and scan for obstacles.

I could rotate an object, and create an animated gif allowing you to see all sides

And ultimately, I could do some kind of animatronic thing.

I know, it’s not very impressive. But it’s a start. And as I’ve heard before, the journey of a thousand miles begins with a single step.

More on $.99 Christmas lights…

I didn’t have a lot of time to do anything significant tonight, but I wanted to test a few things about this strand of Christmas lights using a multimeter and some simple math.

Recap: there are two strands of LEDs, each wired in parallel. One strand consists of 4 red and 4 yellow LEDS. The other has 4 blue and 3 green LEDs. When powered by two AA alkaline cells, the two strands combine to draw about 40ma of current.

While mulling what I could do with them during the day, it seemed obvious that I could use my ATtiny13 pumpkin circuit to drive the LEDs. While the ATtiny13 is just an 8 pin DIP, it has two PWM outputs, each of which could drive one strand. My pumpkin was powered by 2 AA batteries. The ATtiny13 should have no problem sinking 40ma of current on two pins. Since the LED strands can be powered by just 3V, I could run the entire thing off just the two AAs.

But there is one thing that is a bit wonky: the yellow LEDs. They are really dim compared to the other LEDs. One is sort of okay, but the other three are really feeble. I thought it was possible that maybe the yellows were just feeble (they usually aren’t as bright as good red or green LEDs), but I had another hypothesis: that the forward voltage for those leds was really close to 3v, and they weren’t really conducting properly.

To a first approximation, until the voltage across the diode reaches the forward threshold value, the diode doesn’t conduct. If the yellow LED was barely meeting (or not) meeting its forward voltage, then it’s not passing as much current as the other LEDs. In fact, in this parallel arrangement, it means that the other LEDs are passing more current than you would think (the overall current is still limited by the current limiting resistor in the circuit, but the balance is wrong).

So, I hypothesized that if I raised the voltage perhaps I’d get more even illumination. I hooked up a 5v supply, and… yes! the lights did seem a bit more even, and the yellows, while not exactly blazing, were at least reasonably illuminated. I then hooked up a ammeter to measure the current through the circuit. I knew it would be higher (obviously, since the LEDs were brighter). Indeed, it measured 120ma or so, nearly 3x the current. To keep the same 40ma current, I’d need some additional current limiting resistance. I tried inserting a 220 ohm resistor, and the green and blue strand were nearly completely extinguished, and only the red LEDs of the red/yellow strand were illuminated. Obviously the voltage drop across the resistor was too great to cause the forward voltage of most of the LEDs to conduct.

So, I dusted off a small 200 ohm pot from my junk box, and inserted that. I then tuned the resistance to match the 40 ma of current that we saw at 3v. And, indeed, while the current draw was the same, the illumination was quite a bit more even: the yellow LEDs were quite reasonable.

This suggests that maybe the right thing to do is to drive the LEDs with a bit higher voltage. I’m now thinking that I’ll power the ATtiny and the LEDs with a 9v battery into a 5v regulator. Since the capacity of the 9v battery is a bit lower, it won’t last as long, and we are wasting more energy in the current limiting resistor (I need to add about 47 ohms of resistance to lower the current draw to just 40ma) but I’ll get better illumination.

We’ll see how this works when I get it on the breadboard.

Preamps and Microphones…

A few weeks ago I did an experiment that stored an 8 bit PCM file in the flash memory of an Arduino, and then used PWM to flash a laser at a high rate so I could transmit that audio over a long distance to a solar cell based receiver. A few days ago, I assembled a nifty little gadget called the bliplace, which interfaced a small electret microphone to an AVR ATtiny processor. For the last couple of days, I considered merging the two: the idea was to build a small interface circuit to condition the signal from an electret microphone to feed into the A/D converter of an Arduino. Then, it would be simple enough to use the Arduino to modulate the PWM output.

I’m a bit confused about the bliplace, it doesn’t seem to employ any kind of preamp to increase the output. My understanding is that the output from these kind of microphones is typically quite low, so a preamp would seem to be necessary to boost the overall voltage swing to something that the Arduino can measure with some precision.

My idea was to use a simple op amp circuit to boost the voltage from the microphone, and center it around 2.5v. It’s not hard. You create a resistor divider to halve a 5v supply, and put it into the non-inverting input of the op amp. You then feed the input signal through a blocking cap (I used 0.1uF) and a 1K resistor into the inverting input. Then, feedback from the output of the amp is fed through a 100K resistor back into the inverting input. Here’s the schematic in LTSpice:

I put it together today on a breadboard, and it seems to work. I couldn’t dig up a suitable microphone (I know I have some somewhere), but I’ll get to it in the next day or two and get it all soldered up so I can hook it to my Arduino. Since the LM324s are a quad operational amplifier, I could even use the spare op amps to do some additional filtering. I’m still working on that part.

Through some strange coincidence, a couple of other people I know have been playing with amplifiers too. Whisker over at tymkrs has been working on a preamp for a microphone, and MakerDino’s weekly hack at HackAWeek was to build a single transistor preamp. It’s a simple little class A amplifier, and he did a great video:

I played around with the circuit in LTSpice a bit, and it seems to work pretty well. It provides about 36db of gain, and seems reasonably linear. You can get distortion of the input signal is too high, but other than that, it looks pretty good. The gain is enough to convert a 10mV signal to a 600mA signal. Current draw is about 700 microamps with a 3v supply. Not bad! I could use similar circuit for electret preamp. I’ll play with both circuits some more. Thanks Dino!

The Kansas City Standard

I was pondering my laser transmitter the other day, and began to think of how I might transmit digital information from the Arduino to the remote receiver. Since I am old, I remember the old days where programs used to be stored on an obsolete audio storage medium called cassette tape. Indeed, the first storage device I ever used was the Atari 410 tape drive pictured on the right.

The Atari stored data at 600 baud, using FSK (data is stored as short bursts of two different tones, in the case of the Atari 3995 and 5327 hz), using a variant of the so-called Kansas City Standard. KCS was a standard for storing data on cassettes that was developed at a Byte magazine sponsored symposium in 1975.

Data is converted to short bursts of 1200Hz and 2400hz tones to represent zeroes and ones, respectively. Each burst is 1/300 of a second long, meaning that it sends 300 bits per second. Each 8 bit character is framed by a 0 start bit, and a pair of 1 stop bits so that character frames can be identified. It was designed to be a reliable if slow format, and succeeded on both counts. It transmits about 27 characters per second. An 8K download would take about five minutes.

It’s amazing we ever lived through the stone age.

Anyway, I thought it would be fun to make an Arduino library to send this information over my laser link, but first I decided that it would be good to test to make sure I understood how the format worked. So, I coded up a small program to generate some test .WAV files from an input data file. I made the problem simpler by generating the output at the somewhat non-standard sample rate of 9600 samples per second. This considerably simplifies the generation of samples, since they only would have amplitudes of zero, plus or minus one, and plus or minus sqrt(2)/2. I coded up the following C code, and generated this WAV file.

A WAV file that contains an ASCII test message, encoded in Kansas City Standard

The encoder is simple, the decoder, somewhat less so. So, to test that I was generating the proper bits, I used Martin Ward’s decoder written in Perl which did a good job of decoding the sample WAV files. I haven’t tested the robustness of this format with respect to noise yet, but it does appear to work reasonably well.

It wouldn’t be that hard to modify the simple sound generation code I used before to send data in this format. I think I will try to get to that next week.

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <sndfile.h>

 * kc.c 
 * A program which takes a file as input, and encodes it via the old
 * Kansas City Standard - a 300 baud format that was used by old 
 * microcomputers to store data onto cassette tape.
 * We are going to produce a 9600 sample per second output file...
 * Each "baud" is 32 samples long.
 * A '0' is 4 cycles @ 1200 Hz.
 * A '1' is 8 cycles @ 2400 Hz.
 * 0 -  0 R2 1 R2 0 -R2 -1 -R2
 * 1 -  0 1 0 -1

#define R2      (.70710678118654752440f)

SF_INFO sfinfo ;

output(float f)
    sf_write_float(sf, &f, 1) ;

send(int bit)
    int c ;

    switch (bit) {
    case 0:
        for (c=0; c<4; c++) {
            output(0.f) ;
            output(R2) ;
            output(1.f) ;
            output(R2) ;
            output(0.f) ;
            output(-R2) ;
            output(-1.f) ;
            output(-R2) ;
        break ;
    case 1:
        for (c=0; c<8; c++) {
            output(0.f) ;
            output(1.f) ;
            output(0.f) ;
            output(-1.f) ;
        break ;
        abort() ;

encode(int ch)
    int i ;
    send(0) ;           /* start bit... */
    for (i=0; i<8; i++) {
        send(ch & 1) ;
        ch = ch >> 1 ;
    send(1) ;           /* two stop bits */
    send(1) ;

    int i, ch ;

    sfinfo.channels = 1 ;
    sfinfo.samplerate = 9600 ;
    sfinfo.format = SF_FORMAT_WAV | SF_FORMAT_PCM_16 ;

    sf = sf_open("test.wav", SFM_WRITE, &sfinfo) ;

    for (i=0; i<9600/4; i++)
        output(0.) ;
    while ((ch = getchar()) != EOF)
        encode(ch) ;
    for (i=0; i<9600/4; i++)
        output(0.) ;

    sf_close(sf) ;

Speleogroup’s cool LED headlamp design

Fellow hacker Mike Cowlishaw tweeted me a reminder that he had worked on a design for a spelunker’s headlamp that used Luxeon LEDs, and had excellent high performance. I remember that I listened to a talk about this design, but at the time, I wasn’t saavy enough in electronics to grasp the details, and it had slipped from my mind. He was designing a headlamp for caving, where battery life was a serious matter of safety, so efficiency was primary concern. The final design they came up with would drive a 350ma Luxeon LED at full power for over 5.5 hours using 4 high capacity 1800maH batteries, and then would automatically step down the current as the battery voltage faded. Their first designs used an LT1512A constant current/constant current battery charge controller, but the version I think most interesting was just a small Atmel AVR chip driving a IF7422 FETKY (combination power MOSFET and Schottky diode. Very neat! Mike references an interesting AVR application note which gives a complete design for a battery charger, which is indeed somewhat similar. I’m printing it out so I can read it later.

Speleogroup – LED Lamp based upon ATtiny

Thanks Mike!

A simple constant current LED circuit

I’ve been pretty happy with the performance of my linear current based LED transmitter, but that was just sitting on the bench, driving a 20ma device. As I played with the circuit, I began to realize that if I scaled the circuit up to a 1W LED, its deficiencies in terms of efficiency would become more evident. In particular, I began to think about the efficiency: what percentage of the total power delivered by the battery is actually consumed by the LED?

Rather than using my previous op amp circuit, I thought I’d analyze the basic circuit from this Instructable, which I’ve created and reproduced with LTSpice:

I substituted components: I used the every popular 2N3904 and IRF510, and entered a simple model for a 1W Luxeon LED, which has a current drop of around 3.4v. I set it for a 9v supply, just for an example. A quick simulation shows that current through the LED is about 285mA, which combined with the voltage drop means the LED is putting out about 973mw.

But there is also a voltage drop through the MOSFET and through the reference resistor R2. The resistor is easy to calculate: the current through it is the same as the current through the LED (285mA) and the resistance is 2 ohms. The voltage drop is the then .57 volts, and the total power is .57V * 285mA or about 165mw.

So, what’s left? Well, we began with 9v, and we drop 3.4 for the LED, and another .57V for the resistor, let’s say the total drop is 4V. That leaves 5V, and at 285mA or about 1.425 watts. Ouch. The total of non-LED components is about 2.6W, only about 1W of which gets to the LED which nets us about 37% efficiency.

We can do a bit better by lowering the supply voltage: dropping it to six volts lowers the current to around 267mA, but the voltage drop across the MOSFET decreases to just a little over 2V, which drops the power to about 550mw. The net result is the efficiency climbs to about 57%.

Of course now more integrated solutions exist: many of which combine voltage regulation and current limiting in very small packages at high efficiencies. For instance, the LM3407 is a 350mA constant current floating buck switching converter. It can achieve efficiencies of 90% over a wide variety of supply voltages in a very small, inexpensive package. It also appears that you can use it with a PWM input to implement dimmer technology. It seems like a chip like this can be the center of an efficient LED transmitter.

More to think about and play with.

Simulating the Joule Thief with LTSpice

I always think it is good to follow up a practical build of an electronic circuit with some simulation to try to learn some of the underlying design principles. LTSpice is a great circuit capture/simulation system which runs on Windows, but also runs pretty well under Wine. I was a bit intrigued by the behavior I noticed in my video: while the LED lit quite well using a single AA battery with a nominal 1.5 volts, when I connected the circuit to an old, partially depleted lithium coin cell that I extracted from a burned out “throwie”, it did not light my LED despite being measured at a nominal 1.4v or so. I thought this was pretty interesting. I had an idea about what the problem was, so I thought I’d test it in LTSpice.

Warning: I don’t know what I’m doing. That’s why I am doing what I am doing.

Here’s the schematic that I entered:

I determined the value of the inductors (44uH) using an online toroid calculator, specifying an FT-50-43 toroid with 10 turns through it. The K1 statement creates a transformer out of L1 and L2, with a coupling coefficient of 0.99 (just a guess, they are wound on the same toroid, I expect it to work rather well). In the circuit as presented, the battery is represented by the voltage source V1 and the resistor labelled ESR. From a data sheet for EverReady AA batteries, I found that the typical series resistance is somewhere between 150 and 300 milliohms. I picked an LED out of LTSpice’s catalog: no attempt was made to ensure it was close to the random LED I grabbed from my junkbox.

If you simulate it for a half a millisecond, and look at the voltage at Vout, you get the following graph:

If you change the ESR to 30 ohms, and look at the voltage

Here’s a graph comparing them:

We can see that the voltage going into the LED peaks much higher, and remains higher for a significant period longer when supplied with a battery with a lower ESR. Using the FFT function, we can determine that the fundamental frequency is around 64Kh, and we can see that the average current is around 35 ma (a bit higher than the recommended average power for the LED, but not tremendously high, given the high frequency at which it operates).

When we have a 30 ohm resistance, the average current through the LED drops to a mere 3.5ma. While the voltage does appear to peak higher than the forward voltage needed to light the LED, the current supplied is simply too short and too low to significantly light the LED.

This seems to verify my experiments to a degree. But last night, I thought of this, and thought that perhaps I could boost the ability of these coin cells by paralleling them with a capacitor. I yanked out an electrolytic of around 220uF from my junk box, and wired it in parallel with the coin cell. The LED did light, but at a very low frequency, just a couple of Hertz. If I add a similar cap to my simulation, I don’t get this behavior. Not sure what’s going on. Any real engineers in the audience care to school me onwhy what I did here is completely inaccurate/wrong/stupid?

Batsocks – Text on TV – Introduction

The chaps over at the Batsocks blog sell a cute little gadget called the “Tellymate”: a nice little serial->video converter that is very, very simple. It uses a single Atmel AVR Mega, and handful of other extra components to implement a full character mapped 38×25 character display terminal which reads characters from a serial input port. But what’s really great is that they have all sorts of good information on how the gadget actually works, meaning that you can adapt the techniques and ideas for your own use. Very cool.

Batsocks – Text on TV – Introduction.

The interesting bit that the Tellymate implements is a higher density display than can be achieved with the arduino TV-out library that I mentioned a few days ago. It does this by leveraging the SPI output to automatically clock out bits 9 at a time, which gives you enough time to actually stream out 38 characters (about double what I can achieve with the Arduino library). Very neat, but there are some details which are a bit crufty. Lots of good information.

You can tune a banjo, but you can’t tuna fish…

Or can you? Courtesy of the Make Blog, here’s an interesting little musical instrument called a “canjo”, a two string banjo that uses an old 4″ tuna fish can as the resonating cavity. Perhaps I should take a break from my plinky string sounds generated with software, and instead do it the old fashioned way.

Tuna can guitar blog.


Ambisonic Microphone Exp2 Construction

Here’s one for Tom, or anyone else interested in doing ambisonic sound recordings. It mounts four inexpensive Panasonic electret microphones into a tetrahedral array to record sound that can later be processed for surround or other spatialization effects. Seems pretty cool, and they even include the patterns for PCBs that can be cheaply manufactured by ExpressPCB. Nifty!

Ambisonic Microphone Exp2 Construction Documents page.

Jonathan Ward – MIT – Machines That Make

I’ve been interested in all kinds of machine tools for a long time, and in the various projects like Rep Rap and the like that use either additive or subtractive technologies. Now that I am involved more in radio stuff, the prospect of milling small pc boards seams very cool, and this little CNC mill seems to fit the bill. Preserved for later.

Jonathan Ward – MIT – Machines That Make.