Quick Weekend Project: Resurrecting a Clock




I have this Frank Lloyd Wright desk clock. I love the art and simplicity of it. In fact I love it so much that I’ve had it on my nightstand for 2 years without it working! The problem is that the single AA battery last for less than 2 months and I finally got tired of replacing it. I’ve thought about turning it into some sort of digital clock project, but then I had a much simpler idea. I’ll just plug it in.





5 volt power supplies are easy to come by in the form of USB chargers. So I simply took an old iPhone cable and put an axial power connector on it.




Then I bought an adjustable power supply from eBay…




…wired it up with the power socket.






And now I never have to replace another battery. At least not in this clock. I had everything but the power supply on hand, so total cost: 96¢




The Internet of Things is really taking off. The ESP8266 has made it possible to add a powerful process with wifi to any project for a couple of bucks. Whether you doing a one off art project, or are building a home automation gizmo that you plan on funding with Kickstarter, the ESP8266 can be at the core.

I’ve gotten really excited about this new chip and it’s potential, so naturally I decided to write my own scripting language. When you say that sort of thing in the circles I run around in or when you read it in ESP8266 forums, you generally get a lot of push back. Once the rolling of the eyes and general incredulity settle down, you are likely to get any combination of these 3 responses:

  1. Anyone who writes a new scripting language for any reason on any platform is nuts. There’s nothing you could possibly do that hasn’t already been done.
  2. The ESP8266 already has support for many scripting languages already, based on excellent memory efficient and powerful standards (Javascript, Python, Lua, Basic). Trying to add something new, especially a language not based on an accepted standard, is just nuts.
  3. Scripting languages on a platform like ESP8266 incur useless overhead. Native code FTW. You’re nuts.

TL;DR I’m nuts.

So what motivation could I possibly have for doing this? I’ll push back on each of the points above:

  1. There are plenty of reasons for writing a custom language specific to a particular platform. In the case of the ESP8266, it is both much more powerful that other solutions that have come before it (like the AVR chip in Arduino) and much less powerful than traditional computers for which most of these languages were written. So it makes sense to make a language that enhances its advantages while minimizing its constraints.
  2. All the languages currently on the ESP8266 were originally written for more powerful platforms. Even though the versions being ported are generally “micro” versions, they still push the limits of the platform. For instance, they typically leave less than 25KB of ram storage, It’s hard to do anything in that space. And they generally use garbage collection that adds even more overhead to the management of that tiny memory space.
  3. Native programming is fine as long as you want to upload new code every time you make a change. You might think this problem is solved with OTA. But how do you test your changes without crashing the device, which would require you to bring it back to the shop, crack it open and flash new firmware over the serial port. OTA was designed for mass deployment, not experimentation.

One of the great advantages of m8rscript is that I wrote it to be cross-platform. It runs on both ESP8266 and Mac. That has allowed me to write a macOS app which can simulate m8rscript code before deploying on the device.

To be continued…

Open Sprinkler PI


I recently automated my home sprinkler system and I’ve been so happy with the results that I wanted to share my experience.

Getting the Parts

I’ve had a pretty nice Hunter sprinkler controller for years but I wanted to automate the system. So after a bit of research I settled on an Open Sprinkler PI system from Rays Hobby. It had great documentation, is well supported and used a Raspberry PI as its controller. I’ve been wanting to play with a PI for a while now and this was the perfect excuse.

The Open Sprinkler PI system comes with a fully assembled board, a case and extras so you can hook it all up. All you need is the Raspberry PI and a few more parts. Here’s what I bought to get started:

From Ray’s Hobby:

From Amazon:

You will also need a micro USB cable to power the Raspberry PI while you set it up. Note, that’s a micro USB cable, not mini. I pride myself on having every imaginable cable. But I only had one of these and I had a devil of a time finding it. Order one from Amazon if you don’t have one.

You also need a 24VAC transformer. If you already have a sprinkler controller you probably have one of these. Unfortunately for me, my old Hunter unit had the transformer built in. So I went down to Home Depot and found a wall wart in the irrigation department that fit the bill. Amazon carries them as well.

Initial Setup

Setting the system up could not be easier. Much of the information is in the excellent user manual. Assembly is simply plugging the two boards together. But before you do that, set up your Raspberry PI. And before you do that, load the file system image on the memory card.  Download it from here and use these instructions to copy it. I have a Mac and I used the command line technique without any trouble.

This setup assumes you have a home network with a wireless router with DHCP enabled, and that you can access that router with some sort of admin tool (I have an Airport Extreme, so I use Airport Utility).

