Skip navigation

Arduino

5 Posts authored by: beavertank

Unfortunately, I didn't manage to complete all of the features I had hoped for with my ornaments. Not long after Christmas I caught a flu that knocked me out pretty completely for a surprisingly long time, and when I finally returned to the land of the living I had to play catch-up in my personal and professional life, so my ornaments got pushed to the back burner. Even so, I had high hopes for completing them within the time provided by the contest, but when I jumped into programming the Yun it was just too different from what I had done before and I ran out of time.

 

The ornaments are in a minimally usable state: The physical objects themselves are designed and readily printable, the library I wrote to control the Infineon board works, and the prototype I built does just what it should. The only thing it's missing is the IoT half of the project, so unfortunately you can't remote control the colors, and they don't yet act as notification devices.

 

I still intend to complete them, because it's still a neat project, but unfortunately I won't be able to do so within the timeline set for the contest. C'est la vie.

 

Building the Ornament

 

Step one, naturally, is to print the parts. Attached to this post you will find the three files you need: ornament mk2 - outer top.stl and ornament mk2 - outer bottom.stl will produce the outer shell of the ornament, while ornament mk2 - inner.stl will produce half of the inner support structure for the strip lights (you'll need to print two copies of this one). I've also included the source file that creates these STLs, ornament mk2.scad, and if you're so inclined (and are familiar with openscad) you can make modifications to the design.

 

Once you have them printed, you'll notice both the inner and outer shells have five holes in them. These are sized so pieces of 1.75mm filament will fit into them and can be used to anchor the halves together (or simply to align them if you plan to add additional glue). Depending on your printer's first layer calibration you may need to help the holes out with a quick bit of trimming or drilling, but don't expand them too much as you want lots of friction to hold the filament bits in place.

 

inner halves with filament.jpg

After you have the two inner pieces printed and assembled, you'll want to attach the LED strips. The design is sized for the commonly available 5050 LED strip lights, although I believe most LED strip lights are fairly uniform in terms of strip size, it's just LED size that changes. But you may find that assumption to be incorrect. If it does turn out to be wrong, you've got the source file and can easily modify the channel widths to fit.

 

I found that hot glue works well for attaching the strips to the plastic. Once they're tacked down (careful to avoid the solder pads on either end!) it's time to wire. You want to connect the strips in series, and you want to connect each solder pad to the identical pad on the next strip (i.e. 12v to 12v, red to red, green to green, etc). You also want to make sure both you leave two LED strips with unconnected top pads when you're finished linking all of your strips, because this is where the input and output connections will go.

 

I chose one strip to be "strip one", then connected the bottom of that strip to the top of "strip two". I did the same for strip two and strip three, as well as strip three and strip four. I then connected the bottom of strip four to the bottom of strip five. This left the top of strip one and strip five open so I could have the input and output connections coming out on the same side. Luckily for us, these LED strips are non-polar, so you don't need to worry about orientation or getting the right sides together at all.

 

wired up sm.jpg

In the above picture, you can see the strips attached and wired together, with the input connection already in place. I made a bit of a mistake in that I soldered the input wire in place before threading it through the hole in the outer shroud. The hole in the shroud is easily big enough to allow both sets of wires to pass, but the connectors won't fit. So make sure you don't do what I did, and thread your wires through the outer shell first.

 

Once everything is wired together, start on your next one! Using the "4pin male to female extension wire" for LED strips, which you can easily find on Amazon, you can link together as many ornaments as you need. A single 5m roll of LED strips should make ten separate ornaments, and a single Infineon shield can easily power them all simultaneously.

 

When all the ornaments are assembled and connected, wire the first one back into the Infineon board, and upload the Arduino sketch and library found in this post: IoT Christmas Ornaments - The Software, Part 1

 

The linked post explains how to change the code to make it do what you'd like and, for now, that's all you can do. Unless you'd like to finish the incomplete Yun/IoT portion of the project... or you don't mind waiting. Sooner or later I'll get these working correctly, but for now, this is where the project ends.

 

It was a fun time, and interesting components, but in the end life got in the way and slowed things down too much.

I've been hard at work on my IoT Christmas Ornaments project, specifically getting the software and firmware for my little lights working nicely.

 

As a first step toward that goal, I dove into the manual Infineon provides for the XMC1202 board in order to get a feel for how it works. In the end, I decided to follow Peter Oakes lead and produced a library for the board. While Peter's library focuses on using text-named colors, I wanted mine to act more as a simpler overlay for the actual control of the board, so mine is geared more toward being passed numerical values. Someone more ambitious than I may, someday, want to combine both functionalities into a single library. But for now, this works for me.

 

The library files, as well as a test program, are attached at the bottom of this post.

 

The Library - rgbshield

 

The library implements a number of functions which can be used to control the basic functions of the Infineon board.

 

There are four functions which can be used to set the intensity of each color channel:

 

setrgb(Red, Green, Blue) - Sets the intensities of all three color channels at once. This is probably the most common method of controlling color. It accepts three integers as inputs to set the values of the red, green, and blue channels respectively. The valid inputs range from 0 to 0xFFF (or 4095 if you prefer decimal).

 

setred(Red) - Sets the intensity of the red channel only. This accepts one integer as an input to set the red intensity, and the valid inputs again range from 0 to 0xFFF.

 

setgreen(Green) - Sets the intensity of the green channel only. It is otherwise the same as the setred function.

 

setblue(Blue) - Sets the intensity of the blue channel only. Again, it works the same as the previous two functions.

 

There are also three functions which can be used to set the other basic parameters of the board:

 

setbrightness(Bright) - Sets the maximum allowed brightness level of the board, from 0 to 0xFFF (or 4095 in decimal), with its single integer input. This doesn't simply set a cutoff point, above which any values will produce the same intensity of light, this acts more as a dimmer switch. If, for example, you passed a value of 0x800 to this function (so 2048 in decimal, or 50% brightness) it would cut all intensities in half. A pseudocode example may help illustrate this more clearly:

 

    setrgb(0xFFF,0xFFF,0xFFF); --> Full intensity white light

 

    setrgb(0x800,0x800,0x800); --> Half intensity white light

 

    setbrightness(0x800);

    setrgb(0xFFF,0xFFF,0xFFF); --> Half intensity white light

 

    setbrightness(0x800);

    setrgb(0x800,0x800,0x800); --> Quarter intensity white light, because the rgb intensity values are multiplied by the brightness level set

 

setwalktime(Walk) - Sets the time the board takes in transitioning from one color to the next. The single integer value passed here should be multiplied by 0.01024 seconds to determine what the actual walk time will be in seconds.

 

setfade(Fade) - Sets the time the board takes in going between brightness levels. This also accepts a single integer value as an input. The value set here isn't used linearly, because the board will follow a pseudo-exponential curve when changing brightness levels (in order to mirror the semi-logarithmic way our eyes perceive brightness) to create the appearance of a linear shift in brightness. This makes it difficult to give a quick and easy method of determining the actual time the board will take to transition from zero brightness to full brightness, so if this is a value that's important to your program you're just going to have to play with it until it looks good (and probably use the read function to determine when full brightness is reached rather than attempt to do it by absolute timing).

 

The library contains six functions which can be used to read the current state of the board's outputs. All six return an unsigned integer containing the current value of the requested parameter and require no arguments to function. There are three used to read rgb intensity values:

 

readred()

readgreen()

readblue()

 

As well as three used to read the other board parameters:

 

readbrightness()

readwalktime()

readfaderate()

 

I have also included two of the Infineon created functions for use with the more advanced parameters which are mainly set during setup (these parameters will be discussed later):

 

I2CWRITE2BYTES (int Address, int Command, unsigned int Data) - Allows two bytes to be written to the shield in order to perform whatever command value was passed.


I2CWRITE6BYTES (unsigned int Address, unsigned int Command, unsigned int DataOne, unsigned int DataTwo, unsigned int DataThree) - Allows six bytes to be written to the shield in order to perform whatever command value was passed.

 

The Library - a test program

 

To better demonstrate how the library is used, I have created a basic test program, aptly named rgbshield_test:

 

#include "rgbshield.h"
#include <Wire.h>


rgbshield RGB = rgbshield();


void setup()
{
    Serial.begin(9600);
    Wire.begin();

    while (RGB.on != 1) // Wait for shield to respond, keep setting the values till it does
    {
      RGB.setfade (0x0000); // Immediate fade
      RGB.setbrightness (0x0000); // 0% brightness level
      RGB.on = RGB.readbrightness(); // Request for brightness level
      if (RGB.message == 1 && RGB.on == 0) // If message received and dimming level = 0%, "message" is set in the I2CREAD function
      {
        RGB.message = 0;
        RGB.on = 1; // break out of loop
      }
    }

    RGB.I2CWRITE2BYTES (ADDRESS, OFFTIME_RED, 0x38); // Set off-time of red channel to 0x38 - good base value
    RGB.I2CWRITE2BYTES (ADDRESS, OFFTIME_GREEN, 0x39); // Set off-time of green channel to 0x39 - good base value
    RGB.I2CWRITE2BYTES (ADDRESS, OFFTIME_BLUE, 0x38); // Set off-time of blue channel to 0x38 - good base value
    RGB.I2CWRITE6BYTES (ADDRESS, CURRENT_RGB, 0x80, 0x80, 0x80); // Set current of red channel to 0x80 = 780mA - maximum safe current!
    RGB.setfade (0x002C); // Fade Rate between brightness levels
    RGB.setwalktime (250); // walk time between colors = (value)*0.01024 seconds = (here) ~2.5s
    RGB.setrgb (0x0555, 0x0555, 0x0555); // low level White Light - indicates initialization is finished
    RGB.setbrightness (0xFFF); //Maximum brightness means intensity levels are used directly


}


void loop()



{
    //Variables for storing color intensity reads
  unsigned int rout = 0;
  unsigned int gout = 0;
  unsigned int bout = 0;


    //Set full green
  RGB.setrgb(0x000,0xFFF,0x000);
    //Pause until green reaches desired level
  while(gout != 0xFFF)
  {
  gout = RGB.readgreen();
  }


    //Set half green half blue
  RGB.setrgb(0x000,0x800,0x800);
    //Pause until blue & green reach desired levels
  while(gout != 0x800 && bout != 0x800)
  {
  gout = RGB.readgreen();
  bout = RGB.readblue();
  }


    //Set full blue
  RGB.setrgb(0x000,0x000,0xFFF);
    //Pause until blue reaches desired level
  while(bout != 0xFFF)
  {
  bout = RGB.readblue();
  }


    //Set half blue half red
  RGB.setrgb(0x800,0x000,0x800);
    //Pause until blue and red reach desired levels
  while(rout != 0x800 && bout != 0x800)
  {
  rout = RGB.readred();
  bout = RGB.readblue();
  }


    //Set full red
  RGB.setrgb(0xFFF,0x000,0x000);
    //Pause until red reaches desired level
  while(rout != 0xFFF)
  {
  rout = RGB.readred();
  }


    //Set half red half green
  RGB.setrgb(0x800,0x800,0x000);
    //Pause until green and red reach desired levels
  while(gout != 0x800 && rout!=0x800)
  {
  gout = RGB.readgreen();
  rout = RGB.readred();
  }


}

 

Breaking down the program into its most relevant bits, we start with the initialization check for the shield. This code was adapted from Infineon's test program. As you can see, it attempts to set the brightness level to zero (i.e. turns the LEDs off), then reads back the current brightness level from the shield. It continues this process until the Arduino successfully sees the brightness set to zero at which point it knows the shield is fully responsive and ready to work:

 

while (RGB.on != 1) // Wait for shield to respond, keep setting the values till it does
    {
      RGB.setfade (0x0000); // Immediate fade
      RGB.setbrightness (0x0000); // 0% brightness level
      RGB.on = RGB.readbrightness(); // Request for brightness level
      if (RGB.message == 1 && RGB.on == 0) // If message received and dimming level = 0%, "message" is set in the I2CREAD function
      {
        RGB.message = 0;
        RGB.on = 1; // break out of loop
      }
    }

 

Next, we set some of the board's electrical and timing values. A deeper discussion of just what these do follows, but the values given here are good and safe base choices. I chose to leave these functions unimplemented in the library, because they aren't things that should be played with by the uninitiated. They're still easily accessible by using the I2CWRITE commands implemented in the library, but are not readily apparent to a user who hasn't spent some time digging into the workings of the board:

 

    RGB.I2CWRITE2BYTES (ADDRESS, OFFTIME_RED, 0x38); // Set off-time of red channel to 0x38 - good base value
    RGB.I2CWRITE2BYTES (ADDRESS, OFFTIME_GREEN, 0x39); // Set off-time of green channel to 0x39 - good base value
    RGB.I2CWRITE2BYTES (ADDRESS, OFFTIME_BLUE, 0x38); // Set off-time of blue channel to 0x38 - good base value
    RGB.I2CWRITE6BYTES (ADDRESS, CURRENT_RGB, 0x80, 0x80, 0x80); // Set current of red channel to 0x80 = 780mA - maximum safe current!

 

Finally, we have the main loop and its color changes. This basic pattern is repeated a few times, but essentially what it does is tell the board to set certain rgb intensity values, then continuously reads the actual intensity values until the desired level is reached before moving on to the next color change.

 

You could get the same behavior as this test program by replacing the while loop with a delay(2500) statement, and while that is simpler conceptually, it introduces additional problems if you decide to change your walktime value to anything other than 250. Say, for example, you changed walktime to 300 because you wanted slower changes. If you used the delay() method, you would then have to modify every delay() statement or else your color changes would run over each other. Instead of getting to full-green before starting the switch to full-red, you'd get about 70% of the way there, then immediately start transitioning from that color to full-red.

 

That may seem like a small hassle, but consider a less simple program: You use an input of some kind (whether a button, a rotary encoder, or some web-based input) to modify the walktime value to create different patterns. You would then have to use a variable as your delay value, and have that variable change in proportion to your walktime. It's certainly possible, but your simple solution has now become markedly more difficult, and that's still a relatively simple use case.

 

With this method, the problem works itself out. Walktime changed to 100? Ok! No problem! Oh, now it's 500? Wow, that's slow, but sure, we can do that... no other changes needed. Have I sold you on this method yet? Good!

 

    //Set full green
  RGB.setrgb(0x000,0xFFF,0x000);
    //Pause until green reaches desired level
  while(gout != 0xFFF)
  {
  gout = RGB.readgreen();
  }

 

Now... lets see how that program looks, shall we?

 

 

What you see here is everything going from a fully powered off state to the initialization check, then the very dim white light indicating the initialization has succeeded, and then on into the program itself for a few loops.

 

Now that you know how to use my library to control the Infineon shield, let's go into a few of those technical details I glossed over earlier. You can, of course, feel free to skip this section and simply use the commands discussed above. But we're hackers here, we care about more than just making it work, we care about knowing how it works.

 

Technical Nitty Gritty

 

The following commands aren't specifically implemented in my library. They're still accessible through use of the I2CWRITE2BYTES function, however, and can be accessed by using I2CWRITE2BYTES(ADDRESS, [command listed below], [value you want set]).

 

CURRENT_[COLOR]

 

This is the first of the "electrical and timing values" I mentioned before. Using this command, you can set the maximum current per given color channel (which are obviously red, green, or blue). It's normally something you would set in your setup() section, as shown in the test program, and then leave. There may be situations where you'd want to modify this during board operation... but I can't think of any offhand.

 

This command accepts a numerical value in the range of 0 to 128. Feeding it any value over 128 will just result in the setting being changed to 128, so you can't accidentally blow out your board with a funny setting. This maximum value also, unsurprisingly, corresponds to the maximum safe current for the board. Nine times out of ten you'll just set this to 0x80 (or 128) and leave it be.

 

OFFTIME_[COLOR]

 

This is the second, and more potentially dangerous, of the "electrical and timing values". The control circuit on the Infineon board uses a chopper style of pulse width modulation in order to achieve the required current for a given intensity level. This command sets the off-time of the chopper circuit.

 

To get a better understanding of what this means, picture a graph of the current flowing through your LEDs - because of the way circuits like this work, it won't actually be a straight line. Instead, it will be a series of peaks and valleys, because the power source is being constantly turned on and off ("chopped") in order to maintain an average correct level of current. By using this command to change the off-time value, we're either making those valleys wider or thinner, and in the process producing more or less ripple in the output current.

 

Because of propagation delays inherent in this kind of control, as well as delays introduced by components in use on the board, the peak level of current experienced by the LEDs and the driver board will always be slightly higher than the maximum we set with the previous command. That is, the board will sense that it has hit the maximum current value a short time after that value has actually been reached, and in the meantime the current has continued to go up, so by the time the chopper circuit goes into "off" mode we've already exceeded our desired maximum current.

 

The hardware can take this, briefly, but if we set the off-time to a value that's too short we can exceed that safety margin. And that's how you get catastrophic failure.

 

The default value here is 0x40 (or 64), and that's probably a good value to stick with. It results in an off-time of 1 microsecond. If you REALLY want to change it, the manual has equations you can use to try to estimate what is (and isn't) going to be a safe value when combined with your maximum current setting. But so far, the ripple with the default values seems low enough that I can't see its effects. Like the peak current setting, this is also a per-color setting, and something you'll usually handle in your setup() function.

 

