Updated FAQ #2 (markdown)

Michael Miller
2018-08-10 16:17:06 -07:00
parent 12827cc0d7
commit 7a857d0fd1

@@ -2,10 +2,10 @@
The effects you may see, but are not limited to are; the first or last pixels show incorrect colors, random flashes, or nothing.
This is due to the IO Pins on the device are 3.3v and the pixels require +-0.5v relative to their power voltage. Most pixels require 5v to run; so this puts the Pin IO out of spec. There are several solutions to this problem.
1) Make sure there isn't a 5v IO Pin on your device. A few lower voltage devices expose a compatible output pin just for this purpose. Switch to that Pin.
2) Use a level shifter in your design. [Adafruit sells one](https://www.adafruit.com/products/1875) that will work and you can find similar modules and circuits that you can incorporate. This will shift the 3.3v IO output to 5v for the pixels. Note that [Adafruit HUZZAH ESP8266](https://www.adafruit.com/product/2471) board that has built in level shifters for RDX0/GPIO3 pin is designed so that the pin is an "input"; but it is needed as an "output"; so you must use the UART method with this board.
3) Lower the running voltage to your pixels to within range of the IO pins. Since the pixels need +-0.5v IO, if the primary voltage of the NeoPixel is 3.8v, then the 3.3v of the IO pin are within spec. Some pixels can run just fine at 3.8v and this is often the lowest rated voltage they can run at. The problem with this solution is how do you provide 3.8v at the current requirements the Pixels run at? You will need to get a variable power module and with a good meter you will need to set the voltage output to 3.8v. A lot more effort than just getting a level shifter.
For this reason I don't suggest this solution except for the bench testing.
1) Make sure there isn't a 5v IO Pin on your device. A few lower voltage devices expose a compatible output pin just for this purpose. Switch to that Pin if you can, but release the esp8266 methods use very restricted set of pins. Note that [Adafruit HUZZAH ESP8266](https://www.adafruit.com/product/2471) board that has built in level shifters for RDX0/GPIO3 pin is designed so that the pin is an "input"; but it is needed as an "output"; so you must use the UART method with this board.
2) Use a level shifter in your design. [Adafruit sells one](https://www.adafruit.com/products/1875) that will work and you can find similar modules and circuits that you can incorporate. This will shift the 3.3v IO output to 5v for the pixels. See [Issue #183](https://github.com/Makuna/NeoPixelBus/issues/184) for details on making it work. Note that [Adafruit HUZZAH ESP8266](https://www.adafruit.com/product/2471) board that has built in level shifters for RDX0/GPIO3 pin is designed so that the pin is an "input"; but it is needed as an "output"; so you must use the UART method with this board.
3) Lower the running voltage to your pixels to within range of the IO pins. Since the pixels need +-0.5v IO, if the primary voltage of the NeoPixel is 3.8v, then the 3.3v of the IO pin are within spec. Some pixels can run just fine at 3.8v and this is often the lowest rated voltage they can run at. The problem with this solution is how do you provide 3.8v at the current requirements the Pixels run at? You will need to get a variable power module and with a good meter you will need to set the voltage output to 3.8v. A lot more effort than just getting a level shifter.
For this reason I don't suggest this solution except for the bench testing.
----
The acceptable driving voltage of pixels depends on the chip. The above voltages may be correct for some pixels, but others differ. For example, with the WS2811, the specified thresholds are >= 0.7 * VDD for high, and <= 0.3 * VDD for low. Using 5V pixels, that's above 3.5v for 1 and below 1.5v for 0. As you can see, a 3.3v uC can put out a 0 easily, but is out of spec for a 1. Luckily, the pixels often work a bit beyond spec anyway, at least if the pixel is close to the uC, but sometimes the pixels don't work reliably (other chips will have their own specified, and actual, thresholds; the actual thresholds may vary by batch even within the same pixel chip type).