RGB Fairy Lights with only 2 wires (part the first)

I am a huge fan of all things blinky and light up. I’m less interested in things I cannot control remotely by writing a plugin for XTension or by building a new controller for it. While looking for RGB “fairy” lights on Amazon (“fairy” lights here being defined as some strands of what looks like magnet wire with surface mount LED’s soldered between then and then sealed into a little blob of epoxy) I came across these RGB ones and was intrigued since they appeared to have only 2 wires. There was no control wire or separate PWM lines for the RGB channels. (Amazon Link) These are by “Yihong” but there may be others that are the same.

They came with an RF remote which is nicer than the IR ones that some similar things come with. Since you don’t have to point it at the controller box. Interestingly enough the remote also has an IR led and so could be used by either type of system. I have not tested to see if it is running on the standard 433mhz band or does something special. Given that it appears the same as the thousand other such remotes I’ve gotten over the years for other LED displays or just for remote arduino projects I would guess that it does.
In spite of the picture on the box showing different colors on the strand at the same time, you cannot control the LED’s individually, only as a whole strand.

This is the very tiny control box. The strand is powered from a USB plug and this box does the work of receiving the remote signals and adding whatever data is necessary to the power lines going down the strand. I have not broken the case open yet to see whats in there.

While there is tons of information out there about the “neopixel” type LED’s and the newer “dot star” that Adafruit sells and are amazingly wonderful there is very little information about anything similar to this. If anybody knows the type of chip or LED that they are made from I’d be interested to hear about it.

This you tube episode from Julian Ilett shows him reverse engineering a similar protocol. The system used by my lights looks to be very different however. So the first step to seeing what it’s doing is to get it on the scope. Since the wires are just enameled I scraped some of the insulation off them at the end of the strip. It occurs to me that I might have gotten a cleaner signal by tapping it at the front of the string instead. I’ll try that in step 2 and see if it makes it easier for the scope to trigger on it.

These LED’s are different than Julians as they don’t pulse all the way to off. The data pulses drop the voltage to the lights down to 1.5 volts, but not all the way to off. This potentially makes sense as it would let the little processor in the LED chip continue to operate as it’s being updated.

 

Here you can see the amazingly noisy USB power supply, either from the hub I was using to power this or from the controller device itself I don’t know, but it didn’t seem to bother them. You can also see the tiny blips of the control pulses coming in every 100ms or so. 

 
Zoomed in on those a bit you can start to see the data.

There are 2 lengths of pulses. Since the on portion of the pulse is always the same length the entire duration of the data packet changes based on how many 1’s there are in it.

The short pulses, which I will call a binary 0, are approximately 5us with the bus at 1.5v and then 10us back at 5v. The actual measurements I got from the scope was 6us and 12us but they varied enough that I assume they meant to use 5 and 10us. That may have to be adjusted later if the device is very picky about the timing. The 1 binary pulse is 10us at 1.5v and 10us at 5v.

Every data packet starts with 8 “0” or short timing bits. These do not appear to change no matter what the string is displaying so I will assume they are a preamble that helps the receiver lock into the data rate. In the screen shot above you can also see the end pulse which is twice the length of the “long” or binary 1 pulse, 20us at 1.5v. 

There are 32 bits in total, one byte for the preamble and 3 more bytes which obviously encode the RGB values that the LED should display. I did several captures from the various solid colors the three different intensity levels, leaving out the preamble byte: I’ve added the decimal value of the binary next to them:

RED:   FULL:  0010 0110(38)  0000 0000     0000 0000

       MED:   0100 1100(76)  0000 0000     0000 0000

       LOW:   1001 1000(152) 0000 0000     0000 0000

GREEN: FULL:  0000 0000      0010 0110(38)  0000 0000

       MED:   0000 0000      0100 1100(76)  0000 0000

       LOW:   0000 0000      1001 1000(152) 0000 0000

BLUE:  FULL:  0000 0000      0000 0000      0010 0110(38)

       MED:   0000 0000      0000 0000      0100 1100(76)

       LOW:   0000 0000      0000 0000      1001 1000(152)

It’s quite obvious already that the 3 bytes are RGB values. You can also see that even when on at full they don’t send just an FF. Perhaps the LED’s would overheat at full on. There is some visible PWM even when a solid color is set to full on. Or there is a limit in the controller device itself that is not capable of 255 individual levels. They are rotating that bit pattern across for dimming the LED. At this point I’m thinking that the value is actually how long to wait into the PWM cycle before turning on that LED. That would make sense, it would let a larger number actually be a dimmer display. Just for fun sampled some of the other colors as well:

