On Relay Computers…

I share an interest in old computing technology with several of my friends and readers. An interesting sub-topic within this vast area is the world of computers based upon relays. In the last couple of days, I found cool links to two different relay based computing projects, so I thought I’d pass them along.

First is Jon Stanley’s Relay Computer Two. Consisting of 281 relays, it boasts an 8 bit data bus and a 16 bit address bus. His website gives the kind of dense, technical information that I like to see from a project like this. You’ll see how he implements adders (using Konrad Zuse’s design which constructs a one bit full adder out of two 4PDT relays). Very neat. Lots of cool details. It clanks along at less than 30 cycles per second. Yes, it uses solid state memory (as almost all amateur reconstructions do, it’s simply to expensive to do otherwise) but the result in a clicky, clanky marvel. Check it out (and make special note of the enormous capacitor in the power supply):

Then there is Rory’s awesome series of relay based computers, culminating in the TIM-8. There are all sorts of awesome laudable features in this build. He didn’t want to “cheat” and use solid state memory, so he struggled to find solutions. He ends up storing programs on paper receipt tape as a series of black and white lines which provide control signals to the rest of the computer. These are then loaded onto a motor driven spindle and read by a series of phototransistors (I think, not clear). The tape is rewound and replayed during program execution. Very cool. He also constructed his own solid state memory out of capacitors, with a density of about 9 bits per cubic inch. Very, very cool. Here’s one of his videos, but search around on his site, he has more:

Nice new breadboard and power supply from TAUTIC.com

This is just a plug for a cute little pair of gadgets that I got the other day.. If you are like me and use solderless breadboards to experiment with stuff on the Arduino, you end up with the Arduino and the breadboard connected by a hodge podge of wires, and if you accidently tug on a power supply cord or the USB cord, half connections come undone. Or, you do all this experimenting on the dining room table, and when you have to clear it away for dinner, all sorts of wires become undone. Frustrating. Even annoying.

So, I took out an insurance policy against annoyance and frustration and ordered a protyping board for the Arduino Uno from TAUTIC.com. TAUTIC Electronics LLC is one of those cool little bootstrapped companies that have chosen to embrace the Open Source Hardware ideas and offer products of interest to tinkerers like myself. This prototype board is basically just a solderless breadboard bonded to a blue plastic backer, with the holes properly drilled to attach an Arduino Uno and the necessary hardware. He also makes version for the chipKit microcontrollers manufactured by Diligent.

While I placed that order, I decided to also give one of his dual output breadboard power supplies a try. For $9, you get a nice little board that plugs into a prototype board and provides 5V on the top rail, and 3.3V on the bottom rail. Very spiffy. The boards were shipped to me literally on the day I ordered them, great customer service. Jayson has a number of other cool boards, including some thermocouple boards and a PIC based development board. Check his store out and see if there is something that catches your eye.

A micro-power Arduino Morse radio beacon

My G0UPL QRSS beacon is working pretty well, but is only putting out about 40mw of power, when it probably should be putting out 100mw. I was pondering oscillators in general, and (as I do often) surf for information and inspiration. I found both on Steve “Melt Solder” Weber’s website, in the form of a ATtiny based Wireless Morse thermometer. It was just a cool little circuit, so I tossed it together on a corner of my breadboard.

Works pretty well! I simulated the circuit using LTSpice before I built it, and found that it takes about 2ms for the oscillator to stabilize after powering down. At 12 wpm, each dit lasts 100ms, so it’s pretty clear that you can do a reasonable job of sending morse at pretty much any speed that most humans can use. To test the oscillator, I hooked up a pair of new D cells which were measured at 3.42 volts, and the current draw was a miserly 0.461 milliamperes for a maximum input power of around 1.5mw. The Arduino can supply 20ma, so it’s pretty obvious that you can drive this oscillator directly from an output pin. So, I used the Morse code sketch that I wrote a couple of years ago and voila! Instant beacon.

Regarding the legality, without any antenna, the effective radiated power of this antenna is incredibly low. I haven’t done any analysis of the circuit to state categorically that it falls inside the restrictions of Part 15 wireless devices, but I’d be shocked if it didn’t.

Hadie High Altitude Balloon Project

While listening to the Amateur Radio Newsline podcast this week, I was interested to hear that a group of hams from Ireland had launched a balloon which transmitted digital pictures back from the balloon while it was at altitude, using a version of dl-fldigi. While I was familiar with fldigi, I hadn’t heard of this version, so I did a bit of searching on the web.

First of all, you can find details about the hadie high altitude balloon project here:

Hadie High Altitude Balloon Project