Once you have the disk image, it’s time to get the Raspberry PI onto your home network. This is the slightly tricky bit, especially if you are like me and want to do it “headless” – without connecting a monitor and keyboard to the PI. Use the low profile memory card adaptor that came with the Open Sprinkler PI and plug the memory card into the PI. Next plug in the Wireless USB Adaptor. You also need to connect to your home network with an ethernet cable. You need to use a wired connection so you can access the PI and setup your wireless network. Now connect the micro USB to power up the PI. You should see blinking lights for a while, but the wireless adaptor may or may not light up.

Login by opening a command line shell on a computer connected to your home network. I use Terminal on the Mac, but you may have to use a 3rd party program if you’re on a Windows PC. The Raspberry PI connects using DHCP, so it should already be on your network.

But first you need to figure out the IP address your PI is connected to. You can guess this if you don’t have many devices connected  and you know where your DHCP addresses start. But the easier way is to open whatever admin tool you have for your wireless router. It should show you all the DHCP clients connected and what IP address they are connecting to. Find the one named “OSPI” and write down its IP address (the 4 numbers separated by periods). Now in your terminal type:

ssh pi@<ip address>

This will respond with a request for a password, which is “raspberry”. Once you’re in you’ll want to setup your wireless network name and password. The best resource for this is on the Adafruit site. All I had to do was  open the network file:

sudo vi /etc/network/interfaces

Adafruit suggests you use nano, I prefer vi, your choice

and then add or modify the following lines:

iface wlan0 inet dhcp
 wpa-ssid "ssid"
 wpa-psk "password"

where ssid is the name of your wireless network and password is the one for that network. Now type:

sudo reboot

and disconnect the ethernet cable from the Raspberry PI. When it comes up again, the blue light on the wireless adaptor should turn on and you should now be able to login to your PI over wireless.

Beware, once you reboot, the Raspberry PI may connect with a different IP address. In that case you need to go to your router’s admin panel and find out what the new address is. You can avoid this by reading this.

That completes the setup of the Raspberry PI. The only thing left is to plug in the Open Sprinkler board, mount the whole thing in the case and take it to the location where you’ll be hooking it up.

Hooking It All Up

If you have an existing sprinkler controller like I did, you just need to disconnect the wires from the old and connect to the green screw terminal connectors that came with the Open Sprinkler. Remember which channel goes to which to make setup later easier. The small connector is for the grounds and the big one is for each channel.


Channels (right) and grounds (left). You can easily put two or three wires in each ground hole.


You need a 24 VAC transformer as well. Typically this is what is running your current sprinkler controller. So you just disconnect it from that and connect it to the 2 pin orange screw terminal. This is AC, so it doesn’t matter which wire go to which terminal. Just make sure not to cause any short circuits.


Power connector. Even though the wires are different colors, they can go in either hole.


Now  plug in the green and orange connectors and you should see the lights inside case light up. Now you should be able to login just like you did when you were setting up the Raspberry PI.


My OSPI, happily running my sprinklers for weeks now

Web and Mobile Access

The Open Sprinkler software comes configured with a web server. Once up and running you can open your web browser and go to:

http://<your ip address>:8080

And you should see the web interface for the OSPI. There is also a mobile app for iPhone (and Android, although i didn’t test it). The documentation  tells you everything you need to know about how to set these up.

My one complaint about the software is the way you need to setup programs. Every sprinkler controller I’ve ever seen lets you set the start time and duration. You can often set multiple start times if you need to water multiple times a day for example. But it’s always been time/duration. In both the web interface and mobile app  you have to set start time, end time, a repeat time and duration. This allows you to  have the program repeat multiple times a day. That’s a nice feature, but you have to be careful about setting the program up to just have a single start time and duration. So make sure you set the end to longer than the duration x the number of channels you have. And set the repeat time to a large value so it doesn’t repeat. But one of the great things about OSPI is that it has a very active forum. I posted this issue and got a quick response that Ray was working on an update to make it simpler.

All in all, I could not be happier with the system! Thanks Ray’s Hobby.





I’ve been planning on building an ethernet connected clock for some time now. It started as a project for my daughter, Mikayla. But my wife went out and bought both her and my other daughter Leah little LED alarm clocks for $10 at Walgreen’s which took away my ability to make her a $50 clock 🙂

Not to worry. We always need more clocks. So I repurposed Etherclock for the family room. We had a Squeezebox serving the purpose of a really accurate clock in that room. But I felt bad to be putting it to such a meager use and my friend Jon wanted a second one, so I sold it to him and started on Etherclock.

The Hardware

First I chose the Tuxgraphics ethernet board. This is a nice, small board that has a mega168 and an ENC28J60 for ethernet. The ethernet chip runs at 25MHz and can output a clock signal which is 1/2 that, which drives the mega168 at 12.5MHz. That’s slower than it’s maximum rate of 16MHz, but it was plenty fast enough for this project. And it was an easy matter to get a precise 1sec time reference using the 16 bit timer/counter of the AVR. Plus it has a nice little prototyping area on one side, and an LED for some early stage debugging.