ORANGE: FULL:  0011 0001(49)  0101 0000(80)  0000 0000

        MED:   0110 0010(98)  1010 0000(160) 0000 0000

        LOW:   1100 0100(196) 0100 0100(68)  0000 0000

YELLOW: FULL:  0010 0110(38)  0100 1100(76)  0000 0000

        MED:   0100 1100(76)  1001 1000(152) 0000 0000

        LOW:   1001 1000(152) 0011 0000(48)  0000 0000

CYAN:   FULL:  0000 0000      1101 0010(210) 1101 0010(210)

        MED:   0000 0000      1010 0100(164) 1010 0100(164)

        LOW:   0000 0000      0100 1000(72)  0100 1000(72)

and now I’m wishing I hadn’t sampled those extra colors as they don’t seem to follow the same start point of PWM. Or perhaps they are just compensating for irregularities in how much the LED’s output at any given level. They won’t be the same certainly, generally red needs a much higher value than green and blue to look the same. 

In any case there is enough information here to get started trying to build an Arduino controller for the thing. I’m not entirely sure how to provide the 1.5v pulse level in hardware. Will it be enough to just run the stream power supply through a resistor? Will have to calculate the power draw of the LED’s and do the math to drop the voltage to that level. Or are the LED’s in sync with this pulse and so will be off when the data starts and therefore I’ll need a different value since the load would be less. Or will it be necessary to provide a 1.5v regulator and use a transistor or mosfet to bypass it when the strip should be given the full voltage. Some experimentation will be necessary. When I’ve had a chance to play with that I’ll post again.

My pick for the best LED bulb to use with home automation dimmers

Phillips and Cree seem to be in tight competition for your LED bulb money. They both have cheap and cheaper versions of their bulbs now in more and more interesting packages but so far very few bulbs available will work in automated dimmer fixtures. The one reliable exception that I’ve found that is available locally at a reasonable cost are these Phillips bulbs.

The model info on the packaging says “AmbientLED A19  model # 9290002268A(Upgraded 06/2013)” with an ordering code of BC11A19/AMB/2700 DIM 120V

The light color is 2700k, but they dont feel that warm to me. The light is a little brighter than the sick yellow you can expect from a label saying 2700k. 

They dim perfectly on every remote controlled home automation dimmer that I’ve tried them on. They work on dimmers that do not have a neutral which forces them to run a little current through the load to power themselves. They also will run as a single bulb on an old style X10 push button switch! This is amazing as there aren’t many other LED bulbs that can run in that configuration. Sometimes you can build a large array of bulbs that wont be on dim all the time on a no-neutral switch but these work as a single bulb.

They are silent, never making even a hint of a buzz and in the last couple of years that I’ve been buying them I haven’t lost a single one.

Dont be fooled by the Phillips label though, they have several other kind and formats of bulbs, like the very interesting flat ones, but those will not work with no-neutral dimmers. They will be on low all the time and cannot be turned off. The bulb pictured above does not have that problem.

Cree makes a bulb that is a little bit less expensive than this bulb and they now come in 60, 75 and 100 watt versions in both warm and cool color temperatures. I dont have a picture of these but they are the ones with the glass envelope coated in what feels like a dip in silicone rubber to protect you if the bulb breaks. These also work great on remote controlled dimmers and will also work as a single bulb on even an old style X10 push button switch. The downside of them is that they are noisy, buzzing very audibly when on a remote dimmer and even worse they flicker. These bulbs flicker even when there isn’t a dimmer anywhere around. I’ve got some of their flood lights that I am going to soon replace as even when on an appliance module with no dimmer around randomly they seem to think they need to flicker horribly. I cannot recommend these bulbs even though they do work on the dimmers because of the noise and flickering. 

The phillips bulbs are available here at Home Depot and online in many places.

Arduino, xBee and PWM lighting with XTension

Back on Halloween Ben and I built him a gigantic lightup inflatable pumpkin costume that was a great deal of fun. In addition to the el wire face on it we also built him an electric t-shirt with LED strips attached to an arduino, some buttons for lighting effects and a little 12v battery pack to power them.

You can see them there under his costume, at night they put on a great show, flickering and fading in and out and flashing brightly when he pushed the button that let them accentuate his awesomeness while trick-or-treating.  We used these cool white LED strips from adafruit.com. After halloween I removed them from the t-shirt and saved them for future projects. A future project revealed itself shortly thereafter in the form of aquarium lighting for his new fish tank. We didn't do any fancy remote control or PWM on them for version 1. We just taped 2 of the 4 little strips to some shelf support material I had and powered them from a generic 12v wall wort.

They worked great for a while, but the constant splashing of water on them and the metal bars soon took it's toll. I think that the power supply may have been a bit high too for they rather quickly started to degrade and individual LED's started to go dim. Even so they lasted several months, but finally died and it was time to rebuild. We had 2 more strips left over from the costume and this time we decided to do it right. PWM to control the levels so it could be dimmed, an xBee radio so that it could be wired into the Home Automation System and some buttons so he could set the level there. I had just finished an arduino interface for XTension and so decided that this should be a demo project on how to bring some of these things together. 

Here you can see how far the old LED strips degraded. The metal shelf support is rusty, the LED strips have gone opaque and you can see where some coper was exposed and turned bright green.

Yuck... This time I would build something with proper heat sinking and proper protection from the elements. I used a  piece of aluminum extrusion U channel as the base for them. It's available at HD and others as a shelf support. It's meant to go over the long edge of a plywood or particle board shelf to keep it from bowing in the middle. It wasn't quite the perfect size for 2 LED strips, they were a tight fit, but I added some extra adhesive behind them as well. 

Also you can see one of the bezel pieces. I printed those on the MakerBot out of translucent PLA. They are actually less translucent that I had though and I might replace them with just cut pieces of plastic soon, but they work for now to protect the lights from the water.

For the Arduino I went with a Fio. I'm not using the lipoly battery charging ability of it, just the fact that it's an arduino with an xBee socket built in. Both running at 3.3v so no other circuitry is required. Or so it seemed... The LED strips need to run at 12v, the Fio is rated at 12v input and initially booted and started up OK, when I had it wired in circuit and applied 12v the regulator on the board burst into bright flame or arcing or something. I removed the power with some alacrity thinking I had cooked the arduino and probably the xBee as well. Testing from USB power though showed them both to be just fine. Now thats impressive, a piece of gear that can actually catch fire and not break down! So instead of relying on the on board regulator I added a beefier external 3.3v regulator. That also released it's magic smoke upon startup. So at this point I took a step back and reviewed the rest of my wiring. Had I wired the mosfet backwards and was putting 12v into one of the input pins or something? Nope, everything looked good. So I broke out an anyvolt micro adjustable regulator and hooked that up instead. Adjusted it's output down to 3.3v and all was well. I guess 3.3v linear regulators just dont like an input as high as 12v. There are many dc/dc converters on the market now, and anyvolt also make a 3.3v version, but the adjustable was what I had on hand. Connecting that to the 3.3v input and bypassing the internal regulator completely brought it all happily back to life.

The mosfet in the picture makes PWM'ing high loads so very easy, no external parts required, not even a resister. This particular model is an N-channel power mosfet and I wired it according to adafruits excellent examples that are linked to from that store entry. Thats actually the same one that powered ben's halloween costume so it's still got some lumps of hot glue attached.  A $1.25 saved is a $1.25 earned ;) You can also see the LED strips powered up and running behind their makerbotted water protection. The plastic strips are just hot glued gently on top of the aluminum channel. I want to be able to replace them when they get a scuzzy from being in the water.

I mounted all three devices into a tiny plastic parts case with a hole drilled through the top/bottom for the xBee antenna. If you were using a lower output one with a chip antenna then even that wouldn't be necessary. 

The buttons in their final install position on the fish tank. Not very pretty, this end of the project will likely get a reworking.

The arduino interface for XTEnsion just provides a simple text based interface for sending values back and forth. basically just address=value with a return at the end. It can be extended of course ;) but for this that wasn't necessary. I opted to make the buttons and the light totally separate in the device itself, requiring the intervention of the computer in order to send back the light level in response to a button push. This means that you can't control the light if the computer if offline, but if the computer is offline I've got bigger problems than the fish tank lights. So in this code the buttons just send an ON when they are pushed (and no off, though I could do that easily enough if it's useful) and then the computer responds by sending a level for the lamp. There is a heartbeat delay between pushing a button and the response coming back, but this way I can set the levels in the computer without having to recompile the arduino code, or without having to write a lot of code to save the levels into the eeprom. So there are other solutions if you like that. You could also build this without any remote computer in the mix at all by just setting the lamp PWM value in the processButtons() handler. But this is an example of how to write arduino code that talks to XTension.

