I'd like to point out that these so-called "Neopixels" are not a proprietary Adafruit product, but can be bought all over the web. The part name is WS2812 (6 pins) or WS2812B (4 pins) by worldsemi. (www.world-semi.com) That said, these LEDs are really amazing.
Adafruit sells products of their own design and products of someone else's design. What I really like about them is the amount of value that add to whatever it is they're selling. The libraries and tutorials they provide are pretty incredible in terms of quality and breadth. They also give a lot of support to what used to be a re-emerging hobby community, but is now also a re-emerging small start-up business community.
Max, you say that each pixel is individually addressable....but looking at your roll of them in the 3rd photo, along with your description of the Data in and Data out signals it seems to me that what happens is that you tell the first LED what colour you want, then when you tell it a different colour, it passes the previous settings on to the next LED, and so on. Is that what happens? Can you control the brightness as well as the colour (i'd imagine so....)
Very tasty goodies - as is the power adapter in photo 2. I recently ordered some SMD mounting boards from Adafruit - had I known they had these I would have ordered a bunch of them as well. Really handy.
@David: Very tasty goodies - as is the power adapter in photo 2.
My chum Brian LaGrave pointed out that you can get these power adapters all over the place, but as I said to him, I'd never seen one before and I was on the Adafruit site after selecting the power supply and I was thinking "I really could do with a ... oooh, look at that!" LOL
@David: Max, you say that each pixel is individually addressable....
Well, perhaps I should have said "Gives the appearance of being..."
Adafruit provide you with an Arduino library, so a lot of the nitty-gritty details are hidden for you.
When you are creating a Sketch that uses these NeoPixels, first you include their library. Next you declare / instantiate a string of these pixels -- let's say we name it "strip" -- using a type of function call. One of the parameters to this call is the number of the digital output pin you are using to drive this string; another parameter specifies the number of pixels in the string (say 60).
One of the things they do for you is to set up an array in memory -- in th ecase of our 60-pixel stribg, you can visualize this as an array 0-to-59 of 24-bit color fields (8-bits each for the red, green, and blue components).
Now you can use one of their functions to set the values assocaited with individual pixels. For example:
Where 'i' is an integer of variable specifying the number of the pixel in which you are interested (0 to 59, in our case) and 'c' is the 24-bit color value.
Alternatively, you can use:
strip.setPixelColor(i, r, g, b);
Where 'i' is the number of the pixel in which you are interested and 'r,' 'g,' and 'b' are 8-bit color values specifying the red, green, and blue components of that pixel.
The important thing to note is that using the strip.setPixelColor() function doesn't actually upload values to the physical strip -- it just changes the values in the array stored in your Arduino's memery. When you are ready to update the physical strip, you call the strip.show() function -- this streams (a copy of) all of the values out of the array in memory into the physical strip -- I think the way to think about this is sort of like a shift-register -- as you start shoving data in one end, it gets passed "bucket brigade style" down the strip -- but I'm not sure as to the exact mechanism.
@Max, thanks for that, makes perfect sense. I think you are right about the shift register analogy - it would seem that you can stream the data to the strip so fast that to the human eye it seems as if you're addressing each pixel. (ie you could change pixel no 32 without changing the others, and stream the new data, and it will appear as if only that one pixel has changed). Very clever, I can think of all sorts of effects you could do with these things.
Do you know how fast the data is sent? (sorry, I'm one of those irritating people who likes to know exactly how everything works....)
@Max...some simple math reveals that a 1m string of 60 pixels will be refreshed at 800000 / 24 bits / 60 pixels = 555 Hz - surely too fast for the eye to see. You'd have to get up to about 50M before you could discern any delay. Very clever.
I was messing around with these LEDs long before they were called "NeoPixels". First, the LED units are the WS2812 (or WS2812b, which is better suited to the higher current paths large strips and arrays demand). That unit consists of a 5050 SMT RGB LED combined with a WS2811 controller.
The WS2811 protocol is detailed in the datasheets as well as numerous sites (I found http://hackaday.com/2012/12/07/driving-a-ws2811-rgb-led-pixel/ to be helpful when I was getting started with it). Conceptually, it works like this: at any point after a 50 us quiet period (data line held low) a given led is ready for input. The first WS2811 in the chain reads 24 bits (8 bits each for red, green, and blue), and after that it just forwards the rest of the bits downstream. The next WS2811 does the same, and so forth, until you stop sending data (obviously extra data beyond the last LED goes nowhere).
You can search for the WS2811 datasheet and see the exact timings involved (there's both a low and a high speed mode).
Keep in mind that the AVR at 16 MHz doesn't allow a lot of overhead for data processing. I managed at one point to marry the strip with a controller... but there wasn't a lot of room to do anything else:
@Marty: I've pondered putting a small FPGA board between an Arduino (or RPi, or something else) and using it as a high-speed dedicated controller for my WS2812-based ring, matrix and strip.
Thanks for the great information -- very interesting -- and if you do use an FPGA to do this, I woudl LOVE for you to write the project up and to post it for others to peruse and ponder here on EE Times.
You should not trash your NeoPixel ring just yet. Try powering the ring and sending your data into the data-in line on the second pixel, or third, etc. There is a chance that the first pixel is damaged and not flowing the signal data to the next pixel in the chain. Other than overvoltage, I would be surprised if you managed to kill all of the pixels.
Also, part of the perceived update speed is that the pixel LED data is updated for the desired pixels before SHOW is used to update the output currents of the whole strip at one time. This allows a flicker free update because you are not seeing the changes in each pixel each time the individual pixel's data is updated.
@sdtrent: You should not trash your NeoPixel ring just yet. Try powering the ring and sending your data into the data-in line on the second pixel, or third, etc. There is a chance that the first pixel is damaged and not flowing the signal data to the next pixel in the chain.
That's actually a really good idea -- and, in fact, if that works, then it probably wouldn't be too difficult to simply replace the first pixel... thanks for the suggestion.