Close
0%
0%

Integrated Room Sunrise Simulator

An alarm clock that provides dawn simulation using your rooms existing lighting

Similar projects worth following
The Integrated Room Sunrise Simulator, dubbed IRIS for short, is a custom alarm clock to provide dawn simulation. The clock connects via wireless signal to an in-wall dimmer providing a soft ramp on for a gentle wake-up, typically over a 10 minute period.

  • 1 × LUTRON MRF2-600MTHW Dimmer Switch, 600W Multi-Location Maestro RF Wireless Dimmer w/ Pico Remote
  • 1 × ATMEL MEGA168A Microcontroller
  • 1 × MAXIM DS1339A Real Time Clock
  • 1 × AUSTRIAMICRO AS1115 LED Driver
  • 1 × BOURNS PEC16-2xxF-Sxxxx Rotary Encoder w/ Switch

View all 6 components

  • Working on the Enclosure

    Ceady08/19/2014 at 08:40 0 comments

    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.

    Failed Raster Engraving for LED Diffusion

    Silicone and Cornstarch LED Diffusion

    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.

    Old Rear Panel

    Revised Rear Panel

    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 »

  • The Wireless Interface

    Ceady08/17/2014 at 09:18 2 comments

    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 »

  • Stepping up my game

    Ceady08/06/2014 at 08:08 0 comments

    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.

  • The Beginning. . .

    Ceady08/06/2014 at 03:16 0 comments

    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. 

View all 4 project logs

Enjoy this project?

Share

Discussions

corry lazarowitz wrote 01/25/2019 at 04:57 point

I know this project is old, but I want to offer my thanks for the Lutron info.  I love my caseta system, I don’t like it being cloud based.  I’d like to take over the base station with an sdr.  I don’t plan on publishing any success, as it looks like the protocol currently is pretty simple, but the new picos, for example, have everything in one chip, and that chip has an aes accelerator.  I’d rather not have to figure out a way to force a firmware dump (probably through decapping) to get that key, so I’d rather Lutron keeps it simple.  Besides, I think with your spi dump, that ought to be enough to figure the whole thing out for anyone with an sdr.  I can say the new picos are extremely noisy.  Had me wondering if it was somehow 4FSK rather than a form of bfsk!  Maybe I should have moved my antenna closer to the base station :)

It may also be they have multiple forms they can use, so here’s hoping that’s not the case...

  Are you sure? yes | no

drojf wrote 07/15/2017 at 13:16 point

ooh, I haven't seen silicone used as a diffuser before, I might try the same using hot glue (for prototypes)

  Are you sure? yes | no

Blecky wrote 08/18/2014 at 17:45 point
I will definitely be following this and building something for myself once I get time.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates