An alarm clock that provides dawn simulation using your rooms existing lighting
If I have one piece of advice I can offer about my experience thus far with the project enclosure, it would be to design your system whatever it may be to the enclosure, and not design your enclosure to your system. This is likely why I end up with projects sitting in cardboard boxes for years without ever finishing them even though they are electrically functional. Instead I've operated from the beginning with hand sketches of what the final product may look like, adding PCB holes for screws where they may possibly be, and ultimately having enclosure tolerances that I just can't meet without multiple iterations of the various pieces.
I first want to discuss LED diffusion. I initially set out to create a custom clock face to set this clock apart from a standard looking seven segment display. I purposely elongated the bottom of my numbers to be unique and added a few symbols and indicators that were beneficial for my purposes. As a result the LED's were surface mounted on the PCB and a stencil type acrylic plate was laser etched to sit over top to prevent light bleed from each segment and provide some readability. This worked well for preventing light bleed but the display was in no way readable. So the trial and error process began. I tried raster engraving a clear plate above the stencil, cut portions of plastic milk jugs, used various types of paper (wax, parchment, rice, etc.), and clear silicone, all of which were poor diffusers. I then came across an article in Make that discussed adding cornstarch to silicone (http://makezine.com/2010/11/04/reader-research-diy-casting-silicon/) and thought it may be worth a shot. I mixed multiple batches altering the cornstarch content until I was relatively happy with the level of diffusion. I applied the silicone with the acrylic stencil on top and let it sit till cured. Other than being a mess to apply, it significantly reduced the hot spotting from the LED's. It wasn't perfect, but it was the best result that I was able to achieve up until this point.
I continued with this prototype until I came across some 3M diffusing film specifically design for LED diffusion in outdoor signage applications. Unable to source a small enough sample, I continued searching for similar films until I found this matte light diffuser film from inventables.com which promised a cleaner more consistent application.
After having a chance to play around with the film I have a better grasp of its use. I plan on changing the acrylic stencil to white to increase reflectivity within each segment, and I also plan on increasing the thickness of the acrylic as the film works substantially better the further it is from the light source. Both modifications will help reduce the still visible hot spots.
At this point I'd just like to make a comment about LED binning. I ordered a second batch of LED's from the same manufacturer with the same part number and wavelength and noticed how different the color actually is between the two orders. Although not apparent in the photos, one of the digits in the above image uses LED's from the second order and is substantially different enough to be distinguishable to the eye. I will not make that mistake again.
The rear acrylic panel uses a Decora sized cutout for the PICO remote and provides some instructions for clock use. In the final enclosure the power jack will also be located on this panel, as shown in the sketch, using a philips and flathead screw to secure the connector and to indicate polarity of the DC jack. I also need to purchase the remote in black to match the acrylic.
Finally the banding to hold the two clock faces together. . . this is where my current issues lie. I've attempted to use some 1/8" aluminum to wrap the acrylic, but without a metal brake or really any proper metal working tools the fit is too...Read more »
There were a few basic thoughts I had in mind when working on the wireless interface, ideally the clock would;
- control the ramp on of the lighting for the dawn simulation
- have the ability to turn the lights off if the snooze button was pressed
- maintain all the functionality of the Lutron PICO remote, and have it easily accessible
At this point I had it in my head that I needed to reverse engineer the PICO wireless remote protocol so I could incorporate the design directly into my clock. Thus began my trip into the rabbit hole which I later abandoned once I re-evaluated my approach. But none the less let me fill you in on where I went and where I left off, so if anyone has further info to help assist in understanding the transmission packets I would greatly appreciate it.
I first identified the main IC's on the PICO remote, noting the TI CC1150 as the chip responsible for the wireless transmission. Armed with the data sheet and a Saleae Logic analyzer I soldered on some 30AWG wire onto the SPI pins and started recording some data.
(This image actually shows connections to the power and buttons but the idea is the same, I had already de-soldered my SPI connections and wasn't about to re-solder to take a picture of it :)
Using the SPI analyzer in the Logic software, I exported the data to a CSV file to pick apart further (see WirelessAnalysis folder in github for the Logic captures and a spreadsheet for both on and off command data). The first packet in the transmission resets the transmitter and re-establishes all the control registers. Registers are set as follows;
Using TI's SmartRF Studio 7 (a free download) I entered the above values into the registers which then provided the below configuration (which could also be deduced from the data sheet register explanations, but this seemed quicker);
Base Frequency 433.602844 MHz
Channel Number 0
Channel Spacing 49.987793 kHz
Xtal Freq 26 MHz
Data Rate 62.4847 kBaud
Modulation Format GFSK
One of the oddities of the transmission packet, is that it alters the FREQ0-FREQ2 registers twice but with slightly different values. It is not immediately apparent why this would be done . . . I plan on re-visiting this at some point in the future.
The data packets:
Feeling fairly confident in what I had found so far I continued to evaluate the data packets that were repeated after the initialization packet. It was determined that the quantity of repeated data packets was based on the length the user pressed the button, although I'm sure there is a minimum repetition that occurs regardless of how fast you can press a button. Each data packet remains the same length and carry's all the same data with the exception of the pulse count byte and what appears to be a CRC and checksum value (highlighted in red in the PICO.xls file in github). I've got some research to do here to see how these values are actually calculated.
The pulse counting byte always begins at 0x01, and then increments as follows; 0xC1, 0x61, 0x91, 0x31, 0xF1, 0x49, etc. Noticing a pattern, I realized that if I mirror the binary of each number, add three, and mirror again I follow the pattern above. So for example 0x91 in binary is 1001 0001, then mirrored as 1000 1001, plus three, 1000 1100 and mirrored again 0011 0001 equals 0x31 which is the next number expected in the count. I'm not clear on whether the pattern works this way due to the transmission system, i.e. FIFO (first in, first out), so it may look funny on the transmitter side, but make perfect sense on the receiving side. . . once again something I'd like to revisit to understand better.
The actual command data is done in two bytes (highlighted in yellow in the PICO.xls file in github), and appears to always add to the same value, for example ON has the values 0x74 and 0x12, while OFF has the command values 0x76 and 0x10 which I assume is some type of parity system...Read more »
A couple kids after my original proof of concept, I decided to revisit the original project. With renewed vigor I set out some basic goals and got to work. This version would be wireless to avoid the mixed voltages in the wall box, and would permit a clock in a regular form factor (at least eventually) adjacent my bed (as opposed to tucked in the closet). I would use a real time clock and LCD display to customize how the clock functions and looks, which would allow for custom on and off delays, ramp times, etc.
I created my first PCB's in the backyard using the sponge and ferric chloride method, making small modules as opposed to one large circuit board both so I could reuse them for other projects and to limit my troubleshooting if things went bad. Thankfully troubleshooting was limited to a small solder bridge, and a couple of over etched tracks on the LCD module, but otherwise no significant issues. If you look close you can see where I soldered some small wires across the tracks that were damaged.
Here's how things were looking:
Upper right is a little capacitive sensor which was originally going to be for the snooze on/off until I realized it was kind of hard to tell if you hit the snooze without the tactile feedback. The sensor was a QPROX QT100. On the left is the rotary encoder breakout, and the LCD panel which also included the RTC chip as they were both on the I2C bus I figured I may as well have them on the same PCB.
Here is the back of the LCD PCB:
I'm sure Dave Jones ( http://www.eevblog.com/ ) would have something to say about this crusty looking board. Considering this was one of the first PCB's I've ever made and it was double sided he might let it pass . . . maybe.
At this point with a working clock and controls it was time to work on the wireless interface to control the dimmer.
This project first began while attending University in northern Ontario, Canada. During the winter months I would leave for school while it was still dark and return from school when it was already dark. Sometime during this period I stumbled upon Eric Wilhelm's Instructable for an Arduino controlled sunrise alarm clock (found here; http://www.instructables.com/id/Arduino-Controlled-Sunrise-Alarm-Clock/) and knew this would help get me out of bed in the morning and off to classes on time. Only I didn't want blue LED's nor the desk style lamp he created, but nevertheless it was a good starting point.
My first version of the project consisted of a cheap travel alarm clock, which had the piezo removed and the wires reconnected to an Arduino Extreme V2 (these probably can be found in museums at this point), with the output of the Arduino driving a relay which was literally soldered across the raise up button inside the dimmer (pretty much disregarding any NEC code or common sense). Finally I mounted this dimmer in the wall and ran the low voltage wires through the back of the wall into the closet where the clock and Arduino lived. Since the relay was in the closet the switching noise was muffled and barely audible. The Arduino checked for an incoming pulse from the alarm clock and then sent pulses to the dimmer switch to simulate button presses. The length of these pulses were determined empirically, and were sensitive enough that I had to adjust the pulses once additional cable length was added between the relay and the dimmer.
Here are the pieces to the original project:
It was a hack in every sense of the word, but it was a quick build, it worked and proved that the concept was useful enough to do a second revision.