Digitally addressable LEDs?

[shponglefan]

Yes, yet another LED thread.  I think I'm getting a little obsessed.

Anyway, I was looking at Adafruit and notice they have this product: http://www.adafruit.com/products/738

It's a digitally-addressable LED chain with built in microcontrollers.  Basically it means that each LED in the strip can be set individually without having to be wired up individually.  Apparently this just requires two digital pins to control (data and clock), plus +5V and ground.  There are some other similar products on their site, too (LED strips).

I'm wondering if this could open up a new way to light buttons.  Instead of wiring up each colour to seperate channels, it would be much cleaner to wire only a few pins to a controller.  Of course, we'd need controllers to support this first (hence my other thread about U-HID controllers & LEDBlinky).

Not sure if anyone has experimented with this?  I haven't used digitally addressable LED strips but I'm thinking it might be worth ordering to try out.

[armi0024]

Hmmm, was wondering how long this would take... we filed a provisional patent on doing this and have the controller coming soon! LEDs arrive next week.

[matsadona]

I have used addressable LED's for a while and it is very cool. However only as stand alone with external controllers, not from a PC (however the sequences are made in a program on a PC and copied to a SD card).
The protocol is quite simple, so making a serial interface and a driver for the MAME frontend shouldn't be that hard.
Perhaps the current LED interfaces are fast enough to have two of the outputs acting as Clock and Data pins?

[RandyT]

Not sure if anyone has experimented with this?  I haven't used digitally addressable LED strips but I'm thinking it might be worth ordering to try out.

These have been out for quite a while, and I have toyed with the idea, but there are some things about them that I couldn't get past.  If you want to see a good example of them being used in arcade buttons,  this talented guy wired up 61 of these to Sanwa-style arcade buttons back in late 2011 and made a musical instrument out of them (which he plays pretty darned well!).  Be sure to check out the videos and images showing how he built them into the buttons.

The main drawback with these is bulk.  There are some "naked" modules which get the size of the module down, but the the wiring has to be pretty heavy.  With the power running in series, the wires have to be large enough to carry the current for the entire strand, so 20ga wires are the norm.  As these are a "pass-thru" setup, that's the equivalent of 8 20ga wires connected to each module.  Even with the 20 gauge wire, it is recommended to feed each chain of 25 with it's own power feed to prevent the resistance in the wiring from "browning out" the leds on the far side of the chain.  And, of course, there's the "ground chain" effect.  When one module, or wire connection, has a problem, it takes down everything beyond it until it is repaired or replaced. 

But all of that aside, it's a pretty cheap approach, especially if you already have an Arduino kicking around.

[armi0024]

Guessing people will be surprised! The technology has changed quite a bit in the last 2 years allowing for this to be done in a very compact manor.

The distinct advantage of these is to be able to swap components out in the middle or add more leds onto the end without needing to run new wiring all the way back to the controller.

I will try to take pictures of the new controller board this weekend.   LEDs will be in shortly. 

The idea of chains of 25 is an interesting one considering they sell chains of these with 30 leds per meter.  I'm pretty sure the limit of 25 has been solved.  However, there are other limits to the number of LEDs that you can do in a single chain, we will elaborate on those issues later.

[Nephasth]

Guessing people will be surprised! The technology has changed quite a bit in the last 2 years allowing for this to be done in a very I will try to take pictures of the new controller board this weekend.   LEDs will be in shortly. 

 

[kahlid74]

I love adafruit, so much great tinkering stuff.  Dimensionally I would probably have to cut the LEDS and string them together on my own.

Complicated but a cool idea.

[RandyT]

The newer units have the difference that they have embedded the micro into an SMD5050 package and use the NRZ communication protocol, which uses an implied clock, or a specific timeframe for data sequences, which allows for the CLOCK line to be omitted, leaving 6 of the heavier gauge wires.  The limitation imposed with this type of protocol is run length, as framerate is a by-product of the number of devices in the chain.  There can also be "bit-drift' , as there is no external clock available for data synchronization.  But with reasonable numbers of devices and a controller which can put out very accurate timing, they should do the job.

