X-10 SmartRemote

I’m not even sure why I built this at all. I guess I did always have a childhood fascination with making things that seemed professional in some way. A simulacrum of some expensive piece of A/V equipment, or simple computer games that came in a shoe box with construction-paper cover art.

This is another ancient project I dug up during my recent move to San Francisco: A rather gigantic “smart” remote control for X-10 home automation devices.

I’m only posting this because it seems cute in some ways… like finding one of your childhood finger-paintings. But it was really an awful project in pretty much every way. It was over-engineered, terrible at the job it was designed to do, and of course the battery life was pretty bad.

The extremely clunky user interface is based on a numeric keypad recycled from a very old television set, and a 16×2 alphanumeric LCD. The X-10 codes are transmitted via a reverse-engineered “Firecracker” board. A Basic Stamp 2 controls it all. This is one of my earlier microcontroller projects, from way back in 1999.

[flickr id=”5921077038″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

[flickr id=”5920516143″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

[flickr id=”5921079728″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

[flickr id=”5921081670″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

[flickr id=”5921082132″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

[flickr id=”5921083104″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 

[flickr id=”5921082814″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”] 


Another nostalgic post about an old project that I’m purging from my closet… This time from late-1999 through mid-2000.

The Kiwi was a rather ambitious built-from-scratch Linux PDA that I spent my high school years on. My original goal for this project was reminiscent of the One Laptop Per Child project. I liked typing my notes, but of course laptops were prohibitively expensive. I wanted to design a very simple PDA, with a keyboard, that I could sell to my classmates for $100 a unit.

[flickr id=”5920009823″ thumbnail=”medium_640″ overlay=”false” size=”large” group=”” align=”none”]

To reach that low cost, I needed something extremely simple:

  • A cheap 16 MHz system on a chip, the Motorola 68EZ328 “DragonBall”
  • Minimal amounts of DRAM and Flash
  • A cheap laptop-style matrix keyboard, sourced from a surplus shop.
  • Very low-resolution grayscale LCD, with no touch screen.

With these tight constraints, the project was actually more like a souped up AlphaSmart than a bare-bones PDA. It ran uCLinux, and I could use the uCSimm board to start prototyping the software. This project eventually led to the PicoGUI project, as I needed a special kind of GUI to fit such a small device. And developing PicoGUI led to starting the CIA.vc service.

[flickr id=”5920580416″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”]

The Kiwi prototype was done with a hellish combination of a custom PCB, wire-wrapping, and dead-bug surface mount rework. The PCB acted mainly as an SMT prototyping adapter. All the real interconnection was done with wire-wrapping, as I didn’t trust my design enough to bake it into a PCB right away. Of course, the one thing the PCB was designed to do, it didn’t. So the DRAM chip and serial level-shifter ended up grotesquely blue-wired.

[flickr id=”5920577826″ thumbnail=”medium_640″ overlay=”false” size=”small” group=”” align=”none”]

Despite the mess, this machine did boot Linux. I wrote my own bootloader for it, which I used for initial hardware bringup. It booted the uCLinux kernel from flash, and ran PicoGUI on the tiny LCD. Like most of my projects, it was never finished. PicoGUI took over as the focus of my attention, and I targeted my GUI at larger and less haphazard platforms.


This is a 9×16 LED matrix I made by hand back in 2004, with LEDs I had left over from another, even sillier project. It has a USB interface powered by a PIC16C765 microcontroller, one of the first to feature a built-in USB device interface.

This video post is something of a eulogy for the project. I have been trying to simplify and unclutter my life lately, and to that end I’ve been having to recycle, donate, or throw out a lot of things. This includes old projects of mine. This matrix was a fun way to spend a couple weekends seven years ago, but since then it’s just been taking up space in my apartment. So, before throwing it out, I thought I’d take a few pictures and make a silly video.

For what it’s worth, the firmware and PC source code are still available.

AVRFID 1.1 Firmware

AVRFID Tag PrototypeI don’t normally write bloggy posts on every version of every source file I check in, but every so often an older project sees some more activity, and I love the opportunity to revisit software I wrote years ago. Sometimes I wonder why I wrote such-and-such thing that way and oh my god what an ugly hack. But usually it’s just refreshing to think about a problem I haven’t thought about in a while.

The AVRFID was a quick but rather unique project, back from when I was on a bit of a 125 kHz RFID binge culminating in the design, construction, and installation of a proxcard reader for my garage door. While I was fidgeting around with such things, it occurred to me that you could (using a whole host of dirty tricks) convince a general-purpose 8-bit microcontroller like the AVR to function as a passive RFID tag.

Since then, I received a couple patches:

  • Luke Koops improved the FSK modulation for HID tags, so that the resulting waveform is much more regular.
  • Cesar Fernandez described the HID card format in more detail, and implemented a parity calculation. The 45-bit code is actually composed of four distinct fields:
    • A 20-bit manufacturer code or header, constant for all HID cards.
    • An 8-bit site code, unique to the particular security installation.
    • A 16-bit unique ID. These are often printed in decimal on the back of the card, and they seem roughly sequential.
    • An odd parity bit, covering the other 44 bits.

I didn’t have my RFID gear handy, so Cesar was kind enough to verify it with his official HID reader. So I stamped a new version number on it. If you’re interested in building your own HID card emulator, there is now a much better chance it will actually work with your reader 🙂