My new Wood LED Clock - Sparkfun Clockit Retrofit

I always enjoy a good project; a chance for me to make something new and work with something new in the process. These days I have several longer-term projects in-progress, so once in a while I enjoy working on something smaller that I can finish in a short time. This time it's my new wood LED clock project.

The Inspiration

First off, this is not a new idea by any means. I've seen these kinds of clocks around before, but hadn't considered making one until now. Recently I came across a website and youtube channel called "I Like To Make Stuff". Besides the fact that this statement perfectly describes me, I can also identify with the host/creator Bob Clagett. He's a father, software developer, and creative DIY'er like myself. Not long ago he posted a video on How to make a wooden digital clock that walks through the process.

The main driver for me was that I already has the most important part... a barebones clock. A few years ago I bought the ClockIt kit from Sparkfun when I was first getting into microcontrollers. I soldered it up, and then it sat on my workbench, mostly unused and ignored ever since. So I figured, why not retrofit this into a wood clock and put it up on my desk at work?

Reworking The Clock

The clock itself had a few issues that would make it difficult to place behind a sheet of veneer. There were a number of components on the circuit board that were too tall to make it work. I was able to remove a couple items completely. I wasn't planning on using the alarm feature, so I removed the buzzer and the alarm on/off switch. Both were easily de-soldered. I just replaced the switch with a wire jumper to simulate the alarm being in the off position. I could have bypassed this in code too, but this was simple enough.

There were also some buttons, a capacitor, and some programming headers on the front of the board that were a bit too tall. I was able to move the buttons and capacitor to the back of the board without much issue. I didn't get the buttons pushed back through the holes all the way, so they're a little ugly, but for my purposes it was fine. I decided to keep the programming headers, but just clip them shorter. In the end, my LED display was the tallest item on the front, and everything left on that side was short enough that I could fit a 1/8" board over them.

Ready for rework

Reprogramming

I won't get into too much detail here, but I also tweaked the programming on the clock a bit. I dug out my AVR programmer, downloaded the source code from Sparkfun's website, made some changes, and used WinAVR to reprogram the clock. The main thing I did was disable the am/pm indicator "dot" on the clock, purely for aesthetic reasons. I also increased the brightness a bit since it would be behind a sheet of veneer. Their code is fairly straightforward, so making these changes didn't take much effort.

UPDATE 10/6/2014 - I've reworked the code a bit more and made my version available at GitHub: https://github.com/benbrandt22/TimeBox

Building the Box

The front face was the most complicated part of the build, but wasn't too bad. I measured up the clock and used CAD to draw up some cutouts that I could use that would hold the clock kit. I printed those templates to paper, transferred them to my 1/8" boards, and cut them out with a jigsaw. I also ended up cutting a couple sheets of veneer to give me the height that I wanted (see photos below):

Paper templates & wood cutouts. Since it is a 12-hour clock, not all the display elements will be lit, so it's shifted slightly to the left so the time will appear centered.

Checking the height of my "faceplate"

The rest of the box was cut out of various sheets of plywood and MDF, and glued together with wood glue:

Once dried, I trimmed down all 4 sides on the table saw to make each side smooth:

Applying the Veneer & Finishing

At this point it wasn't much of a show piece (yet), just a bunch of plywood glued together. I hadn't worked with veneer before, so this was a fun new (and relatively easy) experience. I picked up a pack of maple veneer from the local woodworking store, and a small bottle of contact cement from Home Depot.

Each sheet of veneer was glued on with the contact cement. After drying, I used a power sander to knock down the edges to make them flush with the sides of the box. Once I had all the veneer applied, I gave the whole thing a couple coats of polyurethane for a nice finish. The polyurethane caused one minor issue I hadn't expected; it caused the veneer to warp slightly. This wasn't a problem where it was glued down, but the small rectangular area for the display ended up slightly indented. Eventually it flattened out a little bit, so it's not too noticeable anymore, but it's still not nice and flat like I was going for. Regardless, I think it turned out pretty nice.

I left the bottom open, so I can set the time, and remove the clock kit if necessary. I figure it's fun for people to be able to see what's inside to see how it was done, and knowing me, I'll probably want to make future changes, so it's nice having it accessible. I may add a removable base in the future, but for now I like the simplicity of the box in its current form.

Sanding down the edge of a veneer sheet

Applying contact cement

I masked off the area where the display would be, to avoid getting contact cement on it.

Adding polyurethane

The view from the bottom. Mounted in the back is a panel-mount power jack that runs to the clock inside.

The finished product.

The Color Jar - Microcontroller-driven fun for the kids

