Problems with WS2812B LEDs / Feedback PCB design - Page 1
Forum section: electronics / projects

author: DomesticHacks
author_rank: Regular Contributor
timestamp: February 21, 2014, 08:39:26 am
content: I made a board with up to eight WS2812B RGB LEDs which can be hooked up to a USB port to control it.It uses an ATtiny85 with V-USB (using the internal oscillator at 16,5 Mhz).I control the LEDs with the light_ws2812 lib (the first version):https://github.com/cpldcpu/light_ws2812My prototype with only tree LEDs worked fine, but i used the older WS2812 LEDs.Now I got the PCB and I have problems controlling the LEDs:- When I use the light_ws2812 lib in the newest version itdoesn't work at all. All LEDs are flashing wildly or don't change the color at all.- When I use the older version of the light_ws2812 lib the LEDs are sometimes working fine, but sometimes especially the first and the last ones have problems.I read some forum posts about the WS2812B LEDs and most of the time similar problems could be solved by changing the timing since it differs from the WS2812. The second version of the light_ws2812 lib should do the trick but it doesn't work at all for my board (even when I change it's timing to the one the first version uses).That sometimes only the first LED has problems is not a strange thing since it reforms the signal (only the "on" time not the period length itself).What I've done so far, is:- Add a second decoupling cap to every LED in parallel.- Checked the signal before and after the led with a logic analyzer and the timing seems fine but the signal from the second version of the light_ws2812 lib seems a little bit more "uneven". For example after each color there is a small pause, but nothing out of spec.- Swaped out the first led which made often problems (it went better but the problem wasn't solved).So, is there anything obviously wrong with my PCB? Or had anybody else problems with this LEDs?And before somebody mentions it, yes the decoupling caps are a little bit far away from the LEDs.The reason for that is, that I wantet to have some space around the LEDs so they will fit in a narrow gap to pipe the light.Those jumpers on the LEDs are for bridging the signal when not all LEDs are soldered in.The 10µF cap (C9) is High-Cap ceramic one (in my prototype I used a electrolyte one).

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 21, 2014, 11:34:42 am
content: It sounds like a timing problem. These LEDs are very picky and need pretty accurate 400 or 800kHz data with correct length 0's and 1's.Does the library use bit banging or a hardware feature? If it uses bit banging it's important to disable all interrupts while you update the LEDs.Try put a scope on it and do a few captures.

author: DomesticHacks
author_rank: Regular Contributor
timestamp: February 21, 2014, 11:58:15 am
content: It uses bit banging and I already disable the interrupts:QuoteI can do some captures in the evening or sunday.Until now, I already did some captures with my logic analyzer and I must admit that the timings are a little bit off because this older version of the lib is for the WS2812 LEDs and for 16Mhz, not 16,5Mhz as I clocked the processor.Oddly this one works much better than the newer version of the lib which calculates the timing depending on the clockrate set in the makefile and timings exactly as they are written in the datasheet.I will post some captures when I had the time recording them.

author: miceuz
author_rank: Frequent Contributor
timestamp: February 21, 2014, 01:41:49 pm
content: Are you sure you micro does not reset when several leds light at once due to power dip? If you have a scope, look at your power supply or set up firmware to detect the reset. Another thing - try bodging a crystal, internal RC oscillator will vary in frequency with change in power voltage and temperature, that might affect timing.WS2812B are not that picky to timing once you understand how they work, this is a good resource about their internal workings:http://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/. I've spent last weekend writing a UART based driver for them for LPC1343 MCU, I've noticed, that things start going south if one pixel time is less than specified 1.25us, it's ok if it is slighly longer.Another thing - since you have a logic analyser, try sending some simple known patterns and counting bits, that might help to debug the issue.

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 21, 2014, 02:17:48 pm
content: It's been some time since I've worked with these LEDs, but from memory, they are picky on timings, in my case running 2-300 in each string. The 0's to 1's timing does allow some freedom, but the bit frequency has to be fairly exact.I did it on a PIC, and I didn't have a library, so in the end I decided to do it in assembly to have full control over the number of cycles during the updates at 800kHz.It greatly helps that they do signal shaping on the outputs, so minimal degradation once you get the timing right.Anyway, once you get the scope captures, I'm sure the root of your problems will be revealed.. try with just 0's first, then e.g. 1's and finally alternating 0's and 1's.

author: DomesticHacks
author_rank: Regular Contributor
timestamp: February 21, 2014, 02:34:11 pm
content: Quote from: miceuz on February 21, 2014, 01:41:49 pmThe controller doesn't resets. I checked it and if it would, the USB connection will be closed.I use a calibration routine for the internal oscillator since it's neccesary for the use of V-USB and as long as USB works i think it's exact enough.

author: miceuz
author_rank: Frequent Contributor
timestamp: February 21, 2014, 03:03:48 pm
content: Quote from: DomesticHacks on February 21, 2014, 02:34:11 pmThen I'd vote for a faster clock as a culprit (16.5Mhz instead of 16MHz) - check how long are the bits and try sprinkling some nops around to get them over 1.25us

author: DomesticHacks
author_rank: Regular Contributor
timestamp: February 21, 2014, 03:18:57 pm
content: I will debug a little bit more on the software side.My fear is that I doing to much debugging in the software while the hardware could be the problem.

author: jaxbird
author_rank: Frequent Contributor
timestamp: February 23, 2014, 06:28:51 pm
content: Quote from: DomesticHacks on February 21, 2014, 03:18:57 pmI still think you need to get a few scope captures to see exactly what is going on. Then compare against the recommended timings in datasheet.For the hardware, it looks OK, except, I don't think your optional solder blob connections will work, as they short the data input and output of the LEDs.

author: DomesticHacks
author_rank: Regular Contributor
timestamp: March 01, 2014, 03:28:41 pm
content: The SMD Jumpers are for disabling the LED when it isn't mounted.I did some checks with the scope and I think it's a problem with the drifting oscillator. The LEDs are warming the PCB and that causes a drift.I think I have to use a bigger ATtiny so I can use an external crystal.

author: matt79
author_rank: Newbie
timestamp: March 11, 2014, 06:16:36 am
content: Hello forum! I've got example code working to control aWS2812b LED strip. I used SPI at 15MHz to get the WS2812b to pay attention and work with the 150ns timing. Works well but I'm not savvy enough at squirrel to really get this code running efficiently.The full example code is here:https://gist.github.com/nseidle/66d8966463aabee7e6ac#file-gistfile1-txt