Additional Commands

 

There are additional commands available for the Infineon RGB shield that are unimplemented in my library and which are actually inaccessible without creating additional functions. These are all very advanced commands, however, which allow you to do things like write directly to registers on the board (rather than reading commands stored in given registers and using them to set values), change the address of the board from the default 0x15EUL to something of your choosing (which would only ever be useful if you have multiple boards connected to a single Arduino), or save the current state of all settings on the board so it will produce the same output even without an Arduino or other microcontroller attached.

 

These are all very useful things in certain circumstances, and are all quite well documented in Infineon's manual for this board, but were things that I felt were best left out of my library. Because I'm releasing my library as public domain, however, you can add these in yourself if it's something you feel is necessary. If you do use my library as the basis for an expanded, improved, or otherwise optimized library of your own I would just ask that you leave mention of me in the comments of your file and link back to my original so the code can be traced back to its source should anyone ever need to.

 

Now... on to working out the IoT/Eclipse part of this project. We'll get these bright balls online yet!

Between shipping, working, and the holidays, I haven't had a chance to give my roadtest hardware a good going over... until now!

 

The Internet of Holiday Lights RoadTest involves three pieces of hardware: The venerable Arduino Uno, its cousin the Arduino Yun, and Infineon's RGB LED Arduino Shield.

 

