Archive for March, 2012

Things were wrapping up on the radio clock just as we were heading into the holiday season back in 2010, and my wife bought me a bunch of nice little projects – this little scrolling message board from Hansen Hobbies was in my stocking:

This took all of about 15 minutes to put together, but it’s cute and it works well.  In hindsight, the $40 pricetag is a little large, and for what it is (a small toy), I think they’re just a tad overprotective of their source code (i.e. they explicitly say on their website that they won’t give it out.) Oh well.  Anyway, as soon as I had it working I realized two things:  One, I wanted COLOR! And two, gosh, it’d make a nice clock… so now I had my next project in mind.

The basic architecture was pretty easy to understand, you just need to daisy-chain a bunch of 74xx595 shift registers together and each bit lights up a single pixel, and then you scan through the rows rapidly enough (i.e. 60hz or greater per frame, or > 480 lines per second) to create the whole character using persistence of vision, just like an old CRT TV.  The first trick was finding RGB color 8×8 matrixes like Hansen’s little red ones, though.  The standard sources (Digikey, Mouser, etc.) simply do not have any of these, primarily because it appears that there aren’t any Large Reputable Electronics Manufacturers building these.  Well, maybe Lumex is, but the distributors don’t stock them, and they also don’t sell them onesy-twosy.  However, there are Chinese companies churning these out like there’s no tomorrow.  I did find some available at Sparkfun, and I also later discovered you can buy them from the nice folks at EvilMadScientist too.  (I still want an Eggbot.)  They’re kinda pricey, though – Sparkfun’s go for around $30 each, if I remember correctly, and I wanted to daisy chain at least three of them together to have enough real estate to be able to read a message.  I didn’t really have much choice, though, other than to abandon the project altogether.

I started really simple and bought a single tri-color LED at Radio Shack.  This let me experiment with writing some PWM (“pulse width modulation) code to fade the colors on a single LED.  For the non-engineers: PWM just blinks the light on and off at varying durations, but at very high speed, so that it appears to be different brightnesses as desired, but not flickery to the human eye.  It was very pretty, I still want to go back and build a little mood lamp out of it. Having knocked that together quickly, my idea was that I would design my own printed circuit board for the first time and I’d design it with connectors so that you could chain an arbitrary number of them together and build it up to be as big as you want.  3 seemed like a good place to start.

It seemed natural to use another Propeller as the microcontroller, since I’d just invested a whole bunch of time learning how to use it, so I attached another RTC chip to drive the clock to a Propeller and then it was time to design the basic circuit. Here’s a pic of the breadboard:  It was quite a tangle, because a single 8×8 RGB display has 32 pins, 8 transistors to sink a row of LED current through, each with a base current limiting resistor, and 24 resistors to limit the current to each column, and 4 shift register chips.

The messy breadboard

It did the job though – it was invaluable to get some software running, lighting up different dots and colors, and scanning through the rows.

Confident that the circuit was working well, it was time to develop a New Big Skill that I had no experience with, namely, PCB design. I spent about 10 minutes looking at Eagle’s UI and just about retched up a lung.  I mean, seriously, it’s not 1995 any more. With this many years of graphical app design in the world, you’d think they would have done a major overhaul by now just for usability’s sake. In researching the alternatives, I found Diptrace and I haven’t looked back since.  You can download a 300-pin 2-layer version as freeware, and they will provide you with a 500-pin update for non-profit use for free, just by asking.  The Diptrace UI follows standard Windows conventions fairly well, the tutorial was good enough to get me off the ground, and the product is of reasonably high quality. I haven’t found any obvious bugs. The word on the street is that their “shape” autorouter, which figures out how to route the wires on the board without overlapping other ones, blows Eagle’s out of the water.  My experience to date is that the router does an excellent job, although it does suffer a little bit from poorly documented parameters.  You can usually improve a bit on the routing it comes up with after the fact, but I’ve seen it solve some pretty tough situations, and it makes for a good starting position for minor manual tweaks.

Here’s the final revision I designed around the Sparkfun LED module:

OK, it took me about 3 or 4 iterations to get there (and a lot of roundtrips with Sparkfun’s BatchPCB service.), so it was costing me a fair bundle to get “final” boards, but by gum, I was learning! It’s educational, right? 🙂 The revisions allowed me to include a few things I’d forgotten like room for mounting holes, and also to make a reversal of which side was input vs. output on the ribbon cable connectors.

A shoutout to BatchPCB here, by the way: Most printed circuit board companies, of which there are many, are built around a business model where volume discounts can be extremely steep but low volume orders are expensive.  There’s a lot of setup and prep involved with making the first board of any particular design, so it’s hard to drive down those manufacturing costs.  Where BatchPCB comes in is to aggregate lots of hobbyist single-order boards onto one larger panel, and to work with a Chinese company to get the boards produced at lower cost.  The turnaround time is long (typically around 3 weeks from order to receipt of the goods) but the cost savings is worth it.  Furthermore, you virtually always get at least one more board than you actually paid for in “overage”, which is a real bonus.

There is an alternative in Oregon that I like too (Sunstone Circuits) who also has a reasonably cheap 2-layer prototyping service with 2-week turnaround (and usually even less, in my experience).  They’ll only silkscreen one side of the board compared to both sides for BatchPCB, but on the positive side, Sunstone’s minimum trace/separations for 2-layer boards are slightly smaller at .007″ vs. .008″, and they can do smaller vias as well (.016″ vs .020″).  Also, from up here in Seattle even ground shipping amounts to overnight service, so even though the price is a bit more, sometimes it’s worth it to keep from getting stalled on a project.

