Hi to all,
I bought a few months ago these LED strips Christmas LED Strip
which they say has the “SK6812” chip, but up to now I have managed to drive them without problems with a commercial controller by setting the LED type as WS2812; the commercial controller I’m talking about is this one: LED Adressable Controller
I created myself a PCB based on ESP8266 (specifically on the ESP-12F model; the PCB works perfectly with all the WS2812 strips I currently have at home, and even with the WS2813. Obviously, but I took it for granted, on the ESP8266 I flashed WLED.
Wanting to put everything I have at home under the WLED system, I thought about also bringing these Christmas lights with my PCB, but unfortunately they don’t work. As you can see in the video I attach, if I set SK6812 RGBW in the Led Preferences the strip does not respond at all to the commands, instead setting WS2812 RGBW (even if the ones I have are not RGBW but only RGB) the strip perceives the commands but behaves in strange way.
In the video I am setting the fixed colors i.e. “solid” Red, Green, Purple and White, finally I raise and lower the brightness. Ok, whatever modification I impose in the program you notice a moment of 1-2 seconds in which the strip “goes crazy” and then in any case it doesn’t show the desired colors.
I repeat with a commercial controller by setting WS2812 the strips are driven without problems.
How can we solve it???
This is my LED PREFERENCES
I am going to guess that it is an issue with the board you created. To rule that out I would test with a regular mass produced 8266 or esp32. It looks like a data problem to me. You could try a level shifter.
Normally those fairy lights are WS28xx.
I have had weird issues with the non coated fairy lights from BTF but they worked on the 8266 and not on an esp32.
Hi, i have just used a logic level traslator from 3.3v to 5v for the data. I use most used in these projects the 74LVC1G125.
Now i try with e Nodemcu, but It seems strange to me that my pcb doesn’t work since for all WS2812 strips it works perfectly.
However i’ll try.
Do you have any other ideas? I read on the web that many with WLED have problems with SK6812, even if these lights of mine say they are called SK6812, but in reality with the commercial controller they are only driven as WS2812.
EDIT : I tried connecting the LEDs to the Nodemcu and noticed that they worked. At this point I thought the problem was the logic level shifter because from the nodemcu I had directly connected the data to pin D4 and it worked so I bypassed the PCB and it works. So it means that these LEDs don’t want a 5V translator… but on a 7-8m long chain I wonder how the 3.3 signal can reach the end… oh well it’s true that they are strips with 10 LEDs/m but however after 70-80leds the 3.3V signal should drop a little but instead it seems like they only work like this…really strange also because with other WS2812 strips the 5V converter is essential…boh
The recommended level shifter is the SN74AHCT125N not the 74LVC1G125. I did not look too deeply into it but I think the 74LVC1G125 is for 5v down to 3.3 and not the other way around. I could be wrong… Either way it’s not recommended.
*with the level shifter you also need the 100nF Ceramic Capacitor. (See Link above)
The data only has to make it to the first pixel. That pixel repeats the data to the next at 5v. Each pixel sends the data down the line boosted to 5v.
I would definitely look at the levelshifter, especially if you can get a display without it.
Do you have a 100nf bypass capacitor on the Vcc pin of your levelshifter?
Your LEDs most certainly “want” a 5V data signal, it’s just possible that they will work with less (maybe).
As far as worrying about the signal degrading over multiple LEDs (down to the end of the string) - there is no “voltage Drop” to worry about on the data line.
There is very little current required for the data line (<5mA) so any drop due to cable resistance is negligible.
Each LED in the string regenerates the data stream back up to their Vcc level so every LED emits a clean 5V data stream.
The only issue is in the distance from the MCU (and/or the levelshifter) to the first LED. After that everything is just passed on forward.
Hi, I used the 74LVC1G125DBV because I had seen it used in an online project and it worked.
This is my logic level shifter schematic. Yes i have put a capacitor 100nF on the supply of level converter
Actually looking at the datasheet it should be fine because its input is between -0.5 and 6.5V max so if powered at 5V an input signal of 3.3 comes out at 5V.
In fact all common WS2812 LED strips (like these
) work perfectly.
The problem is that these LEDs (
) don’t behave quite like other WS2812 LED strips. I don’t know if the commercial controller has a level shifter at the output or if it throws out the signal at 3.3V, but empirically I have proven that on my board these work if the data is thrown at 3.3V; could it be that the commercial controller (which 99% has an ESP8266 on board) throws the DATA signal at 3.3V?
In your opinion, a distance of 2.5m from the controller with a 0.75m2 cable could lead to a significant drop in the DATA signal at 3.3V?
In your opinion, a distance of 2.5m from the controller with a 0.75m2 cable could lead to a significant drop in the DATA signal at 3.3V?
There is no voltage drop in a data signal, at all.
The size of wire used for the data signal is mostly irrelevant. As I mentioned before, there is no current to worry about and that is what causes voltage drop - current over larger distances.
What can happen is the data stream can get corrupted as the waveform distorts because of cable capacitance, noise, etc.
If you’ve verified that particular shifter actually outputs Lo for 0V in and High for 3.3V in (try and do it manually with no lights attached), try moving the 8266 very close to the strip to see if you’re getting cable noise. You might also try running a separate ground and data line from the 8266 directly to the strip. Don’t use your original line, add a new one using some a pair of light wires such as CAT5e, etc.
Exactly that’s exactly what I did, I took a cable directly from GPIO2 to the DATA line of my LEDs and so they work, they work directly with the 3.3V of the ESP8266 output.
Except I tried it with a very short 5-6cm cable very close to the ESP8266.
Tonight perhaps I should try bringing the signal from the GPIO02 to the LED using a 3m cable so I will actually have empirical proof whether it can work without disturbances at 3.3V.
If this were the case I could remove U4 (the level shifter) and short-circuit the Bypass (I had already thought of the possibility of bringing the signal directly from pin 02 to 3.3V in the design phase if needed)
Did you try your very short cable with the levelshifter?
2.5m is not normally a long data distance (perhaps getting close?), but you could consider a TxRx differential pair for your data line as well. See Long Data Lines in the KB.
If they work at 3.3v and they don’t work when using your shifter, I would try using a recommended shifter from the KB and not one that you ‘think’ works.
I just noticed something on your schematic for the levelshifter and (what I can see) your live PCB.
Where does pin 1 of U4 go?
That’s the ~OE line of that shifter IC.
If you’re going to short the bypass, you’ll have to raise that pin to Vcc to disable the output.
If you want “normal” operation, it must go to Gnd.
In general, I agree that chip will be fine as a proper levelshifter, it’s just a single “channel” of a 4 channel 74AHCT125.
As you can see, pin 1 of the level shifter has the OE signal that goes to the node connected to the drain of the Q2 mosfet, but it is practically as if it were directly at GND because I inserted the Q2 mosfet to drive the switching on and off from the WLED (through the Relay setting in the WLED app) effective 5V of the strips in order to power them and de-power them as I wish (because if I lowered the brightness of the LEDs to 0 they would still consume a little, in this way instead by cutting the 5V the their consumption when I turn off WLED from the app leaving it powered however it is 0 and the only one that continues to consume is only the ESP8266).
As I was saying above, either the strips are powered and therefore the OE signal (i.e. pin1 of the level shifter) goes to GND or the strips are off and therefore the OE signal does nothing.
But I repeat, on all the other WS2812 strips my board works perfectly, it’s only on these LED particulates that I’m having trouble.
Finally last night as a bypass I directly removed the level shifter from the PCB, connected the short-circuited one to the bypass test point. Even in this way, however, I noticed that the 330R resistor in series on the DATA causes problems, I saw the signal and at low brightness of the LEDs the voltmeter reads a signal at 18mV while if I raise the brightness of the LEDs the signal reaches 400mV, probably These specific LEDs have something strange because even the voltage that generates the signal seems strange to me.
The ESP8266 should output the DATA at 3.3V while if I connect these LEDs the DATA goes to the voltages expressed above
Ok, I understand where you’re going with the OE line on your shifter.
It sounds OK in theory, but reality may be different?
I keep repeating this, but it’s important:
A data stream might not reach the level needed to trigger an LED reliably, but that’s not because of resistance and current and Ohm’s law. The voltage drop that requires power injection and bigger wires and power supplies is a completely different problem than what causes corrupted data flicker (or no display at all).
Measuring the GPIO out with a voltmeter won’t tell you anything about whether the data stream is good enough for your LEDs. And as you noted, the meter doesn’t really react fast enough to tell you much at all. When looking at the data stream LED brightness has nothing to do with voltages! The brightness of an LED is a number you send it in your data, 255 means 100% bright, 127 means 50%, 63 means 25%,etc.
You need an oscilloscope to show you the max voltage reached by a 150ns data pulse and more importantly,exactly how wide that pulse is at the max voltage. The data stream is huge number of those pulses and when they don’t match what the LED expects, bad things or (in your case) no things happen.
I would take the 330R resistor out of the data line completely, that is not helping the situation. It may be useful (although it is well over the max values I would suggest) in longish data lines, but it only adds an unneeded variable here.
In short I don’t see the “new” bead LEDs as special or strange. On the contrary, they’re reacting as most LEDs are spec’d. You may have had good results with other LEDs in the past, but that’s because those LEDs are farther out of the general design spec and/or more forgiving of your setup than the reverse.