arduino uno.jpg

 

Chances are good that if you've spent any reasonable amount of time making things in the past five years or so, you've heard of Arduinos, and have probably used the Arduino Uno. The Arduino Uno is essentially a breakout board for an ATmega328 8bit microcontroller that gives you access to 14 digital i/o lines and 6 analog input lines. Within those digital i/o lines are two pins which allow you to use I2C devices, and two pins which can be used for serial communications.

 

The one real caveat of the device is that the ATmega328 doesn't have native USB support, so communications with it is mediated by another chip (the ATmega16U2 in the latest revision of the board) acting as a USB-to-serial converter. What this means is the Uno will only ever appear as a virtual COM port to your computer.


The Arduino Uno is a long time staple of the maker toolkit, and although it lacks the clock speed or large number of i/o lines of some of the larger Arduinos, it's still quite capable and a good starting point for microcontroller based projects.


arduino yun.jpg


The Yun is a relatively new addition to the Arduino line. It was added just over a year ago, and is an Arduino Leonardo coupled with an Atheros SoC running OpenWRT (for those of you who have never hacked your router - this is a Linux derived firmware designed for embedded networking devices). This means you get the 20 digital i/o lines of a Leonardo (of which, 12 can be used for analog inputs), the native USB support of a Leonardo (which allows the board to appear as a USB HID device or virtual COM port to your computer), and a directly coupled Linux-based network interface that is both wired and wireless.


Just like the Leonardo, the Yun has the same pinout as the Uno, making it compatible with all the same sheilds you may already have bought or developed for the Uno.


Unlike the Leonardo, however, the Yun doesn't have an onboard voltage regulator. This means you can only power it from a 5v source, and exceeding that may damage the board. It also has a microSD slot, which is tied to the Atheros SoC, intended to be used to hold all your settings, served content, and additional packages for use on the web side of your Yun project.


RGB shield.jpg


The last hardware component of the roadtest is the truly unique one: Infineon's RGB LED driver sheild for Arduino. This shield, in the configuration supplied, has one power input, one data input, and one power/command data output. It also comes without any headers, so you can easily add simple male headers, or a stackable female header if you intend to use more than one shield with your Arduino.


The level of soldering skill required to assemble the board is minimal, pin headers are just about the easiest soldering project out there, but you will need a soldering iron and some solder to get the board up and running.

 

The reference manual recommends providing a higher input voltage than what your LEDs' forward voltage requirement is, but it will happily accept anywhere from 12v to 48v as the input. I haven't tested the theory that you may get normal operation by feeding it an input voltage that matches your output voltage, but other members of this roadtest have and seem to have made it work, so your mileage may vary. I'm powering my project off an old HP printer power supply that pushes 36v, so there's more than enough voltage there to run my 12v LED string.

 

One note: When looking at the silkscreen on the board, you (like me) may misread the labeling for the power input. There is a space above the power input terminals for a DMX chip and input, and the silkscreen on the board has handy labels for that input. If you try to use that label to decide which power input terminal is negative, and which is positive, you're going to wire your power in backward and the shield won't work. Luckily, Infineon was smart enough to realize their users may be quite stupid at times, so reversing the voltage input doesn't seem to damage the board.

 

RGB shield assembled.jpg

Examining the shield, you can see it fits snugly into an Arduino Uno (or otherwise compatible) pin header for control signal input. Only the I2C pins, and the ground pin, are used so the rest can safely be passed through to additional shields if your setup requires it.

 

The power input is also quite simple, if you do one better than me and actually manage to read the correct silk screened label. The output is equally simple: There is one pin for the common anode of your LED setup, then one pin each for your red, green, and blue cathodes. It can be used with RGB LED strips or collections of individual LEDs, but it can only drive one color at a time. If you're looking for individually addressable LED control you should look elsewhere.

 

The input power terminals are of the very simple press to insert friction hold type. They seem quite secure, and should be safe to rely on even without providing some sort of strain relief on the wires themselves. The output power terminals are a little more robust, they're spring tensioned friction hold terminals, and they provide a good strong hold on the wires. I was a little concerned when I first saw these, but none of the wires seem interested in coming loose even after repeated insertions.

 

The datasheet says the driver can safely deliver 700mA per color, with a peak safe value of 1 A per color line, so you've got a lot of power to work with here. In my early testing it easily lit an entire 5 meter length of LED strip light without complaint, even when asked to drive the entire roll at full white brightness.

 

There is no Arduino library available for the Infineon board yet, but the development of such a library is an ongoing project associated with this roadtest, so that will likely change soon. Infineon does provide a test program that will walk your lights through a few predetermined colors, and that program is a good resource for understanding how to interact with the board.

 

 

I'll go more into how the Infineon board works in later posts, but essentially all the Arduino has to do is perform I2C writes of the parameters you want the LEDs set to. The Infineon board does the rest. The sorts of parameters you set are the brightness fade time, the walking time for going from one color to another, and the intensity of the red, green, and blue LED channels.

 

So, for example, if you want to make the lights quickly step back and forth between red and green you would set the fade time to zero, the walk time to something very short (say, half a second) in the void setup() phase of your program, then put two items in your main loop(): one setting red to full and everything else to zero, and another setting green to full and everything else to zero.

 

That's it. No worrying about wait or millis statements to get the transition times right, no bothering with pulse width modulation to get a fade between colors, just set your parameters and you're done. I've only begun putting the board through its paces, but already it seems quite slick.

 

The Infineon board can also report back the actual current state of the LEDs it is connected to using I2C reads, giving you a fully closed control loop for your lights and opening up quite a few possibilities beyond the simple web-enabled christmas ornaments I'm currently working on.

 

