Building DIY BlinkM clones


If you are planning on using more than a handful of BlinkMs in a project, you will likely find that their $15 price tag quickly adds up. Instructables user [jimthree] found himself in that position and opted to create his own homebrew version of a BlinkM instead. He calls his creations “Ghetto Pixels”, and while they might not look as professional as the real thing, they get the job done just the same.

He bought a batch of RGB LEDs online for under a dollar apiece, pairing them with ATTiny45s that he scored for about $1.50 each. [imthree] popped his uCs into a programmer, flashing them with an open-source BlinkM firmware clone called CYZ_RGB. He then prototyped his circuit on some breadboard, adding the appropriate resistors to the mix before testing out the LEDs. When he was confident everything was working correctly, he assembled Ghetto Pixels deadbug-style.

When everything was said and done, they came together in a pretty compact package comparable to that of the BlinkM. As you can see in the video below, they work great too!

29 thoughts on “Building DIY BlinkM clones

  1. I am one of the authors of CYZ_RGB.

    One of the reasons the BlinkM costs what it does and the firmware is not open source is because you are paying for a patent license. Philips owns a patent on controling RGB LEDs over I2C/TwoWire. ThingM licenses this patent, and when you buy a BlinkM you are allowed to do what you want to it. Regardless of your personal feelings about this situation, I would not suggest trying to sell anything with CYZ_RGB loaded onto it in the US or any other territory where Philips patents may be valid.

    If you want to make a commercial product or do anything that enters into the territory of the various patents in this area, build it out of BlinkM’s, license the patent yourself, or use something that does not use I2C such as one of the many shift-register based products out there such as the ShiftBrite, the various LED “pixel” products, or the addressable LED light strip/chain products.

    Please see the following link for additional discussion including participation by the guy who developed the patents:

  2. I’ve been working on a project using the CYZ_RGB firmware as well. I’ve routed some nice 1 in^2 board (mostly thru-hole) which work quite well. More info: (see comments for PCB info).

    I’m also working on a RS485-networked rgb lighting controller on a much larger scale. Boards just came in, and I’ll probably have some more information up in the near future.

  3. It’s fucking ridiculous that you can take General Standard Protocol A, combine it with General GPIO or General PWM idea 1, and get a patent for it.

    Can I patent a generic ethernet tcp/ip to RGB setup?
    Can I patent a generic usb to RGB setup?
    Can I patent a generic wifi to RGB setup?

    This is like a company trying to patent making a left hand turn in a car, if it is done by a drive-by-wire system instead of a mechanical linkage.

    These basic 1 + 1 patents should last for like 5 or less years, at most. I2C RGB control is hardly unique, even back in 2002. If you can separate the two main parts of a patent, and get two generic ideas, the combination should not be considered non-obvious and unique.

  4. Very cool project! Like many of the posters here I am pretty distressed by the idea that something as basic as using product A (RGB LED node) and product B (commonly called a “wire”) together for their design purpose is patentable. Although the patent holder (discussion linked in the article) claims it only covers I2C, the first claim of the patent as-written appears to cover *any* transfer of data and power to a LED PWM device over a wire having at least two conductors. It is not even specified that the power and data, or the clock and data (etc.) have to be on separate wires. That would hypothetically include Dallas 1-Wire and potentially even my own similar dirt-cheap open source RGB bus (2005). Mine uses a self-clocking protocol in which a single wire bears the data and the clock is arguably generated at the microcontroller end. (Not for any patent-related reasons; the PIC10F200 micro I used only had 1 I/O pin left over.) Although I’m sure patent lawyers would spend the next 10 years arguing over the definition of “clock” and whether a clock signal is “transmitted” in a self-clocking protocol (does Morse Code include a clock signal?) At least his patents do not mention any concept of group addressing until the 2006 continuation (mine had this “reduced to practice” a year earlier), or a log-table at the PWM end to linearize apparent brightness, so maybe those ideas are safe for now (at least from this guy…).

  5. About the patent issue people here are discussing: The I2C bus has been developed by Philips, and obviously patented by them. Philips allows licence-free implementation of the I2C bus, but an official slave-address still needs to be bought from them.

    And since Philips is a company which started off as a light-bulb producer around 100 years ago, and still has a mayor lighting division, it’s not strange that they have patented the use of I2C for lighting control. At the time of invention of I2C this was probably innovative enough for a patent.

    No, I’ve got no Philips shares, but a company which has been at the basis of the lighting industry and the inventor of I2C has in my eyes the full right to combine these two and to get a reward for their R&D work in the form of a license fee.

  6. @flip – the led was patentable. Discussing that is a red herring.

    An obvious method of controlling a led should not be patentable. I2C is in widespread use anything using it should not itself be a patent.

    If I understand it, you’re saying if YOU invent something (say, a new tech light source), and andI have the right to patent an obvious configuration… Then I could deny you use of (or demand payment for) each time you use your invention…?

    Now if there were a reason I2C were impossible for a led peripheral, and a solution was discovered… That should be patentable. But it would be an Patent specific to overcoming an operational environment issue. That’s not what this is.

    The patent holder claims he is not interested in going after small designers, but will not flatly exempt Open Hardware, so ThingM needs his permission/license.

    This is an excellent example of patent abuse… And it will never stop getting worse until the patent office actually enforces the anti-perjury rule with regard to documenting prior art.

  7. Well I certainly didn’t mean to start a holy war on patents. I just wanted to point out that one exists that covers this use case and to advise experimenters as to it’s status in respect to BlinkM and CYZ_RGB. In the area of RGB LED control it’s unfortunately simply wise to tread carefully. As I am in part responsible for CYZ_RGB, my own opinion on the matter ought to be somewhat obvious. But I would also never be foolish enough to disregard or disrespect any patent regardless of my personal opinion as to its validity or “obviousness.”

    Instead of ranting and raving — which is really the normal state of things on most public forums, we as hacker/tinkerer community ought to instead see the challenge of developing a different solution that simply eliminates the problem of the patent in the first place.

    It’s important to remember that although they express an “idea,” patents actually document an implementation. Let’s take a wire hanger for example: the first guy who patented a wire hanger filed a document that likely said “here is my design for a wire hanger; here is the manufacturing process, type of wire, etc.” It also probably said something to the effect of “The wire can be bent other ways too!” But you know what? There are plenty of patents for other wire hangers bent into all kinds of goofy shapes.

    So although this particular patent in question does state that the controlling microcontroller can be substituted with something else, the bus could use a different protocol than I2C, the LED could be a different style, or the driver ASIC could be something else it can’t really succeed in wholesale coverage of an implementation that is markedly different than the one shown in the patent. This should be the challenge we face in this situation: do something different and do it better.

    As I had said initially, I’d advise anyone who wants to do anything serious to use either centralized LED control or a shift register and latch based design instead. The design is easier, the hardware is cheaper, and it is a different enough approach that it does not infringe on the patent in question. (Although I do not know if there are any others on which it might.) I2C is a really terrible design choice for this application anyway. It requires an undue amount of hardware and effort to grow the size of the network, and there is little to no ability to recover from errors. It’s easy and fun to experiment with but not much fun to make bulletproof. I should know!

  8. @John Laur –

    Wouldn’t using I2C to talk to a shift register which controls the LED still be a patent violation?

    Is it possible to design an LED node which is compatible with I2C protocol, while staying clear of the LED+I2C patent?

    I understand your desire to avoid being peripherally involved in a “holy war” against an obvious patent, but there is no point in diminishing the value of I2C. It is the most widely implemented standard for input or output devices. Error correction is hardly needed in blinking glass blocks or holiday string lights.

    Rolling your own implementation defeats the point of a standard.

  9. Looking at the patent abstract, I noticed the following:

    “Each illumination device has at least three light emitting diodes (LEDs). The LEDs each emit light at a different wavelength than either of the other LEDs.”

    Read that carefully.

    I’m sure you’ll agree that if you’re I2C controlling only one LED/color, or even two LEDs/colors, you’re not infringing on this patent. After all, it says “at least three”, right?

    What if you go to four LEDs, each individually controlled on a separate channel? But make the fourth LED the same color as one of the others. Then the LEDs don’t “each emit light at a different wavelength than either of the other LEDs”, do they? No patent infringement.

    Of course, this would be silly for a mass manufacturer of Christmas lights to do, and they’d probably be better off paying the licensing fees; which are typically *much* cheaper per unit when a large number of units are produced.

    But what about the small guy running a home business who sells only a few dozen or hundred units per year?

    John Laur said, “One of the reasons the BlinkM costs what it does and the firmware is not open source is because you are paying for a patent license.”

    Apparently licensing only a small number of units costs enough that it’s a significant factor in the price. Plus, it’s preventing the release of source code.

    If you can dodge this ridiculous and restrictive patent by using one extra LED and pin on the MCU, and adding maybe $0.20 to the cost; I say it’s fair game, and go for it.

  10. I didnt suggest using I2C to talk to a shift register; most of the implementations like the shiftbrite just use something like three GPIO’s directly as clk data and latch. It’s fantastically simpler. 95% of the things I have seen built with BlinkMs could have been done using shift register based products as well. The other 5% were using the standalone/script functions of the BlinkM which by being standalone is de facto non-infringing to the patent in question. Likewise most of the problems I have heard about with BlinkM and/or CYZ_RGB are I2C related. The bus is great for chip-to-chip comms on a PCB; nobody’s arguing that, but It takes a lot of care to stretch it out over wires to great distances and complex topology. Just because you *can* do it doesnt always mean it’s a great idea.

    I would suggest that anyone actually needing to interface a whole bunch of LED lighting over a shared-bus network just cut to the chase and use DMX512 anyway. It’s exactly what it was designed for, it’s robust; it’s a totally open and well established standard; it’s well understood; and there are lots of products already implementing it.

    @Chris: I’m not sure a technicality like you describe would be enough. And I am not privy to the economics of the BlinkM, though I suspect the patent fee is not hugely significant.

  11. @Chris: Unfortunately, the title/abstract/description mean approximately nothing when testing a patent for infringement. Only the Claims section matters. Starting at the top-level claims (which are intentionally as general as possible), if your implementation contains ALL the elements of any top-level claim (or that plus any dependent claim), it infringes the patent as-written*. If it is missing even one element of the top-level independent claims (i.e. those that don’t begin with “The claims in Claim X where…”), it does not infringe. Again, since the top-level claims are so generic (e.g. “has a wire to provide power”), a well-written top-level claim covers almost all sensical implementations :(

    That said, I appreciate using a standard and I see a few possible ways around the 2002 patent if you want to still use I2C and the hardware PWM that comes on 99% of microcontrollers. The patent is oddly specific with regard to the wire: it specifies a wire/cable that is flexible and has a “first end and a second end” (read: two or more ends). You can dodge this by using a nonflexible substrate (PCB? Steel rods?) for the bus, or by making the wire have less than two ends. For example, if you make the wire bus in the form of a ring (no free ends) and simply tap the LED nodes AND controller in at various points along the ring using IDC connectors or similar, you’re good to go. Wastes you the costs of some redundant wire though. In fact, these oddly-specific qualifiers may be to get around some prior art that uses a continuous wire loop or solid substrate (probably PCB) to buss multiple addressable LED nodes.

    You could also perform a Dallas 1-Wire like scheme (power+clock+data on one wire) using a nonflexible or non-wire medium as the ground return (car body, Earth, etc.). This keeps you below 2 conductors on the flexible wire part, another part of the top-level claims.

    Looking at the patent again, I doubt my open-source Blinkenlichten design (mentioned above) infringes the patent. Obviously, it gives up the benefit of a standard like I2C in favor of my own made-up self-clocking protocol though. It would be arguable (maybe hard to argue, at that) that my data bus includes a clock at all, as the transition timing can vary on a bit-to-bit basis and is completely unimportant. Also, the design technically does not use PWM (the PIC10 has no hardware PWM registers anyway) but software-implemented PDM (Pulse Density Modulation) – basically a varying number of ‘1’s are rotated around a buffer, and the topmost byte’s carry-out bit at any moment determines the LED state. The ‘1’s need not be (and aren’t) consecutive, so the pulse width is completely unimportant, only the ratio of 1s to 0s. A similar approach could probably be used in an I2C LED project to evade the patent.

    *The vague top-level claims rarely survive a proper examination / prior art search, so a suitably deep-pocketed rival could probably knock them down a peg. But getting a patent reexamined is a whole different and pricey kettle of fish…

  12. @Tim: Thanks for the explanation about the primary claims.

    I did look further into them. It appears that all the LEDs being different colors is in the primary claim. Even better, so is this:

    “an optical diffuser enclosing at least a portion of the first, second, and third LEDs”

    This appears not to refer to the LEDs’ epoxy case, but a separate plastic diffuser over the LEDs; like the diffuser used to imitate the appearance of a traditional incandescent bulb as depicted in the drawings.

    The BlinkM doesn’t contain a diffuser. From what I can tell, it also doesn’t include a cable, flexible or otherwise. Both of those are something the end-user would have to add. So the BlinkM itself doesn’t seem to infringe at all.

    That said, I do agree that I2C isn’t so great over long distances, especially if you want a decent data rate. I have run it through a detachable 15′ CAT5 cable, with power over the same cable, and requirements for supplemental ESD protection at both connectors. The signal degradation was more than I anticipated. I did finally get it to work at an acceptable data rate, but it required pull-up currents way past spec, via constant current sources instead of resistors.

    Still, the ability to use I2C or whatever else one chooses, without encumbrance, is what’s important.

  13. @Chris: Where did you see that? In the ‘825 patent, the independent (top-level) claims are #1 and #13. None of them mentions a diffuser.

    You do have a good point though; the flexible, 2+ conductor cord IS a required part of both independent claims and is supplied by the user. It would be a pretty straightforward argument that BlinkM’s (or any similar) commercial product not only does not infringe as-sold, but is usable noninfringingly by the end-user (projects like a “Wall of LEDs” where the electrical signals are on different layers of chicken wire, or wearable LEDs with multilayer conductive fabric).

    General comment: I don’t know where people are getting that Philips has an I2C LED lighting patent. Philips has a patent on the I2C protocol itself, which it developed (and any micro with hardware I2C already includes a patent license for it); these LED-related patents appeared to be owned by “some guy” (Carpenter Decorating Co., Inc.).

  14. Nevermind, I found the diffuser part in the 2006 ‘337 patent. Looks like he dropped the “flexible” and “multiple ended” parts about the wire for this one and just calls it a “substrate” of at least two conductors in which a clock and data signal can be sent. Its last independent claim drops the diffuser part too. How any of these would still be patentable in 2006 (postdating BlinkM and presumably wire-having projects that used it; my own 2005 project was partly intended as a dirt-cheapest BlinkM alternative) is beyond my comprehension.

    I can say that specific dependent claims in the 2006 patent would not stand up to re-examination; specifically Claim 6 (addresses “common to” two or more LEDs at a time, e.g. group addressing), which my project did a year earlier than the filing date (yay CVS datestamps). Some of the remaining dependent claims are just plain confusing, e.g. the stuff about the RGB PWM registers a separate “brightness” register (PWM-ing the PWM?).

    “Luckily”, both explicitly mention “PWM registers” in all of their independent claims, so I’m pretty sure using PDM (pulse density modulation) instead would avoid infringing either of these patents. Unfortunately no common microcontrollers I know of have a hardware module for this, but it can be done in software/interrupt in only a few clock cycles (see the example on the Blinkenlichten page).

  15. @Tim: The diffuser is in claim #1 of 7,327,337. I hadn’t fully read 7,015,825, but I have now and you’re correct.

    I also didn’t notice that claim #13 in ‘337 was independent. And it’s far more general, as it seems to cover *any* IC that accepts data, clock, and power, and is intended to drive RGB LEDs using PWM. It doesn’t mention any other components of a working system, including the controller, cable, LEDs, or diffuser.

    There’s many ICs out there designed for exactly that (the OnSemi NCP5623T just to pick an example), which would appear to infringe on this claim, even before they are installed in a working system.

    So that makes me wonder:

    1) Is this so vague as to be completely unenforceable?

    2) Or has the patent owner chosen not to enforce it, leaving it now practically unenforceable because of the widespread level of infringement?

    3) Or is OnSemi (and others) current paying licensing fees? In which case, if you were to sell a module using one of these ICs, wouldn’t separate licensing be unnecessary; because the fees are already rolled into the price of the IC?

  16. @Chris: I’m not a patent attorney (just an engineer who has to write and/or dodge one from time to time), so take this as educated guesses:

    1,2) “Enforceable” is a tricky word; if enforcement means they send a nastygram to a small developer and s/he decides to pay a license rather than fight, then yes. But like I said earlier, it’s uncommon for the broad top-level claims to survive a proper prior art search by an actually interested party (not the half-assed search by the patenter or patent office). As I mentioned, I myself can prove prior art on claims in the ‘337 patent, so I would guess there is a whole lot more of it floating around out there. (The dependent claims are a hedge against this; prior art will have the effect of narrowing or nuking individual claims, not nuking the patent outright.)

    2) A patent holder (unlike say a trademark holder) is free to pick and choose who they enforce the patent against. They may choose not to assert it against someone if they stand a good chance of getting their patent narrowed or rejected in the process. Case in point, Oracle recently tangled with Google over some Java patents, and in the process 17 out of 21 claims have been rejected upon reexamination.

    But choosing not to enforce it against party X doesn’t affect their ability to assert against party Y, even if X and Y have an identical product.

    3) Beyond my expertise, sorry! It MAY be the case (some datasheets may even have a blurb, e.g. “Purchase of this product conveys a license to use… (I2C, etc.)”; check with the vendor to be sure though.)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s