The Tuxgraphics ethernet board

I wanted the clock to have nice big digits, so I decided on 0.8″ red 7 segment LEDs (LSD8161). I wanted them to be bright enough and have nice even brightness, so I opted for a shift register with constant current outputs. The MAX6969 is a great part for this. It has 16 outputs, so I only needed 2 parts to drive 4 digits, and I didn’t have to worry about multiplexing. I just needed 4 pins: data, clock, enable and latch.

Testing the MAX6969 LED driver

I set the current on the MAX6969 to maximum and used the enable signal to adjust the brightness. I breadboarded one digit to test the serial interface and brightness control. It was convenient to use my STK500 board for the testing phase, using the same mega168 at the same frequency as the final project. I also used this setup to test the IS474 light detector, used to automatic brightness adjustment. The IS474 outputs an analog signal from 0 to 5v, which I brought into the ADC0 pin of the Mega168. The incoming light level determines the percentage of time the LEDs are on, so they’re brighter in a bright room, and get dim when the room light decreases.

The Software

I knew I wanted to try writing code for Etherclock in C++, partly because I have used it for many years at work and partly because I read so many AVR articles claiming it was a bad idea 🙂 So I started writing Marrinator, a C++ library to interface with all the internal and external hardware used in the project. For a while I even toyed with writing my own toolchain, but things have gotten better since then and I abandoned that project. I made up my own Makefile and was running everything from the command line for a while. But I finally settled on using Xcode for development. It is perfectly capable of using an external Makefile and toolchain for building and made it much easier to find and fix compile errors.

Just for fun I played around with the Arduino development system a bit. It’s not hard to get Arduino to work with non-standard boards. But I found that the libraries and development system didn’t really give me much from my roll-your-own approach, so I went back to Xcode.

Getting firmware to the board

When I started the project I was using an STK500 both for hardware prototyping an downloading the firmware to the chip. When it came time to move to the real hardware I had a problem. The STK500 is perfectly capable of programming external hardware, using the standard 6 pin ICSP connector. But the Tuxgraphics board has a 5 pin inline connector instead. So I built what I called The Abomination to interface the two.

The Abomination

Now, on the face of it, it’s not so bad. It’s just a 6 pin IDC to 5 pin inline adaptor, embedded in epoxy. And this worked fine with the STK500. But later on I bought a Dragon, thinking I would be able to use DebugWire for some hardware debugging. That hasn’t happened (yet), but I also started using the Dragon to program the Tuxgraphics board. Of course, that didn’t work. Just look at The Abomination. 6 pin IDC to 5 pin inline. Where’s the missing pin? Turns out it carries VCC, and the Tuxgraphics board has no connection for it. That was fine with the STK500, but the Dragon wants to see VCC to know what voltage it should be programming at. No VCC, no programming.

So I simply added a 6 pin IDC connector to the prototyping area of the Tuxgraphics board, brought in the 5 ICSP pins, added in VCC and was in business.

Tuxgraphics board with the newly added 6 pin ICSP connector. Also notice the connectors for the display board and the button

Note to board designers. If you don’t have a compact board (like the LilyPad or FIO) please add a standard ICSP connector 🙂

Display Board

I put the 2 MAX6969 chips, the IS474 light detector and the 7 segment LEDs on a separate display board, mounted at a right angle to the main board. This made for a nice compact design which didn’t need any additional mounting for the display.

The finished display board. The Magic Mouse is NOT part of the design 🙂

The parts were mounted on a piece of perfboard, which meant soldering. Lots of soldering.

The rat’s nest that is the back of the display board

I used to really like soldering. But display boards like this are an entirely different experience. It consists of around 50 wires, or 100 connections. Shockingly, it worked perfectly the first time I wired it up, which is clearly a tribute to steady hand and high quality tools – or the beer.

Finishing the hardware

The only other parts and connections were a button on top of the case and the power connection at the rear. I didn’t use a polarized connector for power, but I will always try to do that in the future. I haven’t fried anything (yet), but I worry every time I connect power.

The power jack with its scary unpolarized connector
The button mounted in the top. Always use a connector for something like this, so you can disassemble it easily.

The back panel has cutouts for power and the ethernet connector. For ethernet I drilled a round hole and then used the dremel and a file to square it the best I could. The cable fits fine, so I didn’t worry about the look too much.

The case is a Context Engineering split body aluminum box. This is basically 2 pieces of extruded aluminum that fit together, so you can cut them to any length. I cut it to the perfect size with a band saw, which was easy once I had the right blade! But you might notice in the picture above that the cut is a little ragged. Next time I’ll add a fence using a piece of wood and a couple of clamps. I did this for the plexiglass front and it came out perfect.

The perfectly cut plexiglass front

Once the hardware was done, I just had to write all the software, which I’ll discuss in a separate article.

Etherclock in its new home, next to the Apple TV