The flickr photostream from the most recent flight of hadie:4 can be found here:

Slideshow of hadie:4 images

Sadly, the balloon had a slower than predicted rise rate (2m/s instead of 3.5) and so overshot England after floating across the Irish Sea and landed in the North Sea. But it’s very cool that we got these live photos back.

Digging a bit more revealed this nice project web page which had many details about the hardware and software they used. They used a serial based camera module previously sold by Sparkfun (now apparently retired), an NTX2 module from Radiometrix which broadcasts on 434.075Mhz, and a cpu based upon the ATmega644P chip. The flight software appears to be written in C, and reads the data from a GPS and the camera module, and repackages it in a custom format called ssdv for transmission over 300/600/1200 baud 8 bit RTTY which can then be decoded by a custom version of fldigi known as dl-digi. Very neat. The radio module that they use has an output power of just 10mw, and yet was successfully decoded over distances greater than 500km. What’s kind of cool about this technique as opposed to (say) the analog Robot32 mode that ARISSAT-1 uses is that the image is broken up into packets, which are transmitted and received independently. The dl-fldigi can send any received packets to a central repository, and thus if any station successfully decodes a packet, then the image can be reconstructed (something that is difficult with analog SSTV).

I didn’t have much to add to this, I just wanted to stash this for later. While the images they got don’t really compare to some of the awesome HD footage that we are seeing shot with GoPro cameras, the immediacy of this seems very appealing, and it’s a good technical challenge.

Alan’s Advent Calendar of Circuits 2011

A couple of years ago, I was big into QRSS and wrote some software to do unattended captures of the portion of the 30M band where people were operating beacons. It was through this rather unconventional means that I first discovered Alan, VK2ZAY, as his callsign scrolled across in DFCW. If you look at this capture from February, 2009, you’ll see Alan’s call near the top, with VK6DI at the bottom, and … NM5DV I think? across the middle.

I soon discovered that Alan had a very interesting blog with all sorts of good electronics stuff. But during this holiday season, he’s raised the bar again: he’s doing one circuit for each day of the Advent calendar. And the circuits are amazing. Thought provoking. Simple. And yet useful.

If you haven’t checked them out, be sure to do so.

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.

Christmas Lights powered by an ATtiny13

While waiting for my bread to rise the other day, I moved my breadboard ATtiny13 circuit that blinked two leds to a small Radio Shack perfboard, added a couple of switching transistors (2N3904s) to power the LEDs, and built a small 7805 regulator (which doesn’t yet have any filter caps, I’ll get to that). But, I couldn’t resist powering it on. And after finding a small solder bridge (a hairlike strand that spattered and connected two of the microcontroller pins), it worked!

Hopefully this stuff will get mounted in a hat this weekend. Stay tuned for the final video.

Addendum: I received one request for the source code. It’s trivial. Here you go.

#define F_CPU   1200000UL

#include <avr/io.h>
#include <util/delay.h>

 * xmas.c 
 * A small program for the ATtiny13 that can control two strands of 
 * Christmas lights.   I found a set of batter powered LED Christmas 
 * lights at CVS on sale for $.99 each.   I took the lights out, and 
 * found that they consisted of two strands: one of 4 red and 4 yellow
 * LEDs, and the other of 4 blue and 3 green LEDS.  Each strand is 
 * wired in parallel and draws about 20ma at 3 volts.  I have a few
 * ATtiny13's lying around, which can use between 2.7 and 5.5 volts supply.
 * I think for this test, I'll wire up a little 7805 regulator to provide
 * 5V, and then control each strand with one of the two PWM outputs.
 * If I want to drive the strings directly from the microcontroller, 
 * I'll have to insert another 50 ohms of resistance to limit the current 
 * to around 20ma per pin.  I could also add a 1K resistor and a small 
 * NPN transistor to drive each pin at the higher voltage.  At 5V, the 
 * strand will draw about 120ma.  

#define LED0    PB0             /* pin 5 on the ATtiny13 */
#define LED1    PB1             /* pin 6 on the ATtiny13 */
#define SWITCH  PB4             /* pin 3 on the ATtiny13 */

int brite, dir ;

