Geeking out part two

A few weeks ago, I wrote about a project I’ve been working on that uses a raspberry pi to mimic a sunrise as a sort of alternative to an alarm clock ( .  It’s generated a rather long list of learning experiences including things like the timing issues I wrote about previously.  After thinking about it, I figured it wouldn’t hurt to document a few of them.

First, debouncing switches can be easy or hard…  If you’re as dumb as me and want to set the system up to discriminate between long button presses, short button presses, and spurious noise it’s hard.  I think my completed debounce and conditional sleep code (they’re tired together) are almost a third of the overall code.  If all I wanted was to handle single button presses with the code waiting until it got one, it would have been pretty easy.  If I wasn’t interested in keeping the processor duty cycle and power consumption down, it would have been easy.  If I didn’t want to be able to have multiple functions depending on how the button was pressed, it would have been pretty easy.  If I had a better understanding of python’s order of operations and language syntax, it would have been much easier.  Unfortunately, I wanted to do all these things.  When I first got the prototype up and running, I thought I had a reasonable approach they seemed to mostly work.

When I sat down to write the code to run the new board design that included the hardware PWM controller, however, I made the mistake (or not) of scrubbing all the code.  I had seen some anomalous behavior trying to use the menu, and decided to look closer.  What I found led me on a rather long detour.  I ended up spending probably twenty hours working through the debouncing routines — roughly what I thought it would take to update it for the new controller.  Fortunately, it was pretty simple to swap out the old controller logic, so my overall time at the keyboard wasn’t all that different than I expected.  I just spent it doing different things than I had planned.

It all came together, but the most disheartening thing of all came when I turned the light on at the lowest brightness level.  It still flickers.  I can’t explain why.  The PWM controller is on a hardware clock that isn’t subject to processor load issues or interrupts.  In fact, the only time it should flicker or change brightness at all is when it’s begin commanded to change brightness.  However, it’s only noticeable at very low intensities, so I’ve decided to stop there in my quest.  It’ll have to be enough the way it is.  At this point, I’ve been using it regularly for a few months, and it’s been stable and run as expected with one exception:  the real-time-clock module I purchased off of ebay doesn’t seem to be working.  Without an internet connection, the time doesn’t update after losing power.   I’ll have to look into that later, but for now I’m just enjoying a little taste of success.

Leave a Reply

Your email address will not be published. Required fields are marked *