Routing the traces for this board as my very first PCB project was a little tricky because of a few conflicting constraints:

  1. The board needed to be the width of the LED module so you could put them next to each other and get a seamless transition from one module to the next in line.
  2. The LED chews up a pile of board area, and I wasn’t comfortable yet with surface mount parts, so everything had to be through-hole.  This meant mounting shift registers and DIP resistor packs on the back of the module under the LED to make use of all that board space.  Once the LED is soldered on, you won’t be able to make any changes to the parts soldered underneath it.  (On assembly, I realized this also meant screwing down the board standoffs (good and tight!) before soldering on the LED as well.
  3. Traces were getting a little bit tight side by side, particularly since I wanted to be a bit conservative for traces carrying a lot of current back to ground.

It did all fit in the end, though, and I was pretty pumped when my first boards of my first design worked great, right out of the gate.  That was a really fun day. 🙂 Some others that I’ve made since then have not been so lucky – it’s a real drag when you think you’ve triple checked the layout and the schematic and you STILL find some error that’s a pain to fix when they come back in the mail.

Next time I’ll throw in some pictures of the final result and talk some more about the software that drives this RGB panel, because that’s a whole saga of its own.




Well, this is what it looked like at the end, but it took a while getting there.  From the hardware perspective, this was a good first project after the long dead spell.  I settled on the Parallax Propeller as the heart of the thing rather than the more common Arduino.  Why?  Good question.  I think I was lured in by the Propeller’s interrupt-free programming model, 8 parallel processors, and ready-to-go prototyping boards. I had also poked around their OBEX site of contributed objects for interfacing with common peripherals and liked the one-stop shopping.

It was a snap to hook up the WWVB receiver breakout board from Sparkfun, it’s just power/ground and a signal output line.  Hooking up the serial LCD (also from Parallax) was equally simple to do.  Later in the project I also added a battery-backed RTC from Maxim, which was a little more complicated to figure out since it was an I2C based chip and so I needed to learn about that protocol in some depth in order to get that working.  The weird gymnastics of using the “illegal” states of the data/clock lines to signal the beginning and end of a transfer, and the use of one bit of the address to signal a read vs. write, were not entirely intuitive at first, seeing as how I was a little rusty in this department at the time.  The cable and extra box leading out of the enclosure is simply an extension to house the little ferrite bar antenna, because when I tried using it within the main casing, it was noisy enough in there to pretty much spoil any reception.  Getting it 5 or 6 inches away seems to be enough to get back to good reception most of the time, sometimes even in daylight hours.

The real complexity of this project turned out to be the WWVB signal itself.  The wikipedia entry was my bible, because decoding the signal is just bizarre.  First, you wait for the dark hours of the evening, because daylight tends to drown the signal (coming in at verrry low signal strength from Colorado).  Then, you time the pulses come out of the receiver chip.  A 200ms pulse (yes, milliseconds – an eternity…) is a zero, a 500ms pulse is a one, and an 800ms pulse is a “mark” that is supposed to show up at regular intervals to help you figure out where the top of the minute starts.

It takes an entire minute to receive one complete frame of data, so the debugging process can take rather a long time when you’re working with the live data.  Also, those pulse lengths vary within a pretty wide threshold because the pulses are determined from amplitude modulation of just 17dB (which is not a huge amount), so virtually any noise in reception causes a short pulse or a pulse where there shouldn’t be one at all.  Turning on a fluorescent lamp (of which there are now many) can ruin the signal completely.  There are a lot of techniques for working around the noise, such as averaging consecutive frames over a period of several minutes and trying to figure out where the errors occurred, but after a lot of trial and error, in the end I went for the simple version and I simply throw out any frames where any obviously invalid bits were received, or expected bits were missed.  This seems to work OK in practice.

For a while I used serial-printf() style debugging to tell me how frequently the pulses were coming in, how long they were, and so on.  This was enough to figure out when the signal was really poor and when it was doing well and so on, but somewhere about midway through this project I splurged on a LeCroy WaveAce 102 (a 60Mhz digital oscilloscope) and being able to actually see the pulses and any noise on the signal onscreen made life much, much easier. (The scope purchase will make a good post in itself, I think.)  As a simple signal quality monitor, I programmed a few of the custom characters on the serial LCD to give me a simple 0-3 “bars” meter like a cellphone, and when the clock is locked on and actively receiving a good frame it shows a little “antenna” icon with a little wave overhead.  This way I can at least see what’s going on in a rough sense without hooking up test equipment.  To calculate how many bars to show I just keep a running average of how many good pulses were received in the last 30 seconds and how many were thrown out as invalid due to being too far off “center” (as calculated from the last “top of minute” signal we received, which is two marks in a row) or pulses which were of some obviously invalid duration.  This technique works pretty well too in practice.

There also turned out to be a lot more complexity than I really expected there to be just in the act of keeping time. Since the time is formatted for Greenwhich Mean Time (really, UTC), you need to translate it for local time, which can of course mean rollovers (or rollbacks) in the date as well, all depending on what timezone you’re in and whether DST is in effect or not. Handling daylight savings time shifts also turns out to require a little thought – when the clocks go back in the fall, you need to make sure you don’t fall back again when you get to 2am the second time that night.  Ask me how I know.  Then there’s trying to set the onboard RTC chip with some level of fidelity over I2C, once the Propeller thinks it knows for sure exactly what time it is.

Well, making all that work while learning how to make best use of the Propeller’s parallel programming turned into a couple months of nights spent banging away at the project, but I was reasonably happy with the outcome and I scraped off an awful lot of rust from my brain in the process.  Another clock for the collection.

Next time: RGB LEDs Gone Wild.


The first thing I decided to build, to get me out of the long dark hibernation that was(n’t) my electronics career, was a clock.  There’s no particular reason for that, other than that the logic would be fairly simple (just wait to see how wrong I was), and that I had started to amass a sort of ad-hoc self-proclaimed “Geeky Clock Collection.”  It started with the Nixie clock I mentioned in the last post, which was added to with a few choice selections from the ThinkGeek catalog, and which slowly and organically started to grow into a rather voluminous pile of boxes sitting on my office windowsill:  Check these out (as it stands today):

The Geeky Clock Collection

These are, from the left, the EvilMadScientist BulbDial, a genuine 1970’s Arrow Ball clock, the NixieNeon kit from Nuts&Volts magazine, the Nixie Clock from that started this whole mess, the Adafruit Icetube and Monochron, a TIX, a Thinkgeek Epoch clock, the Analace Binary clock, a Thinkgeek Matrix Cube clock, and lastly a few I’ll post on later: Two CRT clocks I built from the ground up (one a direct copy of the design at, and the other uses the Sparkfun O-Clock, or “Dutchtronix,” oscilloscope clock circuit, to drive an analog stage taken from Jon Stanley’s design here, with some power supply modifications of my own.)  Sitting on top of those CRT clocks is an RGB scrolling text matrix entirely of my own design, which will also be the subject of a future post.

Given this growing pile of vibrating crystal, it wasn’t much of a stretch for me to try my hand at building one of my own.  The thing that ultimately pushed me into action was a New Product post from Sparkfun for a cheapo WWVB radio module.  These are what they put in those weather stations that claim to be “Atomic Clocks” that set themselves automatically from a radio signal. “Aha!” I thought.  “I’ll wire one of these up, and I’ll have my own super-accurate clock reference!” Yeah, well, it wasn’t quite that easy…

Hello World!

Welcome dear reader!

A little background:  What I originally planned to do when I was in college as a computer science major was of course to be a computer programmer.  A couple things conspired against me, though:

  • The primitive state of debugging tools in 1991 led me to the conclusion that I would kill myself after my first year on the job if I was a programmer for a living, having just endured 4 years of semi-pointless academic programming exercises, and:
  • I discovered rather late in college that I really, really loved the digital logic and hardware side of things more than the software.  But nobody wants to hire you to build stuff in the physical domain if your degree is in computer science, rather than electrical engineering (and well they shouldn’t).  I did have a lot of fun, though: All of my independent study/senior project time was spent building MIDI data transformers for my drum machine, and a cheap-to-build DMX512 theatre lighting controller that anybody could stick in a PC of the era, with its own onboard NEC V20 processor (x86 clone with better multiply/divide performance) to calculate dimmer fades, run chases, and that sort of thing. At the time, pulling off that level of functionality at that kind of price was reasonably cool stuff.  DMX-capable lighting boards cost many thousands of dollars at that time and were extremely specialized.  Mine could be built on a PC-XT add-in card for under a hundred bucks.  Now, 20 years later, you can buy one of those as a USB device for well under half that, not even accounting for inflation – practically anybody (so inclined) in even the smallest theatre can get access to some pretty awesome technology using nothing more than a typical laptop.

Well, that was all fun and everything, but spending another few years in school to get another degree so I could keep doing hardware and playing with the toys was just economically infeasible. Since I also had a few really good job offers, it wasn’t really much of a debate: I hung up the wire wrapper and off I went to the world of software, as a “Program Manager.”  Leap forward 20 years or so…  I’ve now spent the last 20 years managing projects (granted, much more so at the technical end, than at the more mundane schedules-and-cheerleading type of work), but still not a whole lot of real grunt-work engineering, other than as a hobby.

If you’re reading this, then you probably know that over the last few years the whole “maker” DIY movement has really taken off, and there’s been a huge democratization of building electronic hardware, spearheaded by folks like Ladyada, Sparkfun, and Make magazine, Burning Man, SXSW, and so on. It ain’t just for geeks any more.  Since graduating, I’d built a few kits over the years like the old classic PAIA Vocoder (which sounds like complete crap, by the way), a Nixie clock, and a few other little toys, but given what you can see on any average day now on Instructables or in Make, eyes were really opened to just how much room there is for creativity in this space way beyond traditional consumer electronics.  I’ve therefore spent the last couple of years boning up on my underlying electronics knowledge in hopes of designing a few simple things myself, and not just assembling other people’s kits!  I’ve finished a few projects now, and have a several more in the incubator.

I have also, luckily, been able to recently finagle my way into a job in my company that bridges the software and hardware worlds rather nicely.  While being known mostly for software, my company also makes a few rather successful consumer electronics products that you’ve undoubtedly heard of, and so we have a team that designs and builds manufacturing test equipment to make sure those things work properly before we send them off to Wal-Mart.  This has been a real kick for me, because now I get to blend my PM skills with learning just an absolute ton about what it takes to build consumer electronics, at a positively enormous scale, in the real world.

So that’s me, and my hope with this blog is just to share a few things I’ve built or am currently working on, what I’ve learned that they didn’t teach me in school, and tools I’ve found useful (or not). Just sharing ideas, links, and knowledge!  So welcome, and drop me a line…

%d bloggers like this: