physical computing

consulting

résumé

projects

images

blog

Email Clock

 
Like many people, I have a lot of anxiety about my email inbox. With every kilobyte that comes in, another minute of my life disappears, time I could spend doing things I enjoy more than checking email. But I can't stop checking my email compulsively while I'm working, and email programs make it even easier to feed my compulsion. So I decided to embody my anxiety in a device that would compulsively check my email for me, and worry over the amount continually coming in, so I wouldn't have to.

Being that I am obsessed with time, and with mechanical things, I like clocks a lot. In particular, I like analog clocks. I find the gear mechanisms very satisfying to watch, and to play with. Naturally, I decided that my email anxiety fetish device would be a clock. This clock would run at a normal pace when there is no email waiting for me, but every new kilobyte of email would drive it hyperactively forward. The clock would worry over the volume of my email so I wouldn't have to.

In theory, the clock would work like this: a java application living on an application server would check my email accounts, noting when new data arrived. With each new message, the application would send the number of bytes to a microcontroller attached to the internet. The microcontroller would then move the clock. Here's a basic system diagram:

The first step was to figure out how to control the pace of a clock. While I would have loved to build a clock from scratch, all custom mechanics, I knew this would take too much time. So instead, I ran down to the local K-Mart, and bought a cheap Martha Stewart Everyday Living™ clock. It seems appropriate that on top of all her other product lines, Martha's doing time these days as well.

The clock's guts are pretty simple. A battery drives a circuit controlled by a quartz crystal, and that circuit triggers a solenoid, which in turn Internal workings of the clockrotates a magnet motor in its magnetic field. That motor drives the gear train for all of the hands, so by controlling the motor, I could control the whole thing.

I took the clock apart carefully, noting which gears went where, so I could get to the circuit board underneath, and find the contacts for the solenoid. I figured all I 'd have to do was pulse the solenoid, and the clock would tick happily away.

The circuit board had at its heart a mystery chip, sealed in plastic. I didn't know what it was, but the crystal and the solenoid terminals were pretty easy to spot. I soldered a couple of leads onto the solenoid contacts, and put the clock back together. Then I pulsed the solenoid from a PIC microcontroller. The motor jumped, but the clock didn't tick.

I'd better observe what happens when the clock is actually working, I thought. So I took the clock off the microcontroller, put its battery back in, and connected the leads to an oscilloscope to see the voltage change it needed to tick. It turned out to be a more complex pattern than I thought. It ticked like this:

Each second the pulse would alternate: high-low-zero one second, low-high-zero the next. Armed with this knowledge, I set out to duplicate the pulse pattern on the microprocessor. This took a lot of experimentation to get the pattern right. I was working in PicBasic Pro, and discovered that many of the standard commands for setting pins high or low didn't give me precise enough timing. Other commands, such as pulseout and PWM, were plenty fast enough, but would give me several thousand pulses a second, when I only wanted one. I finally resorted to a short assembly language routine to just set the pins high and low at the times needed. Here's the final PIC code. It's clunky, but works.
This is where things split. For version 1 of the clock, I used a Java mail checking server, a Netmedia Siteplayer, and a PIC. For version 2 of the clock, I used an Arduino module, a Lantronix Xport serial to ethernet module, and a Perl CGI program. Read on for version 1. Here's a link to version 2.

I could control the clock ticks pretty well from my PIC microcontroller, so the next step was to get the PIC to check mail. It was much easier to have a server check my email so I wrote a java application that lives on my web server, and monitors my email accounts for incoming messages. When new mail comes in, it sends out a Universal Datagram Protocol (UDP) message over the net to a specific address. The message just says how many bytes of mail have just arrived.

To receive the UDP message, I used an embedded net coprocessor called Siteplayer. This is a microprocessor that can send and receive UDP datagrams over the network, and display simple HTML pages. Essentially, it's a web and UDP server on a chip. It communicates with the microprocessor serially. By formatting a UDP datagram specifically for the Siteplayer, you can have it send the data of the datagram directly out its serial port for the microcontroller. Likewise, you can have the microcontroller format a datagram for the Siteplayer to send out to any other computer on the network.

The PIC tells the Siteplayer to listen for UDP messages when they both start up, then listens for any incoming messages via the Siteplayer. The Java program on the server checks the mail, and sends a UDP message to the Siteplayer containing the number of bytes. The Siteplayer passes that number through to the listening PIC. The PIC then drives the clock forward.

How well the clock alleviates my anxiety over my inbox remains to be seen.

My java mail monitor is based on the monitor example from the javamail classes, available from java.sun.com.

Here's the siteplayer .spd file as well.