This is how the units are setup in XTension. The buttons receive the commands send from the arduino like:

  Serial.println( "button1=on");

and if you change the aquarium light units level it ends up sending a command like "LAMP=160"

XTension will also convert the address to be all caps, so keep that in mind in your arduino when comparing strings. In the code you'll see some commented out map commands as I was going to map the standard dim level in XTension, 0%=100% onto the range of PWM outputs available on the arduino, 0-255, but decided not to, just let us control it from here. In experimenting with it we discovered that 160 was plenty bright for the fish and the plants and struck a nice comprimise between light and heat output. Any more than that and the light bar started to border on hot rather than just warm. I want to keep these LED's for a long time so we are not going to let them overheat. And a value of just 4 is bright enough on the dim setting for Ben to use as a nightlight. It really does look like moonlight at that level and is quite pretty.

The computer control is important separate from the button control so that the lights can be turned on remotely when we are on vacation, or if he fails to turn them on in the morning. Since feeding the fish and turning on the light is part of his morning ritual he rarely forgets. But now I know when he last turned the lights on, and if it doesn't happen I can turn the lights on automatically and send me an alert so that I can feed the fish if he forgets. He's 8 and is really very good at taking care of them, but it does happen. 

Since the arduino has plenty of inputs and outputs available we have plenty of room available for future expansion. I think a water temperature sensor is in the near future, that will be easy. Perhaps some UV or deep blue LED's to make his fluorescent fish light up at night too. We're also starting to think about an automatic feeder that we would design and print on the makerbot and control from this same arduino.

Setting up xBee radios to work with XTension needs an entry of it's own as well. That will come shortly. Here is the source code free and open use it as you wish. download the arduino project

/*

  Ben's aquarium light 

  

  using an xBee to talk to XTension

  June 10 2013  james@sentman.com

  

  In this example, the 3 buttons send their ON to XTension when they are pushed, and XTension replies

  with the proper change to the light level. They do not directly control the level of the lamp.

  the lamp is only controlled from XTension by way of scripting from the button units.

*/

//input and output pin definitions

const int lampPin = 3;

const int upButton = 8;

const int midButton = 7;

const int downButton = 12;

const int ledPin = 13;

//these globals are used by the serial interface for talking to and getting commands

//from XTension via the Arduino interface. All commands are sent as NAME=value pairs with a 

//carriage return at the end. Set your buffer sizes to be at least as big as the longest command

//you expect to receive. These are oversized as only a single value is sent.

const int commandBufferSize = 19;

const int valueBufferSize = 22;

char commandBuffer[ commandBufferSize + 1];

int commandBufferIndex = 0;

char valueBuffer[ valueBufferSize + 1];

int valueBufferIndex = 0;

boolean gotCommand = false;

//debounce necessities

unsigned long lastButtonMillis = 0;

unsigned long currentMillis = 0;

int currentButtonPushed = -1;

void setup(){

  

 //make sure xBee is set to same serial speed. Could use faster of course 

 Serial.begin( 9600);

 //set the pinmodes for in or out as appropriate

 pinMode( lampPin, OUTPUT);

 pinMode( upButton, INPUT);

 pinMode( midButton, INPUT);

 pinMode( downButton, INPUT);

 pinMode( ledPin, OUTPUT); 

 //turnon the pullup resisters

 //to simplify the wiring I'm using internal pullup resisters for the buttons

 //that way I only have to connect them to ground.

 digitalWrite( upButton, HIGH);

 digitalWrite( midButton, HIGH);

 digitalWrite( downButton, HIGH);

 //make sure we startup off 

 analogWrite( lampPin, 0);

 //could always save the current value of the light to the eeprom 

 //and retrieve it at startup so that a power outage for a few seconds 

 //wouldn't result in the light being off.

 //give the led a flash

 digitalWrite( ledPin, HIGH);

 delay( 500);

 digitalWrite( ledPin, LOW);

 //write to XTension that the system is ready.

 Serial.println( "log=Aquarium Ready");

 //and update it's unit so that it knows that it's not on

 Serial.println( "LAMP=0");

  

  

  

}