I finally managed to spend some time on a new electronics project at my workbench. Major credit for the idea goes to Paul, author of the Fangletronics blog. He is also a father and electronics tinkerer, so his blog certainly appealed to me. One post in particular (Pixie-Dust Bottles) stood out as a fun and relatively simple potential project, a good programming exercise, and something I thought my boys would enjoy. Shown at left is the final product, what I've been calling the Color Jar. It's a frosted plastic jar with a knob on top. As you turn the knob, the RGB LED light turns on inside the jar, and it smoothly cycles through all the colors of the rainbow, based on the position of the knob, essentially letting you "dial-in" a color.

The original design was built around an ATTiny13 microcontroller, but it ported over very easily to the ATTiny85 chip which I had on hand, as it has the same pinout but with more memory. I worked out the circuit on a breadboard, and then soldered it up on some proto board, and mounted it to the potentiometer to make it into a nice compact package. I made sure to use a chip socket for easy removal for reprogramming, which came in handy. The other major design change was the battery. Since my plastic jar allowed some more space in the lid, I decided to use a larger 3 volt CR2 "Photo" battery (not a small watch battery) that should last longer.

For the most part, I used the programming from the original pixie dust bottle project, but had to make a couple updates & fixes for my project.

First was a hardware issue. I bought my potentiometer (with switch) from Radioshack, which was convenient, but turns out it was not linear. That is, the voltage change was not directly proportional to the amount of rotation. In practice, this meant that for the first half of the knob's rotation there was almost no voltage change, so for most of the rotation the light would only show red. I took a series of voltage measurements at different degrees of rotation, and used Excel to graph out the signal curve. From there I was able to come up with a formula to take my input signal and adjust it to a more linear value. This allowed me to more evenly spread each color over the full rotation of the knob. The extra-low voltages at the bottom of the range also made it difficult to get consistent readings, which made my light flicker a little. I was able to smooth this out by taking 10 input readings per cycle with a 2 millisecond delay between each and averaging them to get my final input value.

The other issue was a programming bug in the code I was using. At a certain point between green and cyan, the LED would start flashing/flickering red. Looking at the code I had a hunch it was a math error in the way the RGB color was being calculated. To be sure, I did the math and found out it was calculating a Red value of -2, when normally this should be between 0 and 255. It might be fun to refactor the code and come up with my own algorithm for calculating the colors, but for now I just left the main logic in place, and then added a few lines to force any values below zero back to zero, and anything over 255 set back to 255, to keep everything in the appropriate range. This got rid of the flickering, and overall I'm happy with the performance of the Color Jar.

While Nathan may not appreciate the electronics and programming running inside it, he definitely enjoys the Color Jar, and that's the biggest payoff for me :-)

Fabrication brings TinyChuck5 to life

After some time spent re-acquainting myself with circuit board manufacturing and laser cutting, my "TinyChuck5" project is complete, looking more like a finished product than a breadboarded mess of wires. Here it is, happily blinking away:



At the time of my last post, I had finished my circuit board design and had some boards on order. The circuit boards were manufactured overseas through the Seeedstudio Fusion PCB service, great for small prototyping runs of small boards. Thankfully my design just barely fit within the 5cm x 5cm maximum size. To get 10 boards for only $20 is a steal, much cheaper than just one board through most other services. They also have a 10cm x 10cm option for $40. Despite the low price, the boards turned out quite well, the only drawback being the long lead time. They also added some identification/serial numbers to the silkscreen on each board to keep track of the order, but that's hardly anything to be concerned over. I also ended up with some additional boards, 12 in all, with 8 of them tested (they promise at least 50% testing, 100% costs extra). All in all a perfect service for the hobbyist engineer.

With boards in hand, I headed for the workbench to assemble my first prototype. After much soldering and clipping of leads, it was time for the ultimate test... would it work? Was my circuit board designed correctly? With the programmed chip pressed into its socket I hooked up power through a couple alligator clips and viola! It worked! Blinking lights! Not terribly exciting I know, but it was personal validation for the work and attention to detail I had put into my little trinket.

Next step was to give this little piece of electronics a proper enclosure. I wanted to have it set up on my desk and look nice & clean. While the exposed electronics look was interesting in its own right, I wanted to take it up a notch.

Years ago, I was fortunate enough to have access to a laser cutter/engraver in my high school's metal shop, and I was appointed to be the resident expert and operator of the machine. I learned a lot that year and had fun cutting and engraving all sorts of parts and materials. Having access to that kind of creativity-driven hardware was a lot of fun. So when it came time to make an enclosure for this project, I wanted to laser cut something. Thanks to their partnership with SparkFun Electronics, I found out about a company called Ponoko, an internet-based "digital manufacturing" service that creates parts from digital files. 2-dimensional designs can be cut from a variety of materials, and 3D designs can be turned into physical parts using 3D printing technologies. They make it easy and affordable. In college I also got to use the rapid prototyping machine to "print" 3D objects, but that's a different story. Needless to say I love the whole digital fabrication concept, and the creative freedom it enables.

For laser cut parts, I simply had to upload my design as an SVG file, and choose the material I wanted. I opted to do my design work in AutoCAD where I feel most comfortable, having made mechanical drawings in the software for four years at college. I saved my design to an AutoCAD R13 DXF format, imported it into Inkscape, placed it within Ponoko's design template, and sent the design off to Ponoko to be cut from 3mm thick white acrylic plastic. Some time later the parts arrived at my door, and it was back to the workbench.



One thing I noticed after assembling my first unit was that my LEDs didn't all line up perfectly in their 4 x 5 grid. The holes in the PCB were bigger than the LED leads, so each LED had some wiggle room. This resulted in a few LEDs that looked "off" from the rest of their respective rows. I had some space available on my Ponoko design, so I had them cut me a template for placing my LEDs. I cut holes for each LED just big enough to fit the lens, and included mounting holes that lined up with the circuit board. This let me place all 20 LEDs in a near-perfect grid and hold them solid while I soldered each one. The results look much better than my first attempt, with perfectly aligned rows & columns of lights.

With soldering complete, I began assembling the new enclosure:



Here's a view of the back of the unit. The back piece included cutouts for my power cord (a USB cable), and for a small T-shaped button I made for pressing the reset button inside on the circuit board.



And here again is the finished product. These days it sits on my desk at work, quietly blinking away, occasionally drawing me into a hypnotic zen-state, and serving as inspiration for my next more ambitious project.

Diving into Microcontrollers - My Tiny Charlieplexed Display

Welcome! Thank you HackADay for publishing my project, and thanks for coming and reading :-)

For those of you who are used to reading about my usual exploits in cooking, fixing things, and family, be forewarned this post gets a bit long, technical, and geeky! :-)

I've been interested in electronics since I was a kid, and have always enjoyed experimenting, building, and learning something new along the way. With the growing popularity of microcontrollers in the hobbyist community, it's become easier to get started in what used to seem too complicated to approach in my spare time.

Since microcontrollers are essentially tiny computers in a chip, you can do much more than you would be able to do with a handful of passive electrical components, and making changes to your device usually only requires making changes to the software that runs on the chip. While I can write software on the computer to work with data, there's something more satisfying about being able to write software to control objects in the physical world like sensors, motors, lights, etc.

I've actually been picking away at this project for several months, in the limited time I have available to me as a parent of a 1-year-old. I'm intrigued by how much can be accomplished by some of the tiny chips available. I decided to start learning with something small, the ATTiny85, with a mere 8 pins to work with. I was also intrigued by what I had read about Charlieplexing LEDs. Basically controlling many LEDs with only a few pins. For simplicity, I wanted to avoid any extra hardware/chips for my first project. To see how much I could do with only a few pins, I decided to take the 5 output pins available to me and make a charlieplexed LED display. Technically I could have used 6 pins, but that would mean losing my ability to reprogram the chip easily. By wiring up my LEDs just right, I could control up to 20 LEDs with only 5 pins.

So I have a tiny chip driving 20 LED lights, but I have no source of input since I used up all my pins. I might as well try doing something interesting... random blinking isn't very intellectually stimulating. I decided I would make a small 4 by 5 grid which could run Conways Game of Life, a simple simulation of cellular life invented by a mathematician in 1970, and a simple programming exercise for me to learn to program my microcontroller in C. By turning on a set of random LEDs, you can let the "colony" evolve based on a set of rules, and see how long it lasts. Sometimes the colonies die off quickly, sometimes the right configuration will get into a loop and survive forever. It's a bit abstract, but interesting to watch.

Setting up the wiring was a bit tricky. I wanted 20 LEDs in a 4x5 grid, all aligned the same direction on the board, and had to run 5 wires to the 40 different connection points. I ended up running bus-lines for each wire on the top and bottom of the board. One side of the board would run to the positive side of each LED, and the other side to the negative leads. After some sketching I ended up with my basic concept for wiring the array and it ended up conceptually simpler than I had expected.

Next step was prototyping. I did some simple experiments with 2 or 3 pins and a breadboard to prove out the charlieplexing concept. Only one LED can be lit at a time. To do this, you have to set one side of the LED high on an output, set the other side to ground on an output, and set all other pins on the array to an input mode. Setting the others to inputs prevents current from flowing and thus keeps all the other LEDs dark. This was perhaps one of the more complicated prototypes I've built, since it involved so many jumper wires on the topside of the board, and such complex wiring in a tight space. I could handle it for 20 LEDs, but probably wouldn't have the patience for much more.

Programming was a new challenge in itself. I've written software in a variety of languages and knew enough to start playing around with some low-level C language with the help of other people's sample code. Getting the programming on the chip required some extra hardware. Awhile back I picked up the USBTinyISP AVR Programmer from Adafruit. The kit was easy to build and in the end I had a top-notch programmer for getting software into my chips. I downloaded the WinAVR development environment and got familiar with it, and after much reviewing of datasheets and other people's software posted online, I started to get simple programs running on my ATTiny85. One big drawback was in-system programming. The AVR chips allow you to program the chip while it's plugged into the rest of your circuit. However, due to the wiring of my board, where basically every output pin is connected to every other with little in between... this interfered with the programming data. I could only get programming to work if I pulled the chip and put it in my dedicated programmer. Not a major issue, but a bit of a nuisance. This also meant I wouldn't be able to include a programming header on my final board design.

I actually started developing my Game of Life software while on vacation in northern Minnesota. I had the WinAVR software working on my laptop, had my prototype hardware built and working, and with this vacation I had plenty of pockets of free time where I wasn't responsible for doing anything in particular. I developed some routines for lighting specific LEDs, storing the current grid, calculating the next generation, and did a little "software PWM" to make it look like the LEDs were fading in and out. I'm sure there are dozens of ways my code could be improved/optimized, but as a first project I'm pretty proud of what came out of it.

As I am always learning, and willing to learn from others, I've posted my code & schematic as an open-source project on GitHub:
https://github.com/benbrandt22/TinyLife5
I just installed Git and just signed up for GitHub, so hopefully I did it right! But my files are there, so that's a good sign.

Detecting when to reset the simulation was an interesting programming exercise as well. The simple ways didn't take much effort. If the next generation has all lights out (dead), then reset. If the next generation matches the current one (steady state) then reset. Detecting a loop was a bit more complex. I didn't want my device to get into a loop and stay there until the power was reset. I didn't have the memory to store an endless record of previous grids to compare to. So, at a certain interval, I saved the grid, and subsequent generations would be compared to that past one. Once the software detected that it's next grid matched one we had seen before, it would know a loop had occurred, and would reset. But how often should I record the grid? How many generations back should I look? I wanted to know how long of a loop I could expect. Since I was only dealing with 20 LEDs, my grid could only display 1,048,575 (2^20) possible combinations of lights, relatively small for a computer to deal with. I wrote some software in VB.NET to run through every possible combination and see how each would play out in the Game of Life simulation. What I found was that about 8.13% of the possible combinations would loop in one way or another, and the longest loop I could expect was 18 generations. Based on this, I knew that if I looked at every 20th generation, I should be guaranteed to catch every possible loop eventually. If my grid were larger I'm sure it would get much harder to analyze every possible configuration, but this worked well for my small setup.

Here's how it looks running on the breadboard:



Now I could have stopped here, but there was more to learn, and after all, I like to make things. I wanted to turn this into a little trinket I could have running on my desk that looked nice & clean. It was time to tighten up the design and put it on a circuit board. Moving my project off the breadboard into a finished product is the perfect way to wrap it up. I haven't done any circuit board designing in about 7 or 8 years since I created my VU-Meter Kit back in 2003. I designed that in ExpressPCB, a proprietary software package, so this was the perfect excuse to teach myself Eagle CAD, with some help from the excellent tutorials at Sparkfun. Once I got rolling, Eagle turned out to be a nice piece of software, and was easy enough to use. Bringing my schematic to a board design was a smooth intuitive process. I arranged my LEDs into a tighter grid, and added some extra circuitry to regulate a 9v power supply to an even 5 volts, and added a reset button. The whole thing fit into a board just 1.95 inches square. Since my board was a charlieplexed LED display running off 5 pins of an ATTiny, I named the board design "TinyChuck5". In the future I can modify my software to do other things besides the Game of Life simulation.

Before committing my design to a board, I ran through some checks to make sure it would work, besides double-checking my traces in Eagle. I printed out my design on paper and taped to a piece of styrofoam, and proceeded to insert the components. This allowed me to make sure everything would physically fit, and that everything lined up properly. I then generated my gerber files for having the board manufactured. As a last check, I viewed the gerber files with ViewPlot, and discovered that my voltage regulator included a drill-hole that I wasn't aware of, which put a hole right through one of my traces. I didn't see this in Eagle, so was thankful I could catch it by reviewing the gerber files. I moved my trace to avoid this hole and the design was finished!

At the time of this writing I have a few boards on order. Once they arrive I can solder some together and make it look nice. I'd like to put my LEDs behind some semi-transparent white plastic. In the end I may have a useless blinking gadget, but at least I can say I created it from scratch, and I have the ability to make it do whatever I want. With the knowledge I've gained in this experience, I can move on to another more elaborate, more interesting project.