int swd = 0 ;
int swu = 0 ;

    DDRB |= (1 << LED0) ;       /* set both LEDs as outputs */
    DDRB |= (1 << LED1) ;
    DDRB &= ~(1 << SWITCH) ;    /* and the switch as an input */
    PORTB |= (1 << SWITCH) ;    /* and activate the internal pull up */

    /* This configures the PWM outputs to be in "Fast PWM" mode. */
    TCCR0A |= (1 << WGM01) | (1 << WGM00) ;

    /* Timer is clocked at F_CPU/8 */
    TCCR0B |= (1 << CS01) ;

    /* COM01 COM00 
     *   0     0     | normal port operation, output compare disconnected
     *   0     1     | toggle output on compare match
     *   1     0     | clear output on compare match
     *   1     1     | set output on compare match
    TCCR0A |= ((1 << COM0A1))  ;
    TCCR0A |= ((1 << COM0B1))  ;
    OCR0A = 0;
    OCR0B = 0;

    for (;;) {
        /* SOLID ON */
        for (;;) {              
            OCR0A = 0xff ;
            OCR0B = 0xff ;
            _delay_ms(1) ;
            if ((PINB & (1<<SWITCH)) == 0) 
                break ;
        while ((PINB & (1<<SWITCH)) == 0) ;
        /* CROSS FADE */
        brite = 0 ;
        dir = 1 ;
        for (;;) {
            OCR0A = brite ;
            OCR0B = brite ^ 0xFF ;
            brite += dir ;
            if (brite == 0 || brite == 255)
                dir = -dir ;
            _delay_ms(2) ;
            if ((PINB & (1<<SWITCH)) == 0) 
                break ;
        while ((PINB & (1<<SWITCH)) == 0) ;

        /* BLINK */
        brite = 0xff ;
        for (;;) {
            OCR0A = brite ;
            OCR0B = brite ;
            _delay_ms(500) ;
            brite ^= 0xff ;
            if ((PINB & (1<<SWITCH)) == 0) 
                break ;
        while ((PINB & (1<<SWITCH)) == 0) ;

        /* CROSS BLINK */
        for (;;) {
            OCR0A = 0xff ;
            OCR0B = 0 ;
            _delay_ms(500) ;
            if ((PINB & (1<<SWITCH)) == 0) 
                break ;
            OCR0A = 0 ;
            OCR0B = 0xff ;
            _delay_ms(500) ;
            if ((PINB & (1<<SWITCH)) == 0) 
                break ;
        while ((PINB & (1<<SWITCH)) == 0) ;


Carmen makes an Arduino Stoplight

Today, Carmen decided that she wanted to give Arduino programming a try. She’s an experienced programmer, but had never tried any of this small embedded stuff, and knows relatively little about electronics, but with a little direction from me, she got the Arduino development environment installed, and we did a bit of playing around. I showed how we could blink an LED, and then showed her how to read switches and even drive a servo motor. She then walked through some of Lady Ada’s tutorials and ended up scavenging a red, green, and yellow LED from some old throwies we had, and coding up a little stop light application:

Here’s the code:

// Stoplight 
// Introductory Arduino program - Carmen & Mark VandeWettering 12/11/11
// with thanks to : http://www.ladyada.net/learn/arduino/lesson3.html
int redPin = 12;                  // Red LED connected to digital pin 12
int greenPin = 11;                // Green LED connected to digital pin 11
int yellowPin = 13;               // Yellow LED connected to digital pin 13
int delayTime = 1000;             // initiate a delaytime amount here

void setup()                      // run once, when the sketch starts
  pinMode(redPin, OUTPUT);        // sets the digital pin as output
  pinMode(greenPin, OUTPUT);      // sets the digital pin as output
  pinMode(yellowPin, OUTPUT);     // sets the digital pin as output

void loop()                       // run over and over again
  digitalWrite(redPin, HIGH);     // sets the Red LED on
  delay(delayTime);               // waits the delayTime 
  digitalWrite(redPin, LOW);      // sets the Red LED off
  digitalWrite(greenPin, HIGH);   // sets the Green LED on
  delay(delayTime*5);             // waits the delayTime * 5
  digitalWrite(yellowPin, HIGH);  // sets the Yellow LED on
  digitalWrite(greenPin, LOW);    // sets the Green LED off
  delay(delayTime);               // waits the delayTime
  digitalWrite(yellowPin, LOW);   // sets the Yellow LED off (and continue the loop)

If you have any experience with programming at all, the Arduino should be pretty easy. If you don’t, it will take a bit more work, but it’s still doable. Give it a try!

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 Wisdom on LEDs…

More important help for the budding young electronics designer:

Little known fact: If you wire up an LED backwards, it actually works as a dark-emitting diode.


Evil Mad Scientist

Note: this also works in computer graphics quite well. Just specify a negative intensity for the light value.

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.

Correction: Schematic for $.99 Christmas Lights

I was in a hurry yesterday, and didn’t draw the LED connections in my schematic for the $.99 Christmas lights properly. Mike pointed it out to me on twitter, so I thought I’d post a corrected version of the schematic. I’ve also updated the schematic in the original post, so no one will be led astray by haste and carelessness.

Dissecting a set of $.99 battery powered Christmas lights…

I was over at the CVS repository today, and saw that they had some small strings of fifteen LED Christmas lights on sale for a paltry $.99 (if you used your CVS discount card). That was simply too much to resist, so I got a couple of strings, and thought that I would use them for a Christmas related electronics project of some sort.

And, of course, it provides a reason to test your basic electronics knowledge as well. (Forgive my more technologically saavy readers, this is gonna be pretty basic, but I found it fun to go through the mental exercise).

First of all, here are photos of the box they came in, just so we are all on the same page:

When you pop them open, you’ll find a small greenish plastic box that holds the batteries, and a string of fifteen LEDs wired into it with green wire. The box has a small switch on it, which if you stare at you’ll see has both an OFF and an ON position, but it can also be set half way to enable a blinking function. Popping two batteries into the case and flipping the switch had the desired effect: Christmas lights!

So, I started staring at them. There are three wires coming out of the battery box. Each LED appears to have five wires operating in its vicinity. One bypasses the LED, and four other wires sprout from each LED (except for the very last one on the string, which just has two connections. A few minutes of thinking reveals that the LEDS must be wired in parallel, with a circuit that looks very much like this:

Ed. note: Mike pointed out that the original schematic was in error. This has been updated.

The lines labelled A and B are just two power lines: each carries power to half of the LEDs. In the “blink” mode, power is applied to only half of the LEDs at a time. Staring inside the box, it appears that there are two discrete plastic cased transistors wired together: my guess is that they are a classic multivibrator circuit. I’ll verify that later.

Okay, enough of boring reality, let’s try to get to the exciting math.

First of all, the package says that we can get “120 hours or more” from one (presumably) set of alkaline batteries. That seems like excellent battery life, but how realistic is it?

First of all, how much power is in a pair of AA alkalines? Wikipedia says we have about 1800-2600 mAh. I bought some cheap AAs from CVS, so let’s say we are in the middle of the range, about 2200 mAh. Naively, to last 120 hours, the current draw can only be 2200 / 120 or about 18ma (this isn’t quite right, but it’s close) which works out to about 1.2 ma of current per LED (did I mention that the LEDs are wired in parallel?). The total power consumed is about 50mw. If we assume the voltage drop from the LEDs is around 2 volts, we need we need to have a series resistance of about 1 v / 18ma or about 55 ohms. It can be a tiny one, since the power consumed is very small.

All this presumes that they were all in parallel. In reality only half the current flows in each of the A and B circuits, so in blink mode, I suspect the power consumed will be cut by one half (ignoring the power consumed by the multivibrator, which should be very low).

But here’s the good thing! The current draw is low enough that it should be possible to power these lights directly from an Arduino, without any additional switching transistors or the like. My intention is to power each of the two strands with a PWM signal, to allow independent fading and glowing.

But I don’t trust my math enough (nor the specified 120 hour life) to just hook this up randomly, so I’ll be doing a little dissection when I get home tonight, to verify that my calculations are roughly correct. Stay tuned!

Addendum: I took a closer look at the tiny circuit board inside the battery case, and was somewhat surprised to see its inner workings hidden under a blob of epoxy. Two driver transistors do appear on the top side. As far as I can tell, no caps or inductors are visible anywhere:

Addendum2: Last night I put my multimeter in series with the batteries in this circuit, and measured a current draw of 40 milliamps in its “steady”, non-blinking mode. That means that the 120 hours on two AAs quoted on the box is likely a fiction, a life of more like 55 hours would seem to be more likely. In blinking mode, the current draw seemed to vary between 20ma and 30ma, but my meter wasn’t able to integrate the current to a stable value.

I’m thinking that I’ll resurrect the circuit that I used for my ATtiny13 powered pumpkin to drive these LEDs. The ATtiny13 has two PWM channels, which could be used to drive the two LED channels separately, allowing some cool color fading effects. I could probably even salvage the case to hold the batteries. Stay tuned.

The art of capacitive touch sensing

I didn’t get a lot of electronics hacking done, but I found myself again playing with capacitive sensing. I found this interesting article on the EE Times website:

The art of capacitive touch sensing

It also pointed me at the following pretty cool Youtube! vid by the folks at Nerdkits:

My experimentation thus far has been mostly confined to using the CapSense library for the Arduino. This library is pretty simple to use, but it has a number of quirks that make it somewhat cumbersome for the uses that I had for it. I’m currently working on a “better” (for my purposes) version. Stay tuned.