...next, we'll tackle the software aspect of this roadtest, and begin work on the meat of the project itself. But that's another blog post.

I seem to be a bit behind the curve compared to other testers, my hardware hasn't shown up quite yet (tracking predicts it'll show up today, so maybe I can get it unboxed and plugged together this evening - we shall see). But that doesn't mean I've been sitting back doing nothing. There's more to my project than just electronics after all!

 

After playing with the necessary 3D design, and printing one unfortunate failure, I realized I was taking the wrong approach to wrapping a flat string of LEDs around a spherical object. A spiral pattern just wasn't going to work given the LED strip's inability to bend along its thin edge. Being the intrepid rapid prototyper that I am, I mulled it over, and decided to give longitudinal mounting a try instead.

 

Here's attempt number two, printing away:

2014-12-14 22.50.08.jpg

 

With a little bit of math, and a little more 3D modeling, I came up with a working design. Each channel is essentially made up of 11mm wide strips of a 40mm radius sphere incised into a 42mm radius sphere, that channel is then rotated 72 degrees around the center line of the sphere, and the process is repeated until there are a total of five channels. That may sound a little confusing, but the practical upshot of this you get five channels that will hold the LED strip and that are sized specifically to fit two segments of the strip (i.e. six LEDs per strip, and 30 LEDs per ornament).

 

My hope is this will give a relatively even lighting effect on the final ornament. But we will see.

 

2014-12-14 23.17.52.jpg

You can see that in addition to the incised channels, the inner sphere has five raised nubs at points 45 degrees up the arc of the sphere. These will provide additional clearance between the inner sphere and the outer shell of the ornament to make for easier mounting of the LED strips and wiring.

2014-12-15 00.53.59.jpg

Each 6 LED segment will have to be wired to its neighbors, and then each ornament will have two sets of wires coming out of it. One to hook to the supply (or the previous ornament) and one to hook to the next ornament. The holes in the top and bottom of the core will be useful for wire routing to keep the surface clear of stray wires.

 

One thing I discovered, but wasn't surprised about, is that the sticky 3M backing on the LED strips seems to be all but worthless. If there's anything it will stick effectively to, PLA plastic isn't it. I'll probably end up having to tack the strips down with hot glue or odorless silicon or something.

2014-12-15 01.01.06 small.jpg

The only thing missing from the ornament now is the outer shroud. It's mostly designed, but not quite finished, and will be printed in nylon for a nice white diffuser layer that has a nice smooth texture to it.

 

Now... if only my hardware would show up I could put it through its paces and make a glowing ball...

As I've been selected as one of the finalists in the IoT Holiday Lights road test, it's probably about time to put some firmer plans in place. My core idea is to take the readily available RGB LED strip lighting found (among other places) on Amazon and use them to construct Christmas globe-style ornaments.


This is a quick and dirty sketch of my concept:


2014-12-08 14.52.52.jpg

What you see there is a 3D printed core with LED strip lighting wrapped around it, with a 3D printed shell to fit over this core and act as a diffuser. Moving beyond the basic concept, the outer shell can relatively easily have additional words or symbols or patterns added, but that can come later.

 

Each ornament will have leads attached which can be used to daisy-chain them together in order to cover an entire tree (or as close to it as the power limitations of the driver board will allow for). These will ultimately connect back to the main driver unit, made up of the Yun and Infineon LED Shield, which will in turn connect to a local network in order to be controlled.

 

The precise mechanism of control has yet to be decided, but some ideas include the simple "RGB colorwheel with the ability to add cycling presets", the more complicated "tweet to control" interface, or the "change color in response to incoming emails/twitter messages/facebook notifications/etc" to turn the entire tree into a notification LED. One interesting option with the "tweet to control" interface is the possibility of setting up a public webcam as well as a publicly visible twitter account which will accept @messages containing hex color codes to set the LED colors in order to recreate the once popular automated christmas light house which internet users could control and watch via webcam.

 

Once the basic ornaments are completed, the more advanced control options can be explored. Lots of possibilities... this one should be fun!

Filter Blog

By date: By tag: