Since we moved back into a city and left behind a mostly rural life I’ve had to adjust my hobbies to the new environment.  I don’t spend much time planting fence posts, the only animal I take care of now is an old and grouchy dog, I don’t have old or worn out farm equipment to rebuild or repair, can mow my lawn with a weed whacker, and couldn’t fit a car in the garage to work on it if I had to.  This has been a hard transition, but it has given me an excuse to reengage with several hobbies that have lain dormant for quite a while.  One of the things I’ve restarted has been playing with electronics.

Back in high school I spent a lot of time in the electronics shop designing and building various projects that included a simple television jammer, an all electronic Christmas tree that could flash lights in various sequences, and a custom built clock that was crazy enough that it made airport security really uncomfortable when I took it to Kansas City for a national competition (after x-raying it, they  made me disassemble it and show them it wasn’t a bomb).  My brother Tolon and our neighbor Mike have tons of stories about the crazy stuff we did with electronics growing up, so needless to say, it was a big part of our adolescence.  However, once I left college and the part-time television repair job I had, electronics mostly fell by the wayside.   It wasn’t that the interest faded.  It was really just that I had a long list of competing priorities and interests.  Besides, I don’t have much use for the kinds of simple projects I could build at home.  While flashing lights are cool in some respects, it doesn’t do much for me once it’s built.  I have a higher standard of applicability for projects these days.

This last Christmas, however, I bought Isaac a robot car that used a raspberry pi for the controller.  Unfortunately (or not, depending on how you look at it), the cheap Chinese version I bought came with code that was so bad that I spent my Christmas break learning Python and writing new code from scratch.  I hadn’t done much coding for a long time, and in the process of making a functional software set for the robot I remembered how much I like that kind of a puzzle and challenge.  Another thing working on Isaac’s robot did was get me back looking at electronics hardware design and thinking about the software/hardware interface in ways I hadn’t before.  I have been a Linux geek for over 20 years, and the possibilities of a super-cheap, super-small Linux-based computer with exposed low-level I/O ports really piqued my interest to the extent that I actually had a spell of insomnia while a whole host of ideas for things I could do with it flooded my mind.

It didn’t take too long for me to realize that the best way to get sleep would be to pick a project and get to work on it.  As I thought about it, I kept coming back to a project I’d built years ago and decided it was time to update it and build it again.  The original project was nothing more than a Mr Coffee that I stripped the electronics out of and repurposed to turn on a light at a given time every day.  This light woke me up every morning for several years, but it was bulky and ugly, and the way the light turned fully on instantaneously was rather jarring.   In an effort to fix this shortcoming, about five years ago I designed and built an analog circuit to gradually turn on a bright LED lamp.  Unfortunately, Liz hated the bright white color and couldn’t stand the fact that the LEDs weren’t diffuse enough.  They were rather blinding if you looked right at them.  I had to retire the light and Mr Coffee electronics.

In thinking about the possibilities of a super cheap computer with easy to use hardware interfaces, I came to the conclusion that I could easily build a control circuit to digitally dim a three color LED.  I decided to build a raspberry pi based project that would mimic both the brightness and color of a sunrise at any time I wanted to wake up.  Because it was software driven, I could tailor both the brightness and color to match a sunrise from start to finish.   I would also be able to set it up so that I could program different alarms for weekends or any other unusual day.  Not only that, but I could even program it to do any kind of goofy rainbow-colored light show if I ever got the inkling (but I have to admit that the odds of that are kind of low).

Now, I haven’t made custom circuit boards in almost 20 years, and I haven’t written much code since I left grad school.  A sane person might hesitate to jump into what amounts to two simultaneous complex projects, and you might think it would at least have given me pause.  But no, true to form I jumped in.  I scoured datasheets from several electronics vendors, ordered materials for etching circuit boards, and began learning Eagle CAD.  Before too long, I had a schematic complete.  Not long after that, I had a circuit board layout.  A few failed attempts later I had a complete board and was on my merry way writing code to see if it would all come together the way I intended it.

After fumbling around with Python and learning some of it’s ‘features’ the hard way, I managed to make the LCD and buttons I bought work as a menu of sorts, and got it to start the sunrise sequence on-schedule.  Pretty stoked about my progress, I plugged it in near my bed and set it to go off the next morning.  Unfortunately (or perhaps fortunately) I woke up a few minutes before the alarm and was watching it as the first blue-gray light started to come on.  Almost immediately, I realized my design wasn’t going to work.  At low brightness, the light flickered enough to really bother me.  I wanted to understand why, and what I could do about it.

As it turns out, one of my day-job responsibilities is setting design criteria for safety critical systems, and I had spent a good deal of time recently getting familiar with what are known as “real-time operating systems” and their role in safety-critical applications.  In any modern computer, multiple processes (programs) compete for processor time.  The operating system will hand control to a process, and how long that process has control before the next process gets to do it’s part is not tightly controlled.  For example, if you’ve ever been working on a computer that suddenly ‘hiccuped’ for a second and then caught up with you, you have been the victim of a non-real time system.

For routine applications, a slight hiccup that results from a process taking too much processor time isn’t all that important.  The process will eventually finish and the computer will catch up without any dramatic consequences.  However, if that computer were flying a plane or guiding a missile, even a slight hiccup could result in a crash.  For these situations, a special type of operating system is put in place to make sure that the important stuff always gets the processor time it needs, and only the unimportant stuff occasionally gets stuck with a hiccup (if at all).  Everything runs on a heartbeat, and important stuff gets done every heartbeat, every time.  When done properly, this kind of a system ensures that there aren’t any hiccups on things that matter.

So, how does this apply to my stupid little project?  First, it’s fundamentally difficult to efficiently dim an LED the way you would dim a conventional light bulb — especially using a digital controller.  Instead, to dim a high power LED you turn it on and off very rapidly, and our eyes average the intensity naturally.  To make the light brighter, you leave the light on for a longer percentage of the time.

Well, as it turns out, the code that determines how long the LED stays on works by deciding every few microseconds whether to turn the light on or off.   Because the ultra-bright LED’s I used are so bright, when I want them to be very dim the lights are only on for a few of these cycles before they turn back off again.  Even small changes in how long the lights are on in that case make a big difference in how bright the light looks.  The way this thing is set up, it turns the LED on and off 200 times a second (each cycle is 1/200th of a second) to make sure the human eye can’t see it flickering.  To make the sunrise work, I break that 1/200th of a second into 1024 chunks (why not just a round 1000 you ask… 1024 = 2^10, and computers do most things best with powers of 2).  When the light is at it’s dimmest, it’s on for 1 chunk (about 1/200,000th of a second) every cycle.  When the light is all the way on, it’s on for the full 1024 chunks and never turns off.

When the light is at it’s dimmest (where I start it in a sunrise sequence) even a five microsecond delay (about 100000 times faster than a blink of the eye) will cause the light to stay on twice as long as it should and change the brightness by a factor of two.  Small glitches make a big difference.  As the code runs through it’s loop deciding when to turn the light on or off, other processes randomly run a little long, and the decision to turn off the light is delayed just a bit.  Because the raspberry pi isn’t running a real-time operating system, there is competition for processor time, and that shows up as a flickering light that flickers worst when it’s on very low.  Because I’d just been through the wringer working through the real-time operating system stuff at work, I instantly recognized the situation for what it was.

Unfortunately, this realization meant that my design was fundamentally flawed.  I had relied on the pi for timing, and even using the most optimized code I could find to run the timing, the light still had a noticeable flicker.  Did that stop me?  If you are reading this, the odds are pretty good that you know a fair bit about me already, and could guess that I don’t quit that easily.  One solution would be to implement the code in a real-time operating system.  However, I’m not really an expert on those systems, and I don’t believe they’ve ported real-time linux to the pi.  The answer would have to be a hardware-based timer for the lights, and the best part is that I already knew where to go to find one.

Something I learned while working with Isaac’s robot car was how servos work (the small motors that steer the car and point the camera).  They work by generating a pulse with a very specific width proportional to the turn angle at regular intervals, just like the way I was trying to control the lights.  Robot designers don’t use the I/O pins on the pi to control servos for the same reason it didn’t work well for the lights — flickering, but in the case of servos, they don’t flicker, they jitter back and forth.  If you’re using the servo to control a remote-control plane for instance, that jitter would make the plane uncontrollable and result in a crash.  In Isaac’s car, the designers had actually re-purposed an LED controller with built-in timing to generate the servo pulses, and I was already familiar with how that controller worked and how to program it using the pi.  It would be an easy answer.

Frustrated, but unwilling to give up, I pulled open the schematic, deleted the control lines that I had been using, and added in the controller.  A few days of spare-time later, and I had a new board layout ready to process.  Thankfully, when I originally ordered parts for the first board, I had planned for the probability that I’d ruin several boards and had ordered plenty of extra resist film and copper-clad board.  I was also willing to bet I’d break something or need to re-build another board, so I had spares of all the parts.  I etched and solder-masked another board and built it out with everything but the new controller.  At this point, I’m waiting to order the new part and am looking forward to getting the code written and version 3 up and running (version 1 died before the first hardware met the real world).

At this point, if I were to add up the number of hours and the money spent on parts and processing stuff, this would definitively be the most expensive clock I’ve ever owned.  To make it worse, I’m looking at probably 20 more hours of coding to fix bugs in the current code and integrate the new controller (I’m not particularly efficient with Python).  Given my going labor rate, I can’t afford my own time.  But then again, it’s not really about either the cost or the time.