void loop(){

  

   //currentMillis is used in the button processing in several places

   //so instead of constantly calling to millis() just do it once and put it

   //in this variable.

   currentMillis = millis();

   //check the serial buffer for any waiting command data and process it

   //if there is any

   processSerialCommands();

  

   //check for any button state changes

   processButtons(); 

  

  

}

/*

  this is part of the Arduino interface to XTension

  it can easily be reused in future projects.

  this just manages the command and value buffers and reading of data

  from the port. Any actual received commands will be passed to the next

  processCommand() method. Add any other incoming value handlers or special

  commands there. This handler shoulnd't need to be changed for most things

*/

void processSerialCommands(){

   int workByte;

  

    //if no data available then just return, nothing to do this cycle through loop

    if (Serial.available() == 0){

     return;

    }

   //read a byte

   workByte = Serial.read();

   //since all data is sent and received as name=value pairs

   //initial data is added to the command buffer. When a 61 or "=" is recieved

   //we finalize the end of the commandBuffer with a nul and start adding future characters

   //to the value buffer.

   if (workByte == 61){

      commandBuffer[ commandBufferIndex] = 0;

      commandBufferIndex = 0;

      gotCommand = true;

      return;

   }

   

   

   //this is looking for the carriage return at the end of the command line

   //if it finds the return then it finalizes the value buffer with a nul and 

   //resets the buffer indexes to get them all ready for the next command

   // and finally passes the most recently received command=value pair to the process command

   if (workByte == 13){

     valueBuffer[ valueBufferIndex]=0;

     valueBufferIndex = 0;

     commandBufferIndex = 0;

     gotCommand = false;

     processCommand();

     return;

   }

   

   

   //if we haven't finalized the command yet (or address as it's now called in XTension)

   //then we add the byte to the commandBuffer and increment the index to wait for the next one

  if (!gotCommand){

    commandBuffer[ commandBufferIndex] = workByte;

    commandBufferIndex++;

    

    //make sure that we dont overrun the buffer though and reset it if we're receiving garbage

    if (commandBufferIndex > commandBufferSize + 1){

      commandBufferIndex = 0;

      return;

    }

    

  } else {

    

    //we've already got the command because gotCommand has been set to true by the

    //check above for a 61 value or "="

    //so now add instead to the value buffer, increment it's counter and continue

    valueBuffer[ valueBufferIndex] = workByte;

    valueBufferIndex++;

    

    //make sure that the value buffer doesn't overflow and if so then

    //reset both the command and value buffer due to garbage on the line.

    if (valueBufferIndex > valueBufferSize + 1){

      commandBufferIndex = 0;

      valueBufferIndex = 0;

      return;

    }

  }

  

}

//XTENSION here is where you will receive incoming commands use the string objects to manage your response

//  add as many addresses as you need.

void processCommand(){

  String theCommand = String( commandBuffer);

  String theValue = String( valueBuffer);

  

  if (theCommand == "LAMP"){

    

    if (theValue == "on"){

      setLampLevel( 100);

    } else if (theValue == "off"){

      setLampLevel( 0);

    } else {

      setLampLevel( theValue.toInt());

    }

    

    return;

  }

  

  //add as many more comparisons for theCommmand as you need to for your application

  //XTension will always send address=value pairs if it's a change to a unit, though

  //any data may be sent with the "send data" verb including commands that have no value

  //though in that case you should still send the = and then immediately the return. like

  //reboot=/13 do not omit the equal sign.

}

void setLampLevel( int newLevel){

 //int adjustedLevel;

 //level from XTension is 0 to 100, map it so that we never go to all on 

 //adjustedLevel = map(newLevel, 0, 100, 0, 210); //keep it from going all on as that burns out the LED's

 //Serial.print( "log=level is ");

 //Serial.println( adjustedLevel);

 analogWrite( lampPin, newLevel);

  

  

}

void processButtons(){

  boolean debounceTimeout;

  

  if ((currentMillis - lastButtonMillis) > 100){

    debounceTimeout = true;

  } else {

    debounceTimeout = false;

  }

  

  

  if (digitalRead( upButton) == LOW){

    //upbutton is pushed

    if ((debounceTimeout) && (currentButtonPushed != upButton)){

      currentButtonPushed = upButton;

      lastButtonMillis = currentMillis;

      Serial.println( "button1=on");

      return;

    }

  } else if (currentButtonPushed == upButton){

      //the button is up but the last button pushed was ours so we can reset it

      if (debounceTimeout){

        lastButtonMillis = currentMillis;

        currentButtonPushed = -1;

      }

  }

    

 if (digitalRead( midButton) == LOW){

    //midButton is pushed

    if ((debounceTimeout) && (currentButtonPushed != midButton)){

      currentButtonPushed = midButton;

      lastButtonMillis = currentMillis;

      Serial.println( "button2=on");

      return;

    }

  } else if (currentButtonPushed == midButton){

      //the button is up but the last button pushed was ours so we can reset it

      if (debounceTimeout){

        lastButtonMillis = currentMillis;

        currentButtonPushed = -1;

      }

    }

    

  if (digitalRead( downButton) == LOW){

    //upbutton is pushed

    if ((debounceTimeout) && (currentButtonPushed != downButton)){

      currentButtonPushed = downButton;

      lastButtonMillis = currentMillis;

      Serial.println( "button3=on");

      return;

    }

  } else if (currentButtonPushed == downButton){

      //the button is up but the last button pushed was ours so we can reset it

      if (debounceTimeout){

        lastButtonMillis = currentMillis;

        currentButtonPushed = -1;

      }

  }

}

crank powered airplane to crank powered flashlight

Ben has been throughly enjoying his "Kid Galaxy Dyna Flyer Air Streak" airplane. It runs an amazingly long time on just a few moments of cranking up the launcher thing.

Unfortunately being made of foam it's lifetime was limited and we finally busted the little wires that run through the middle of the prop. Rather than just toss it we had to take it apart to scavange for reusable parts. I knew it had to be a super capacitor in there and indeed it was. 2.7 volt 7 farad. The motor we salavaged for some future project, but the charger and capacitor we kept together and added a multi-chip warm white power LED that I got off ebay a long time ago. I was using these for outdoor lighting long time ago but they didn't really last in that application, or I was overpowering them, so I had a bunch in the toolbox. There is a tiny board in there that shuts off the motor till it leaves the launcher, but we didn't use that, just soldered directly to the capacitor. The voltage is close enough that I didn't bother with a resistor or anything.

The charger is really quite powerful, about 7 seconds of cranking will run the LED at decent flashlight level for about a minute and a half with many more minutes at diminishing candle and then "find me" levels.

And of course you can shoot it across the room too as it's still on the sled that used to launch the airplane.

I haven't played with any of this new generation of super capacitors before, but they are certainly going to be useful! You couldn't use a battery in this kind of thing, it wouldn't work at all. I see now that there are a bunch of different versions of this toy, they aren't expensive and it was definitely fun. I'm not sure how we managed not to lose it into a pond or up on a roof or tree while we had it, and when it does inevitably crash and burn like all toy airplanes must, you can salvage the really cool super cap out of the inside!

Steampunk Photo Cube Lamp

A little over a year ago a friend of mine saw This Instructable for the “Architectonic Photo Cube” and I offered to build it for her if she ordered the pictures printed to glass. That was not long after we had moved and what with life in general the pictures sat here for a year before I got around to putting them together. I decided to use brass fittings rather than the standard zinc plated and build a nice oak/brass base for the lamp. Since she had waited so long I spent some extra effort on the switch putting in a little knife switch to control the lamp and since it had a second position that would have been boring as just “still off” I put a Candle Flicker LED on the second position so that the lamp can be operated in either lamp mode, or candle mode.

Assembling the photo plates I did pretty much according to the instructable. They look really nice in brass. The corner braces that I got in brass were larger 2” than the ones called for in the instructable so my angle brackers are closer together in the middle a bit, but it wasn’t a problem and looks just as good.

The springs are completely decorative and serve no purpose other than decoration. I was thinking I’d have to wind some copper coils to make them look good against the brass, but I just bought a couple of packs of assorted springs at HD and they were enough to fit. I might have gotten shorter screws than these too as the whole thing is rather more spiky than it technically needs to be but it’s still a stylistic approach.

The base is cut from a piece of 3/4 oak with oak molding around the bottom piece and the top piece has a small routed ogee at the top. The bottom has a cutout under the top part to fit the electronics.

This is a 7 watt Phillips LEd bulb, but we ultimately went with a 3 watt one to just illuminate the photos without trying to actually cast light, it was a better look. The 10mm candle flicker LED is also visible in this picture as well as the brass shelf brackets that I used to hold the top in place. Since the angle brackets I used were 2” ones the tab from those brackets fits perfectly between the nuts on the bottom 2 screws and do an excellent job of holding it to the base but still allowing you to easily lift it off to turn around to show the other pictures.

