Happy Ada Lovelace Day!

From PedgeBank:

http://www.pledgebank.com/AdaLovelaceDay

Ada Lovelace Day is an international day of blogging to draw attention to women excelling in technology.

Women’s contributions often go unacknowledged, their innovations seldom mentioned, their faces rarely recognised. We want you to tell the world about these unsung heroines. Whatever she does, whether she is a sysadmin or a tech entrepreneur, a programmer or a designer, developing software or hardware, a tech journalist or a tech consultant, we want to celebrate her achievements.

It doesn’t matter how new or old your blog is, what gender you are, what language you blog in, or what you normally blog about – everyone is invited to take part. All you need to do is sign up to this pledge and then publish your blog post any time on Tuesday 24th March 2009. If you’re going to be away that day, feel free to write your post in advance and set your blogging system to publish it that day. We will gather as many of the posts together on the day as we can, and we’ll let you know exactly how we’re going to do that nearer the time.

For ongoing updates about Ada Lovelace day, please follow us on Twitter, join our mailing list or see our blog.

http://findingada.com/

http://twitter.com/FindingAda

http://groups.yahoo.com/group/findingada

Who was Ada?

Ada Lovelace was one of the world’s first computer programmers, and one of the first people to see computers as more than just a machine for doing sums. She wrote programmes for Charles Babbage’s Analytical Engine, a general-purpose computing machine, despite the fact that it was never built. She also wrote the very first description of a computer and of software. Anything wrong with this pledge? Tell us!

Here and There

Two interesting places.

Side by side for relative comparison.

Lucky’s Beepy Ball II!

UPDATE! Scroll to the bottom to see the results of the first trial run!

My dog is blind. Well, mostly blind—he can see a few feet and light and dark—but for most intents and purposes, he’s blind. He’s not blind in old age, but blind congenitally—he’s only 3. His name is Lucky. As a golden retriever, he’s obsessed with getting, keeping, carrying, fetching a ball shaped object of any sort. I set out to make a ball that beeps that he can find easily since his hearing is very acute now that he’s been fully blind for a while.

I scratched my original design for the Lucky Beepy Ball that was built around a LM556 timer chip and a handful of components (four resistors, two capacitors, and two signal transistors) as being a little too heavyweight for putting inside a ball. I did a lot of head scratching, reading, and doing other builds to learn more and finally settled on a very simple design: 1 ATtiny13V microcontroller, one piezo speaker, a small battery, and a switch. You can’t get too much simpler than that.

The Atmel ATtiny13V was PERFECT for this job, as it had a low pin count (it’s an 8 pin ATtiny) and operated well in a wide range of voltages. It can operate normally at between 1.8v and 5.5v (the ‘V’ model of the ATtiny13 is the low voltage version) and is plenty fast (I run mine at 4.8MHz on the internal oscillator). Best of all, it can source and sink at least 20mA on its digital output pins, and has a nice 8 bit timer built in that is easy to program for interesting bleepy sounds.

First I prototyped my design on a small piece of breadboard. All the ATtiny13V REALLY needs is the Vcc connection on pin 8, the GND connection on pin 4, and the two legs of the piezo speaker on pins 2 and 3, but I used the breadboard as my programming harness as well so you can see the 6 pin ISP header at the top. It took a little experimentation to get the beep sound the way I wanted it.

I wanted a beep sound that was easily audible by a dog under a lot of conditions. I figured a chirp would probably work the best. It would start at a high frequency above human hearing but dog-audible, and then decrease in frequency over time until it got low enough so that the wavelength was long enough to have good travel properties through tall grass. Long wavelength sound travels greater distances and can pass through solid objects better than short wavelength sound, so I wanted to take advantage of this property. I wanted alternating periods of chirping and silence so that it was easier for Lucky to triangulate the position of the sound. With a constant chirping, I was concerned that the sound reflection would interfere with his ability to locate the source.

Here are the parts all laid out and ready to assemble. This build was going to be free-formed (point to point wiring) instead of boarded on a piece of experimenters board/veroboard since it needs to be compact and fit inside a ball or Kong ball of some kind.

After programming the ATtiny13V with my chirpy sound code, I ruthlessly hacked its legs off with a wire nipper. This was surprisingly painful for me to do… there’s something about defacing a MCU that physically hurts. I wanted unused pins to be out of the way to reduce the possibility of a short and to keep them from interfering with other parts as I put everything together.

The battery I’m using is a 2.4v NiMH battery that I salvaged out of a tiny radio controlled car (one of those Hot Wheels-sized radio control cars that you dock with the transmitter to charge it.) I hadn’t used the radio control car much before it broke, so I took it all apart and saved a few select pieces from it. This battery only stores 70mAh worth of charge, but then I don’t anticipate that the ATtiny13V and the piezo are going to really need all that much. Plus it was the perfect size. I soldered right onto it at each end.

I brought the positive lead from the “bottom” of the battery up to the center pole on the SPDT switch so I can turn this thing off when we’re done playing ball. I soldered the switch’s metal housing directly to the negative side of the battery by using a little liquid solder flux (I have a solder flux pen I use for things like this) to get everything to stick.

Next, I mounted the ATtiny13V directly on the switch, soldering the Vcc pin (pin 8) directly to one side of the switch. Then I soldered the GND pin (pin 4) directly to the metal housing. Pins 2 and 3 that you can see in the right hand picture are going to be wired up to the piezo speaker.

Here the speaker is wired to the MCU and the wiring is done.

Now it’s time to hot glue this mess to make it more shock resistant and to keep everything in place. I’m using a typical craft hot glue gun to turn this all into a big capsule shaped insert that I can put inside a “Kong” brand dog toy to play fetch with.

… to be continued …

 

Spooky Halloween Light Dimmer

Here’s a quickie image gallery of my Halloween Door Light Dimmer system I cobbled together for a spooky Halloween gag.

The basic idea is that I’d use a distance sensor to spot people walking up the sidewalk to my house and slowly dim the lights as they get closer and closer. When they’re standing there at the door, I wanted them to be surrounded by almost-darkness with the white christmas lights flickering dimly while I handed out candy.

To achieve this effect, I knew I’d need a reliable distance sensor that could spot a humanoid/child up to 20 feet away and then I’d need some way to control lights running off of AC current.

