@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.
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.
@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.
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:
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.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.