The only ways around the power issues are to A: use large gauge wires to reduce the resistance, or B: to provide power directly to smaller segments of chains.  Devices at the far end of longer chains will still work without doing this, so long as the voltage threshold of the micro is met, but there would be a brightness change in the LED.  The word "law" in Ohm's Law is there for a reason

[armi0024]

I think these are great points... no other vendors should work on a controller like this, it's futile, completely futile.  Let us take the fall and prove the several months of development and testing can not pan out.

On a serious note, we have been working on this for many months and been through a few iterations based on available chips etc.  We actually had an early board ready to go in Febuary but decided to use a better option of chips and control.  Testing was done on chains longer than those mentioned above and I think people will be quite happy with the outcome.  There are limitations but not those described, and we will get into more detail later.  One of the nice parts is that we also have a small adapter that will allow for the use of older style LED lights from us or our competitors.

Another interesting possibility that we will work on is that wiring can be massively reduced using this new technique.  Because a common ground can be used to each button, you can wire a complte control panel with 3 wires daisy chained and then 1 single signal wire running to each button for input.  That would allow not only LED control, but also would allow a usb adapter connection also.  We are VERY EXCITED about how this can massively reduce the burden of building wiring harnesses (Nephasth is going to need to find something else to do with all his free time!) and make lighting control panels simplified so anyone can do it easily.

Now I have to run to Home Depot and pick up some good ol' 12 gauge for the daisy chain... I think most builders will find it easy to work with the 12 gauge and triphasic power converter required to run our leds   *** Please note, we can not be held responsible for modifications made to your house wiring ***

[BobA]

This is what I love about this hobby.   Just when you think it is slowing down something new is developed to make things even better.   A  to our suppliers who never sit still.

[Nephasth]

(Nephasth is going to need to find something else to do with all his free time!)

I'm open to suggestions.

[RandyT]

I think these are great points... no other vendors should work on a controller like this, it's futile, completely futile.  Let us take the fall and prove the several months of development and testing can not pan out.

Of course, I never stated any of this.  As this is a general discussion about these devices, in the context of DIY, I'm not sure why this is becoming about your upcoming product.

Are there technical details amiss in my description of the workings, or specifications of the WS2811 5050 LED?  Feel free to add to the discussion, so perhaps folks interested in "rolling their own" will know what is involved when/if they decide to use these parts.

[armi0024]

(Nephasth is going to need to find something else to do with all his free time!)

I'm open to suggestions.

Build more machines of course.

The question was
"Not sure if anyone has experimented with this?  I haven't used digitally addressable LED strips but I'm thinking it might be worth ordering to try out."
The answer is, yes we have, great idea, we have products arriving next week that will allow this to be done with our controller or an arduino board.  It is feasible, you can order some and work your own form factor or wait a week or so and we'll have some in stock for testing.

To contribute to the fact aspect of the discussion:

1) Chainable leds can present a problem with loss in voltage so make sure to select an appropriate wire and as discussed in other forums, try to keep the RGB led count below 500 per string and select your wire ga based on published standards for amperage.  Remember these leds can draw a max of 20 mA per color, and each RGB LED will draw a max of 60 mA, there is a negligible amount of loss in the controller.

2) If you need to calculate resistance for loss in a wire, you are either A) using to many LEDs (see the 500 note above) or B) using to small a wire (see the reference to using ga tables to select a wire)

3) As far as "bit drift" this is an issue if you do not control your clock speed well, so make sure you use a quality controller, or use an indexable led with a clock connection.  Several libraries are available for both.  Controlling clock rates is key to good performance.

4)  Don't believe me... just look at what people are doing in other areas:

Oh and the part about not working on it... I said that, based on the myriad of issues in dealing with these things that have been raised.  And I would strongly encourage any other vendors to heed the technical difficulties of this daunting task.

[RandyT]

Deja Vu

1) Chainable leds can present a problem with loss in voltage so make sure to select an appropriate wire and as discussed in other forums, try to keep the RGB led count below 500 per string and select your wire ga based on published standards for amperage.  Remember these leds can draw a max of 20 mA per color, and each RGB LED will draw a max of 60 mA, there is a negligible amount of loss in the controller.

And this is why I brought this up as part of the discussion.  If someone was crazy enough to try to drive 500 per string, the total amount of possible current draw would be 30 amps!  For chassis wiring, meaning very short overall lengths of wire, 14ga (basically an extension cord) is recommended by the charts.  For longer lengths, you end up looking at the "power transmission" recommendations, which kicks that up to something considerably heavier.  For this reason, folks should should probably never try something like this.  The video shown uses 16 data channels to keep the speed up (due to the cascading protocol method I indicated earlier), and provides each strip it's own power connection to divide out the requirements.  Nonetheless, those are very impressive little boards shown in the video.

3) As far as "bit drift" this is an issue if you do not control your clock speed well, so make sure you use a quality controller, or use an indexable led with a clock connection.  Several libraries are available for both.  Controlling clock rates is key to good performance.

The thing which is going to be important here is making sure that the clock source is reliable (crystal oscillators, no funky built-in RC or resonators) and fast, interrupt driven code.  But as there are libraries for that last part, that's been taken care of if one uses the platform they were written for.

[MonMotha]

As a little technical detail, you can probably rig up the UART/USART on most MCUs to generate the single wire comm protocol (it's actually an RZ type, not NRZ) needed for this.  You'll have to do some bit massaging in software - basically each UART data "byte" will represent one or maybe two bits of data, but the timing would be extremely accurate (limited only by the accuracy of your MCU's peripheral clock), and you can run it at crazy high speeds (you'll probably be limited by signal integrity on the chain) with relatively little CPU overhead compared to bit-banging it.

Some SPI controllers may also be usable.

The protocol is actually somewhat similar to that used on the N64/Gamecube.

[shponglefan]

Hmmm, was wondering how long this would take... we filed a provisional patent on doing this and have the controller coming soon! LEDs arrive next week.

I'm very intrigued to see what've come up with!  And not a little surprised to here you guys have been already working with this.  In fact, I recall from one of your other posts hinting at a new LED solution, so I guess this was it! 

[shponglefan]

These have been out for quite a while, and I have toyed with the idea, but there are some things about them that I couldn't get past.  If you want to see a good example of them being used in arcade buttons,  this talented guy wired up 61 of these to Sanwa-style arcade buttons back in late 2011 and made a musical instrument out of them (which he plays pretty darned well!).  Be sure to check out the videos and images showing how he built them into the buttons.

Wow that's awesome!  I love it when arcade parts meet musical instruments. 

[matsadona]

Hm... wasn't the initial discussion about lighting up the buttons on an arcade CP with addressable LED's instead of a lot of parallel outputs from a a LEDWIZ or similar?
Then the discussion drifted away about 30 Amp current and heavy wires and so on...
Addressable LED's doesn't have to be on a 5m strip. If you keep the current 5mm RGB LEDs and just add a couple of WS2081 circuits and just a data and clk wires between the WS's it shouldn't be that different.

But of course, it would be cool to have the CP buttons synchronized with the t-mold being back lit with an addressable LED strip 


By the way, I have been building stuff with the WS2812 chips, which is both the controller and the RGB LED in the same capsule and that is quite cool and opens up for convenient installations.

[RandyT]

Hm... wasn't the initial discussion about lighting up the buttons on an arcade CP with addressable LED's instead of a lot of parallel outputs from a a LEDWIZ or similar?
Then the discussion drifted away about 30 Amp current and heavy wires and so on...

Addressable LED's doesn't have to be on a 5m strip. If you keep the current 5mm RGB LEDs and just add a couple of WS2081 circuits and just a data and clk wires between the WS's it shouldn't be that different.

Considering that the difference in the parts being discussed (daisy-chain configuration) is the way the power is carried, it was appropriate .  But you are correct in that there is no reason why you would need to chain the power and ground.  The ideal configuration, in order to keep the current handling requirements of any wires and connectors to a minimum, would be to individually power several small chains, with each of those chains interconnected with the data line(s).

Of course, the LED-Wiz, Pac-drive, etc are different types of devices, which allow for much higher current handling, and control of other types of devices, as well as LEDs.

[armi0024]

I'm sorry, the statement of 500 leds on a single chain was a bit sarcastic, but I think that was lost on current company.
It was, in part, in line with a triphasic power supply.  However, let's run with it to show why the initial question of indexed leds is a great idea.  For concerned party members, I will only include current products available and will keep this as a roll your own discussion. 

One needs to remember that 500 RGB leds requiring 30 amps (and that is 30 amps at 5V, or 150 Watts, equivalent to the power of a bright incandescent light bulb) is 1500 single color leds.
So on 2 arcade switching power supplies (each will supply 5v at 15 amps, and only set you back $50), powering multiple chains of LEDS, one can run 500 RGB LEDS on a machine.  Even the ridiculous numbers are possible.  This is the advantage of the indexed leds, they open up a huge amount of space for creativity and application.  Other devices and controls can also be integrated but we can get to that later.

Let's contrast 500 leds on current devices vs. 500 indexed leds.
Currently the most cost effictive LED device is the PAC64 at  .92 per output (The LEDwiz is 1.40 per output).  To light 1500 leds by the PAC64 would be 24 devices and cost 1406 (to use the LEDwiz it would be 47 devices and cost 2112 dollars)  That is just for the controller boards.  Let's just assume LED cost is a wash and equivalent between old and new because the reality is the cost of LEDs is about the same.
Now the wiring if we assume that each LED requires 3 wires to control and that one wire can be daisy chained to sets of 25 RGB LEDS we are looking at 1500 + 20 wires running from controllers to LEDs, plus 480 daisy chain links.  If each wire to an led is 1m and each wire between leds is 10cm then we are talking about 1568 meters of wire.

For indexed leds:
You have 1 maybe two boards, these can cost from 30-100, so let's be pessimistic as say 200 for two devices.  that will take care of all 1500 leds. 
With wiring, at 60 leds per a meter let's put 200 leds in strip form requiring 1m of wire to start each strip, thats 3 wires per strip x 1m x 4 or 12meters.  If we break the rest down to 21 led chains (to handle power requirements etc) that's 15 chains, each requiring 3 1m wires to start the chain and then 10cm daisy chains between.  So 15 x 3 x 1m + 285 x .1m x3 = 130.5m

So to run 500 RGB leds with current systems (controlling each pixel) you are looking at least 24 devices with 1400 in cost vs 2 devices with 200 in cost (or 47 and 2100 in cost for the more expensive option), and 1568 meters of wiring vs. 140 meters of wire

So in answer to the question, has anyone done this, the answer is yes.
Answering the question of whether there is an advantage, yes.
Answering the question about feasibility of ridiculous numbers of leds on the current or old methods, answered.

To bring this down to regular numbers, let's just take a 4 player control panel and we will leave out the cabinet leds. Say 12 buttons and a joystick per player, so 13 leds x 4 or 52 leds.  156 controlled lines requires 3 Pac64's or 5 LEDwiz.
Cost and wiring with current methods is 180 (PAC64) - 225 (LEDWiz) and 163 meters of wire instead of 100 or less for a controller board and 18m of wire.

[RandyT]

And there are disadvantages;

High speed data lines which EM or RF noise can disrupt
Limited to low current devices without extra addressable boosters
Limited to only devices which are addressable, without extra addressable hardware
Requires setting the states of each LED/device where multiples of LEDs/devices are linked in use/purpose (e.g. 15 LED's under a trackball)
Loss of function for all devices in the chain beyond a device which fails

So yes, there are advantages, but there are tradeoffs for those advantages.  The best approach will be based on the installation/expectations of the builder.

[armi0024]

To clarify
This is not true:
"Requires setting the states of each LED/device where multiples of LEDs/devices are linked in use/purpose (e.g. 15 LED's under a trackball)"
You can actually split the signal going out to multiple leds and they will all work the at the same data point.  Beyond that, even if you decided to set each one, that's the advantage, you can do this without loosing significant amounts of data out lines.  To run 15 rgb leds under a trackball independently you would require 2 LEDWiz controllers, to do it with indexable leds, you need 1 data out pin off your controller, a power line and a ground line.  What's being lost in this comment is that with the current way of thinking, having multiple leds under individual control burns capability, with the new way of approaching, your capability is greater and controlling many leds is no longer the limitation.  This is kind of like saying, Horses won't be able to handle 60 miles per hour on the highway so we should restrict cars to slower speeds, we don't have to design within the limitations of horses anymore.

"High speed data lines which EM or RF noise can disrupt"
Like usb? It is possible but this is also an issue with the whole computer system idea.  Not to mention, we haven't seen this issue.

"Loss of function for all devices in the chain beyond a device which fails"
This really depends on how the device fails but yes if an led goes bad you will have to replace it.  So you can either swap it with one at the end of the chain (which is easy because these are addressable so components can easily be moved or added).  Alternatively, with the money saved in buying 90% less wire, you can stash a few extra in your cabinet

"Limited to low current devices without extra addressable boosters
Limited to only devices which are addressable, without extra addressable hardware"
These are actually true.  However, there is a massive push for indexable devices.  Also we are talking about a board that is a chip and two headers, a $1-$2 part to adapt the signal to existing hardware.

I don't have anything against the current methods of lighting, but technology has moved on an allows for much more simple solutions.  There are several disadvantages to the existing hardware that builders and vendors worked around.  Even the two basic current controllers available now are different in their approaches and there are disadvantages between the two.

My bias is clear, we've been developing this for 6 months.  We have not had any EM or RF problems.  We've designed components to allow for high current device control, like a switchable joystick.... We have created small adapters so you can use this on your existing installations.  We have boards with multiple leds that can all show up as the same data point, or multiple data points.  Finally we have been testing these and found no increased rates of failure when compared to conventional systems.  Even if you "roll your own" it's less expensive, less wiring, and more versatile.

I think the key thing is the expectation of the builder, from the start of this thread and the comments here as well as elsewhere people are looking for new solutions to the ones currently available.  As I stated earlier, I don't think this is a good idea of any other vendors, it's futile an frought with issues.  Let the crazy people go off and do this thing.

[Nephasth]

And there are disadvantages;

Requires setting the states of each LED/device where multiples of LEDs/devices are linked in use/purpose (e.g. 15 LED's under a trackball)

Have you used LEDBlinky before? You can set multiple LEDs that aren't wired together to act as one. So this particular "disadvantage" is a non-issue. I've got 3 RGB LEDs, wired separately on my PACLED64s, lighting each dustwasher on the Beast, and each set of 3 acts as one. A few minutes configuring these LEDs in LEDBlinky (which you HAVE to do anyway if the LEDs are wired together or not) doesn't qualify as a disadvantage.

You're quick to shoot down something new, you did pretty much the same thing when the PACLED64 came out. And after well over a year of using the PACLED64 for lighting my buttons, it does the same job as an LED-Wiz would (in this particular application) with less hardware and fewer dollars. Is the LED-Wiz capable of more than a PACLED64? Yes, that's why I'm using one to control my cabinet lighting. But if this new controller was out when I was doing my cabinet lighting I would have went with it. Why? Because of the cost savings Bryan mentioned. When all is said and done, I only need a piece of hardware to do its intended task when it's installed. I don't need that same piece of hardware to be able to do something else that I'll never ask it to do after it is in my machine, because when the build is done, it's time to enjoy the fruits of the labor. So naturally, I'll be looking for what will do exactly what I need that has least amount of impact on my project's budget.

Looking forward to the new controller Bryan!

[shponglefan]

Out of curiosity, if one was to do multiple individual chains (i.e. one for P1 buttons, one for P2, trackball, etc), would two channels be required (clock + data) for each?  Or could the clock channel be shared amongst all the LEDs?

Although I suppose that would probably run into the same issue of both clock + data shared for all LEDs anyway.

[Nephasth]

You would be able to daisy chain link all of your LEDs together as long as your total quantity of LEDs was within the maximum number allowed. It's no different than cutting a strip and wiring the pieces back together.

Edit: "Daisy chain" was a poor choice of wording as it implies wiring in parallel. The LEDs I have been looking at have an "in" and "out" side for the data/clock.

[armi0024]

I would run individual clock lines to each strip as it would be more reliable, but I can see situations where jumping would be fine.  Alternatively  you can just go with a chip that has an internal clock and only requires data.

As far as the number of LEDs, there are some limitations to that both physically and based on software.  With custom software and multiple controllers the sky is the limit.  However, LED blink limits to 512 leds (168 RGB leds, and 8 single color ones)

[RandyT]

You can actually split the signal going out to multiple leds and they will all work the at the same data point.  Beyond that, even if you decided to set each one, that's the advantage, you can do this without loosing significant amounts of data out lines.  To run 15 rgb leds under a trackball independently you would require 2 LEDWiz controllers...

There's little practical use for individually addressing the leds under a trackball, so that comparison is a bit moot.  But a conventional controller also has the ability to use higher current devices, wire things in serial configurations where it makes sense, use devices of higher voltages, etc... and can light all 15 of those LED's with one command from virtually any software, from a single output.

Like usb? It is possible but this is also an issue with the whole computer system idea.  Not to mention, we haven't seen this issue.

USB uses a shielded cable, which these don't, and it doesn't have a large quantity of open wire connecting points, which these do.  Very different situation.  Also, you don't see EM and RF issues until you see them.  They are hard to get past once you do.  I can provide a link to a post from a user of a matrixed input controller (also susceptible to interference) who was having issues for this same reason, and was unable to resolve them.  Sources of EM/RF are monitors, power supplies, wireless devices, high voltage lighting, etc... So long as all of these things play nice, it's not a problem, but when they don't, it's a troubleshooting pain in the nether regions.

Even the two basic current controllers available now are different in their approaches and there are disadvantages between the two.

There are advantages and disadvantages to any approach.  Nothing is 100% ideal for every situation.

Even if you "roll your own" it's less expensive, less wiring, and more versatile.

Again, it depends on many factors.  There is nothing more reliable than a direct connection that does not rely on everything in a chain of parts functioning properly.  There are a lot of "critical" components in control applications, perhaps not related specifically to RGB lighting of arcade controls, where this type of arrangement certainly does not fit the bill.  But less expensive for basic RGB lighting applications?  Absolutely!  How does one compete with a $19 Teensy 3.0 board which can drive 1000 33 cent RGB pixel LED modules?  You'll find no argument from me there.

Have you used LEDBlinky before? You can set multiple LEDs that aren't wired together to act as one. So this particular "disadvantage" is a non-issue. I've got 3 RGB LEDs, wired separately on my PACLED64s, lighting each dustwasher on the Beast, and each set of 3 acts as one. A few minutes configuring these LEDs in LEDBlinky (which you HAVE to do anyway if the LEDs are wired together or not) doesn't qualify as a disadvantage.

As great a piece of software LED-Blinky is, not everyone uses it.  And you still have to do it even if you only do it once when configuring software which takes care of it for you afterward.  It is something that an LED-Wiz or Pac-Drive does not require.  Those two types of controllers can also run devices in series where it is beneficial to do so, can uses devices of varying voltages, higher currents directly, etc...

You're quick to shoot down something new, you did pretty much the same thing when the PACLED64 came out.

I said the same things I am saying now.  Different devices have different strengths.  This is something which apparently became clear to you when you found it necessary to purchase the LED-Wiz.

[armi0024]

My eyes have been opened, clearly this approach is inferior.  I will again urge no one else to do this. 

Since history would suggest it is never possible to have the last word, I will end my comments with this.  The disadvantages and "concerns" listed here are a stretch.  I am not going to argue specific points because the responses are in part false.  Several other communities are using these systems with great success.  If you want a fair representation of issues and problems people are having, just search the internet.

I'm really excited about the stuff we have coming out.  I think people will enjoy it.  I will start a product thread shortly for further discussion but I just can't do the pointless back and forth with Randy, ruins my days. Cheers everyone, I'll watch but I'm out of the conversation.

Ironically, I'm going to go see if any of the 20 or so CRT arcade monitors I have sitting here work...

[Nephasth]

Different devices have different strengths. This is something which apparently became clear to you when you found it necessary to purchase the LED-Wiz.

When it comes to lighting controls, LED-Wiz < PACLED64. I knew what each board was capable of before I purchased either. But it was nice nabbing an LED-Wiz for $15 shipped, well over a 66% discount. I'd have a serious problem dropping $45 +shipping on a device to control 8 clusters of LEDs. You know my stance on this Randy, price per output.

Break it down, Beast style...

To control 38 RGB LEDs and 4 single color LEDs requires 118 outputs.

• 2 PACLED64s supply a total of 128 outputs. At $118 for 2 boards, that comes to $0.92 per output.
• 4 LED-Wizs supply a total of 128 outputs. At $224.75 for 4 boards, that comes to $1.76 per output.

I saved $106.75 by using the PACLED64s, and my controls light up EXACTLY the same as they would have if I used LED-Wizs instead. Saving that amount of money allowed me to make the machine nicer in other areas that I originally didn't plan on.

[RandyT]

....but I just can't do the pointless back and forth with Randy, ruins my days. Cheers everyone, I'll watch but I'm out of the conversation.

That doesn't seem necessary.  I have stated that there are distinct advantages and disadvantages to doing RGB lighting with these kinds of parts, and have pointed out advantages in the current methods, in response to your highlighting their disadvantages.  And I even managed to do it without calling your character into question, or specifically "pimping" my products.

These little Chinese wonders are a great step forward for a lot of applications, but they are not the "be all and end all" for every installation, nor should they be expected to be.  The parts were designed to do what they do, and they seem to do it very well.  But one can't tout the advantages of one method, while completely ignoring the advantages of the other.  It's not realistic, and it's not a fair way to conduct a technical discussion.

When it comes to lighting controls, LED-Wiz < PACLED64. I knew what each board was capable of before I purchased either. But it was nice nabbing an LED-Wiz for $15 shipped, well over a 66% discount. I'd have a serious problem dropping $45 +shipping on a device to control 8 clusters of LEDs. You know my stance on this Randy, price per output.

Did you buy it from a relative?  You've probably made quite few people here jealous to have scooped one for that price.  That's almost less than our parts cost.   But yes, I know your thoughts on the subject very well.  If you recall when urging me to essentially "knock off" the design of that product, my response was that the capabilities of the LED-Wiz went beyond that design in a number of aspects, and that some applications would be better served by the alternatives.  You may not have needed those capabilities for everything on your project, but I'm glad it worked for you when you did.

[Nephasth]

Did you buy it from a relative?  You've probably made quite few people here jealous to have scooped one for that price.  That's almost less than our parts cost.

Got lucky by watching the B/S/T forum.

[matsadona]

I truly believe there is a market for addressable LED's in the BYOAC world, but there are of course pros and cons.
So it is with the current products as well, so some will stick with the old, some will go with the new and some will mix.

Personally I think a device with 16-32 outputs and one or two serial output as well controlled from the same software would be the ultimate thing.
And with some clever firmware hacking, wouldn't it be possible to do that with the current hardware, assuming that the current AVR/microcontroller used at the interface has the speed for that protocol?

[RandyT]

Personally I think a device with 16-32 outputs and one or two serial output as well controlled from the same software would be the ultimate thing.
And with some clever firmware hacking, wouldn't it be possible to do that with the current hardware, assuming that the current AVR/microcontroller used at the interface has the speed for that protocol?

The speed requirements for the protocol make it tough for the mc to do a lot of extra work outside of the actual communication.  At least one clever person was able to use an 8mhz AVR, but it involved some non-conventional approaches.  The one thing that is pretty cool about the WS2811 is that it has a "low speed" mode, which can help a bit (it's half of the default speed) so using devices set up for that can allow for some breathing room.  The major issue with that is that most resellers of the strips don't even seem to know how they are configured, so compatibility with the full speed strips is a requirement, unless you are building your own LED parts (or can modify them). 

Monmotha made some interesting observations about using the serial hardware of the controller, and I have seen it discussed, but most of the folks who have been successful are "bit banging" the protocol.  The ARM chip on the Teensy 3.0 has DMA, so it seems to be a lot better suited to the task.  The ideal solution for adding this type of functionality to an existing product/architecture, in my mind, would be to have a separate interface chip.  I'm a little surprised, given the speed requirements of these things, that the manufacturer hasn't offered a $2 solution.  I expect that will be coming in the near future, and when it does, it won't be a challenge to put support for them in anything.  Until then, fast processors with dedicated built in hardware, or "roll your own" interface chips, are the order of the day.

[RandyT]

Just as an addition to this thread, I thought would show what I was able to do with the WS2811 parts just a few hours after I got the string in the mail.  This is a simple technology demo, running on a fast little board I designed and built a while ago for this type of functionality, among other purposes (more about that at some other point...software is still being worked on).  This uses a conventional approach, utilizing machine code to regulate the timing.  Not the most efficient use of the MCU resources, but it gets the job done.  There are 59 LEDs in the string, all controlled individually.

Please excuse the cell phone video.  I turned the strip away from the camera, and used a white backdrop, to better show the colors being produced.  It's very difficult to shoot good video of light sources without proper exposure controls.

[armi0024]

Please continue the discussion but as promised I have started a thread.
http://forum.arcadecontrols.com/index.php/topic,132533.0.html

[armi0024]

More discussion on the new thread, but here's an example of our LEDs and one of our controllers:

[carl125]

I recently ordered the same ws2801 pixels.  I planned on using that mini controller to control basic rgb colors instead of buying an Arduino chip (mistake number 1?). The main question that I have is ,is it possible for me to use that inline controller with those 12mm pixels? I tried to correctly assemble the controller and pixels to my 4.8 (battery) power supply ,but my mini controller started to spark and smoke O.O. Thank goodness the pixels were safe (or apprear to be XD). Maybe I hooked them up wrong?

[matsadona]

Normally this isn't hard to do, since it is 3 or 4 wires:
+ DC
Data
(clock/sync)
Ground

What makes it hard sometimes is that the LED strips or pixel strings might have everything but logical connections, in terms of color coding etc. At some models the red wire i +DC, at some others it is Data etc. Some strips have 4 wires, but 2 of them might be combined ground. I think you get the picture.
So you really need to examine the wires before connecting the power source, since you can never presume the color coding is was it should be (from a logical and standard perspective).

[thagerty]

Old thread, but thought I would add to it in case anyone is looking for ideas.

I just installed addressable LEDS in my virtual pinball cabinet, and boy I would LOVE to see LEDBlinky be able to support them. It would be amazing to be use these strips with arcade and pc games!

Here's some pics and a video to show what it looks like. A game changer for pinball as it offers animations and effects that are triggered by the pinball table itself (via DOF software and Visual Pinball)

The controller I'm using for the addressable LEDS is a Teensy. I also use LED-Wiz to control the other normal RGB LED strips, solenoids, beacon, strobes, and other toys in the cabinet. My control panel LEDS are NOT controlled and just connected to a switch.



















Video demo in Pinball X:

[Nephasth]

Old thread, but thought I would add to it in case anyone is looking for ideas.

I just installed addressable LEDS in my virtual pinball cabinet, and boy I would LOVE to see LEDBlinky be able to support them. It would be amazing to be use these strips with arcade and pc games!

Here's some pics and a video to show what it looks like. A game changer for pinball as it offers animations and effects that are triggered by the pinball table itself (via DOF software and Visual Pinball)

The controller I'm using for the addressable LEDS is a Teensy. I also use LED-Wiz to control the other normal RGB LED strips, solenoids, beacon, strobes, and other toys in the cabinet. My control panel LEDS are NOT controlled and just connected to a switch.



















Video demo in Pinball X:

Could you tell us one more time? Exactly like the last times please.