I sought out the MaxBotics MaxSonar EZ-1 board to handle the distance sensing (http://www.maxbotix.com/MaxSonar-EZ1__FAQ.html). It’s a clever single-board controller for a 40kHz ultrasonic transducer. It uses a single-transducer model rather than the two-sensor style of Devantech’s. I’ve never used a Devantech sensor, but the MaxBotics model fit my budget and was carried by SparkFun, so I ordered it up.

The controller board supports three different output formats for distance sensing information: Serial, PWM, and analog. I chose to use the analog output and the ATmega8′s built-in ADC to get my distance information.

Here are the subsystems, labelled for your protection.

Here’s the outlet box I built. With the help of the guy at Pini’s Hardware here in town, I got it up to building code as well as getting it functional. It’s four separate lines on the four outlets.

There was something extremely satisfying about labeling the outlets “BIT 0″ and “BIT1″ and so on. They were just bits on one of the ATmega8′s output ports!

Outlet Box

For controlling the lights, I checked out some options out there for controlling house current from TTL that use triacs and optocouplers. One of the better ones I found was the SEMITONE “Open Dimmer” project. http://semitone.sourceforge.net/wiki/index.php/Main_Page

Rather than take chances on my first foray into house current, though, I opted to buy a pre-made board. One of my favorite electronics suppliers, Futurlec, had a great board they made themselves. It was cheap at $25.

http://www.futurlec.com/AC_Opto_Output_4.shtml

I doubted I could make one as cheaply and the construction seemed very solid and had just what I needed. It’s driven by TTL signals and has two separate connectors for interfacing to your uC board. It’s optically isolated, fuse-protected, and uses screw terminals for my AC lines. Perfect!

Relay Board

Here’s a picture of the MaxBotics sonar range finder, on the left, and the 8 LED debugging output device on the right. I plug a ribbon cable with 8 SMD LED’s with 1k SMD current limiting resistors wired to common ground with one LED per bit on PORTB of the ATmega8. I write to these bits to help debug things.

Here’s a closeup of the transducer:

Here’s the ATmega8 controller board I use for most of my projects. Click on it for the Really Big version.

And here it is again with ports labelled.

Because I got started late, I had to do the build in 2 days (actually two evenings, and one morning) and got it working Halloween morning at 9:45am–just in time to scoot off to work.

I think it was a big success. My Halloween guests were suitably baffled by the inexplicably dimming and flashing lights and it created a great atmosphere for handing out treats.

…and I didn’t manage to burn the house down or sustain a filling-rattling electric shock in the process. Always a plus! ·

Pumpkinlight!

I put together a simple AVR-based device to stand in for the tried-and-true pumpkin candle this year. It uses two high-output (12,000 mcd) white LED’s driven (a little too hard) by a regulated 5v supply that’s shared with an ATtiny13v. All of this runs off of a 9v battery and should last for days given the tiny amount of current it draws.

The bill of materials isn’t super long, and I had everything on hand so putting it together was pretty easy. I free-formed the first one, wrote the AVR Studio assembly code, then went back and made a proper schematic and built the second one. The first one is a lot uglier than the second due to all the rework and the extra wiring for the ISP connection.

C1 10uF
C2 100uF
G1 AB9V
IC1 ATTINY13V-10PU
IC2 LMS8117AMP-ADJ
LED1 High output white 5mm
LED2 High output white 5mm
R1 150
R2 470
R3 120
R4 120
R5 10k This is a 10k for a pull-up on the RESET pin
S1 Small SPDT sliding switch
T1 2N3904 Any small signal transistor will do
T2 2N3904 I used the 2N3904 because I have a big bag of them

Here are all of the materials required, assembled in marching order:

Here’s the schematic:

Here’s the finished product (the second one… after I knew what I was doing. My layout still sucks, but it all fits and is fairly orderly.)

Microchip PIC?

At home lately I’ve been trying to learn about electronics and simple analog circuits towards understanding microcontrollers from the bottom up rather than from the top down. In the past, I’ve relied on the kindness of others and/or good books or websites to handle all the component work and stuck to microcontroller programming in C. In C, microcontroller programming is just a bunch of bit operations, shifting, loops, polling, etc. But every time things failed to work like you think they would in “normal” programming (microprocessors) it invariably came down to the hardware, or the interface between the micro controller and the hardware—not the C language implementation or the code itself.

So in working from the electrons up, I’m finally to the point where I’m programming again now that I have a working knowledge of how resistors, capacitors, diodes, transistors, inductors and voltage regulators come into play. But the programming is in assembly, and my only previous assembly experience is on PowerPC architecture (some experience) and 680×0 architecture (a fair amount of experience a long long time ago.)

There are basically two ubiquitous chip families in simple 8 bit microcontroller programming. There are a lot more, but these two are far and away the most popular and often-used. They’re the PIC processors from Microchip and the AVR family from Atmel. The PIC’s seem the most popular overseas and the AVR’s seem most popular in the United states, though the AVR’s are (rightfully) starting to overtake PIC’s.

PIC is an abomination.

Here is a list of things I’ve come to loathe:

1. Program space is organized into 14-bit (yes, that’s FOURTEEN BIT) words.
2. There’s only one register, called W, and it only supports a tiny set of addressing modes.
3. Accessing data is done via the “file registers” which is just a fancy way of describing more 14-bit words in program space.
4. There are no conditional branches, you test condition codes as bit operations with the condition code register and there are only “skip the next instruction” kinds of branching.

I have to stop here and offer an example of how fucked up this is. You have to test the OPPOSITE case you want, with a operand that conditionally SKIPS the next instruction.

;
; I want to see if bit 4 is set in my file register
;
BTFSC SomeFileRegister, 4 ; so I test to see if the bit ISN’T set “Bit Test File and Skip if Clear”
GOTO _TheBitWasSetLabel
.
.
_TheBitWasntSetLabel:
; continue normal execution
.
.

[ elsewhere in the code ]

_TheBitWasSetLabel:
; the condition was met
.
.

Two instructions to do a conditional branch, and you have to test the INVERSE CASE.

Jesus.

What the hell were they thinking?

5. The same thing applies for loop counters, where you do the test at the decrement or increment instruction and SKIP the next statement (which is always a GOTO for conditional branches).
6. It’s an 8-bit architecture, so the working values are all 8 bit, but stored in 14 bit file registers (program memory.) That’s 6 bits wasted when storing data.
7. Storing a string in program space requires building a table of return-literal-value instructions, and then jumping the program counter to the appropriate line by adding to the PC file register. WTF??
8. There’s no stack register. You get 8 nested CALL instructions or INTERRUPTS and you’re out of space.

AVR, fortunately, is a much more sane set of machine instructions, and the C compilers available for the PIC chips handle all this madness for you. Soon I’ll be comfortable enough with the architecture to let the C compiler take care of it for me. Until then I have to boggle at the decision decisions!

Back to the drawing board…

After some critiquing by a few N&V forum members more knowledgeable about power supplies than myself (which is likely to be all of them) I’ve decided I need to do some redesign on the PSU.

I reworked the design a little to reflect my current implementation (the direct battery line for the DTV’s screen) and after some charging and testing I’ve determined:

1) the 3.3v regulator needs to run off the battery directly, not one of the 7805′s… it generates a load for the 7805 which heats it up something fierce.
2) my current NiCd cells are probably shot. They don’t hold a charge for very long at all.
3) my R1 resistor is too large, as I calculated the charge current incorrectly.
4) I would get a lot more efficiency using a switching battery charger controller like some of the ones offered by Linear.