The corners I used these brass corner brackets that are also just available at HD, they are supposed to go on the top of a box, but I thought they looked cool on the bottom of this where they sort of overhang the curve of the molding. Underneath them is just a regular stick on plastic non-slip foot thing to raise it up enough for the cord to get out.

The control system required some extra parts to make the knife switch safe, obviously you can’t put the 120v for the light through the knife switch. That black box there is a little 6v power supply that I just soldered to the power plug directly. That is that runs to the knife switch and powers the candle flicker LED. When the switch is in the other position it turns on a Solid State Relay that isolates the knife switch from the mains power needed for the LED bulb. I considered building a custom LED array to light it all from low voltage, but this offers more options for lighting and was actually much simpler.  The 6v power supply there is just slightly too tall to fit glued in there with a cover over the entire assembly so I made a cutout for it. I could have dremeled or notched the bottom of the plate to cover it completely but I had made enough sawdust at this point and needed to finish the product ;) There are no exposed high voltage wires inside there even if little fingers should turn the lamp over and poke around.

See how well the brass shelf supports fit between the angle bracket screws. Measuring for where to drill the holes was tricky as the offset of the shelf supports was 3/8” and my table saw has come out of alignment a bit so that piece wasn’t quite square and the routed profile meant getting a measurement to the actual edge was a pain. But it’s close enough to centered that it looks fine unless you attack it with a ruler.

The cord completes the steampunk/vintage feel of the thing. Ordered a spool of absolutely beautiful fabric woven wire from Sundial Wire.

In the dark my camera made it look more like a steampunk nuclear reactor ;)

LED Under Cabinet Lights

(repeating the past... I am moving this post manually from my old server to blogger. This was originally posted on August 11th, 2010)

Really nice new house, but the lights under the cabinets are so ancient that the tubes actually have a starter and click click light BZzzzzzz. Totally unacceptable! Good under cabinet fixtures, even of the regular florescent type (and I have no interest in the halogen type, too hot and wasteful not to mention continual bulb changes) are very expensive, upwards of $50 a light and more for the wider ones. Little LED ones are available but they are even more expensive but not nearly as bright. Current limited power supplies for LED's are available now directly from china at pretty decent prices and one watt warm white LED's are not that expensive anymore either so I tried to roll my own to replace the lights here.

The power supply is a 7 to 12 LED driver from dealextreme.com and the LED's are from them too. All you have to do is solder them in series and glue them to a heat sink. But that is not as easy as it sounds...

I decided to reuse the fixture cases already wired in under my sink, the power supply is small and will easily fit in them. I used a piece of u-channel aluminum an inch or so shorter than the length of the bulb that used to be in the fixture and arranged the LED's upon it.

First lesson learned: The wire I used was too thick. It's just a watt of power so thinner wire would have been fine and would have made it much easier to manage during the glue up portion.

Here's the channel with the led's being held down while the epoxy cures with blue tape.

as it turns out, blue tape could not hold them in place with the resistance from the overly heavy wire I used and none of the glued flat. Heat kills LED’s they must have good attachments to the bar or they will dim early.

So I pried them all off and began again, this time using one of these blue clamps which have cutouts in the face just about the right size to cradle the lens on the LED without breaking it. So now they are all glued on right and they are really quite impressively bright even without any lenses.

I just screwed them into the same case as the old lamp, replacing the ballast with the new power supply. They are quite a bit brighter than the old lamps and are a superior color temperature the heat sink gets warm to the touch but never so hot that you couldn't hold it which means that either I"m not making good thermal contact with the LED's and they will shortly self destruct, or that it's working great and well within thermal limits for long life.

Putting the diffusor back over them though reduces the output considerably, so for now I've left it off. You can't see them under the cabinet anyway, but I need to figure out some better ways to make it pretty before I replace the rest of them.

(letters from the future: I ended up building 4 of these for under the 2 countertop areas they are terrific. The light maintenance hasn’t been 100%, probably down to 80% and then stopped degrading in any way I could notice in the last year. One LED burned out for some unknown reason in the middle of one array, I replaced it and it came back to life. One power supply stopped working and was replaced with a newer version from DealExtreme with similar specs. I am very happy with them still!)