PartayPat:
Why does dropping the voltage down to 3V make it happy though? (I assume that's what it's doing)
Quite the opposite. It's boosting the 5V data signal up to 12V. As the only data sheet I could find is in Chinese, I can't be sure this is safe, but I left the strip running for 24hrs with no apparent ill effects.
GS1903规格书-中文资料.pdf (1.56 MB)
Thanks for this thread... I was tearing my hair out over the same issue, using and ESP8266 Wemos D1 mini. Sometimes it would work, and sometimes not. I'm guessing that noise + overshoot of the data signal would sometimes get above the threshold, so that sometimes it would work, and sometimes not.
For my contribution, here's a link to an English (probably translated from Chinese) datasheet. https://cdn-shop.adafruit.com/datasheets/WS2811.pdf
I'm not an electronics engineer, but worked with some for long enough to pick up a bit of knowledge. So take what's below with a grain of salt. Hopefully someone who knows more will contribute.
From the datasheet, it appears that the WS2811 chip supply voltage is 6-7V. Presumably there's some kind of voltage converter in the strip? And, assuming there's no similar voltage conversion on the DIN line, the threshold for the DIN line is 0.7*VDD = 4.2-4.9V.
I suspect that level-shifting the DIN up to 12V would be bad, because that would make it higher than VDD which usually kills the chip. But maybe it is level-shifted down?
I'm guessing that the best thing to do would be to use a transistor controlled by the Arduino pin, switching between 5V and 0V. I'd appreciate it if someone could post a circuit. But 5V seems perilously close to the 4.9V threshold.
Or could you use a voltage divider made up of a couple of resistors... say R1 = 10K and R2 = 8K resistors...
12V --- R1 ---+--- R2 --- Arduino output pin
|
|
DIN WS2811
When the ESP8266 pin is high, the output to the WS2811 is (12+3.3)*8/18 = 6.66V
low, (12+0)*8/18 = 5.3V
Or would that destroy the ESP8266?
OK... I've done a bit of Googling.
The WS2811 chip actually operates at 5V, so there's some step-down conversion going on in the strip. The DIN pin is also a 0-5V signal, not 0-12V. From the data sheet, the DIN threshold is 0.7*VDD = 3.5V, so a 3.3V output just doesn't quite cut it.
A MOSFET is probably the right device to switch the DIN line between 5V and GND.
Hi @franknvz. The chips on the OP's strip are not ws2811. They are gs1903. Similar idea and pinout, but not identical.
If you read the thread from the start, in particular reply #9, you will see that the OP is also in possession of some ws2811 strip and found this to work well with the 5V data signal from the Nano, but the gs1903 strip did not.
But I do share your concern that a 12V data signal might not be good for the gs1903 chips in the long term. I think it might be a good idea for the OP to experiment using a voltage divider to reduce this down to the 6~7V mentioned in one of the tables in the gs1903 data sheet.
What we really need is a forum member who can read a Chineese data sheet to help us out.
Your voltage divider idea for esp is not a good idea. You would be exposing the esp pin to 12V, which could damage it, even though there would be two resistors to limit the current.
If you are attempting to drive a genuine ws2811 strip with esp, I recently overcame that problem with help from forum member grumpy_mike. Use a 74hc14. Use two of the chip's 6 inverter gates in series, powering the chip with 5V.
PaulRB:
If you are attempting to drive a genuine ws2811 strip with esp, I recently overcame that problem with help from forum member grumpy_mike. Use a 74hc14. Use two of the chip's 6 inverter gates in series, powering the chip with 5V.
Strictly speaking, 3.3 V is running a bit close to the maximum threshold voltage, though the "typical" is quite comfortable.
A 74HCT14 would be perfect if available - this is after all, exactly what its purpose is.
OK, I have mine running now. Well, nearly. I have it working on an Arduino Uno (i.e. with 5V output).
At first it didn't work even then, just going all white and not responding to data. I verified that the software and port were working by using a 5V strip. So I figured that somewhere along the line I'd killed the first WS2811 chip in the strip. Hoping that it was only the first chip, I cut off the first 3 LEDs and soldered on a connector. Upshot is that the strip is now working. 
Probably that 470ohm resistor really is needed in the data line to protect the WS2811 as much as the Arduino.
NB: 74HCT14 is an inverting device, hence the need to use two of its gates in series. Also, that's a 14-pin chip with 6 channels... wondering if there's something smaller since I really only want one channel? e.g. would this device work? H11L1 pdf, H11L1 Description, H11L1 Datasheet, H11L1 view ::: ALLDATASHEET :::
frankvnz:
Probably that 470ohm resistor really is needed in the data line to protect the WS2811 as much as the Arduino.
OK, let's get this straight. The 470 Ohm resistor is not in any way there to protect the Arduino proper. It is not even there in case of a wiring mistake as it is to be connected in series, at the input of the LED strip.
frankvnz:
NB: 74HCT14 is an inverting device, hence the need to use two of its gates in series. Also, that's a 14-pin chip with 6 channels... wondering if there's something smaller since I really only want one channel? e.g. would this device work?
That device is an opto-coupler, not a level converter.
No, not fast enough. 
sigh
I've wired in the logic level converter as you described but the only difference is that now the first set of LEDs are flashy, then the next THREE sets are black with all subsequent ones going white. No idea why this change from one black to three black would occur.
My strip is split into lengths of 2's with connectors on each end so I can swap the order around but there is no change to this pattern, so it seems to be more general than a single faulty chip.
I've also tried it on a full uncut 5m strip to the same effect, so it also looks like it's not a connector problem.
One thing to note is that the strip with no data input is white by default which might suggest that the trailing LEDs aren't getting anything sent to them. Not sure what this says for the black ones though.
So even with one strip of 6 leds/2 chips connected, the first chip + 3 leds flash correctly, but the second chip + 3 leds are black?
Can you reproduce my circuit as close as you can to my picture & video from post #15, and post pics of your circuit?
I've noticed that the number of black leds is defined by the number of leds I define in the code.
Also one time the trailing leds were a mix of colours instead of white, but I can't seem to reproduce this.
My current code:
#include "FastLED.h"
// How many leds in your strip?
#define NUM_LEDS 4
// For led chips like Neopixels, which have a data line, ground, and power, you just
// need to define DATA_PIN. For led chipsets that are SPI based (four wires - data, clock,
// ground, and power), like the LPD8806 define both DATA_PIN and CLOCK_PIN
#define DATA_PIN 5
#define CLOCK_PIN 13
// Define the array of leds
CRGB leds[NUM_LEDS];
void setup() {
// Uncomment/edit one of the following lines for your leds arrangement.
// FastLED.addLeds<TM1803, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<TM1804, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<TM1809, DATA_PIN, RGB>(leds, NUM_LEDS);
FastLED.addLeds<WS2811, DATA_PIN, BRG>(leds, NUM_LEDS);
// FastLED.addLeds<WS2812, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<WS2812B, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<NEOPIXEL, DATA_PIN>(leds, NUM_LEDS);
// FastLED.addLeds<APA104, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<UCS1903, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<UCS1903B, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<GW6205, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<GW6205_400, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<WS2801, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<SM16716, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<LPD8806, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<P9813, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<APA102, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<DOTSTAR, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<SM16716, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<LPD8806, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<P9813, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<APA102, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<DOTSTAR, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
}
void loop() {
// Turn the LED on, then pause
leds[0] = CRGB::Red;
FastLED.show();
delay(1000);
// Now turn the LED off, then pause
leds[0] = CRGB::Blue;
FastLED.show();
delay(500);
leds[0] = CRGB::Green;
FastLED.show();
delay(200);
}
PartayPat:
I've noticed that the number of black leds is defined by the number of leds I define in the code....
#define NUM_LEDS 4
...
leds[0] = CRGB::Red;
...
leds[0] = CRGB::Blue;
...
leds[0] = CRGB::Green;
Well, yes: You have defined your strip as length 4. So 4 chips x 3 leds = 12 leds will initially be set/defaulted to black by the fastLED library. Your code only changes colour of leds[0], which affects the first chip & 3 leds. The other 3 chips & 9 leds remain black. The remaining chips never get any data at all, because the library is not aware of their existence, and default themselves to white.
That weird feeling of embarrassment and relief.
Everything seems to be working fine now.
Good to hear, well done at last!
But we still haven't resolved the question of whether a 12V data signal is a good thing for the chips in the long term. Have you got a pot you could use to do an experiment? Connect the pot between HV2 and GND with its wiper connected to the strip's data wire via the fixed resistor. Adjust the pot down until the data signal cuts off. Then adjust the pot up slowly until the data is reliably and consistently received by the strip. Once you are happy that its definitely not loosing any data, disconnect the pot from HV2 and connect to 12V instead, without disturbing the pot setting. Measure the voltage between ground and the wiper.
Paul__B:
OK, let's get this straight. The 470 Ohm resistor is not in any way there to protect the Arduino proper. It is not even there in case of a wiring mistake as it is to be connected in series, at the input of the LED strip.
OK. What is it there for then? I thought it was there as a current-limiting resistor. But I only know enough electronics to be dangerous.
That device is an opto-coupler, not a level converter.
No, not fast enough.
OK, thanks.
Getting back to the MOSFET (and my irrational wish to devise the absolutely minimal circuit to interface the ESP8266 to the WS2811)... I found this http://www.rocketnumbernine.com/2009/04/10/5v-33v-bidirectional-level-converter which apparently is what's in the I2C level-shifter boards. That page says "The resistors are only required if the lines are open-collector (not connected to GND or +V)". It seems to me (in my ignorance) that a unidirectional converter ought to be simpler. Could it be that just a single BSS138 (plus I guess the 470ohm resistor... which side of the MOSFET does that go?) would do as a level-shifter between an ESP8266 or Arduino nano and a WS2811?
frankvnz:
OK. What is it there for then? I thought it was there as a current-limiting resistor.
Yes, it sure is!
Grumpy Mike has explained in a recent post (somewhere here) that it is to limit the current in the situation where the LED strip is not powered but the Arduino is and its output is HIGH and feeding current into the data input of the LED strip.
Another situation is where the inductance in the transmission line between the two causes "ringing" on the data transitions resulting in voltages beyond the power rails. This is unlikely over a few centimetres but possible with a number of metres between the two.
Indeed, you want only a unidirectional level shifter, but the problem is you have nothing to actually pull the voltage up to the higher voltage, so you need a resistor to do that passively. This may limit the rise time so you may need a relatively low value resistor.
The FET is connected in "common gate" mode with source to your Arduino, gate to 5 V and drain to that pull-up to the strip voltage (presuming you actually do need this step-up in the first place). When the source is pulled LOW, the FET conducts and pulls the drain to that level, if the source rises to near the gate potential, it does not conduct and the pull-up is allowed to take effect.
Working LEDS "bottle bulbs" I've got 21 20cm sections wired up 1.5m apart, which surprisingly worked without having to boost the power, who knew.
Anyway, this is post party and I'm still a bit groggy. I will test the working voltage once I've untangled it from the mass of slinkys it is now connected to 
I'm hoping to get that short strip you sent me on a 'scope tomorrow. Then I can measure what range of input voltages are acceptable to the chip, and measure the voltage of the data signal coming out of the other end of the strip.
I took your strip along to my maker group yesterday. Forgot to take the 12V PSU I had been using at home. Fortunately, there was a bench power supply available, which I set to 12.0 and the circuit worked as it had at home. Hooked up the 'scope and had a look at the data waveforms. The Arduino output signal had some "ringing" but was otherwise clean looking square shaped with sharp rising and falling edges. The different pulse lengths for ones and zeroes were interesting to see.
The output of the level shifter was not pretty. The square signals had turned into a sawtooth pattern with higher peaks for ones compared to zeroes. Even the higher peaks were nowhere near the 12V level I was expecting, only reaching around 6~7V at the tips of the triangular waveforms. The output of the pot was similar, except of course that the voltage was lower depending on the pot setting.
Adjusting the pot gently upwards until the signal was fully received by the strip, the signal was only reaching 4.5~5V. This then raised the question of why the level shifter was even needed, if the strip worked with a signal of less than 5V. So I removed the level shifter and pot and connected the strip directly to the Arduino output via 330R, to see if what that signal looked like and try to figure out why it did not work without the level shifter...
Well, to my surprise and frustration, it did work. No data loss. The signal looked clean, square and sharp on the scope, at 4.8~5V. I also checked the data output of the strip. At first there was no signal. Then I remembered that the strip length was set to 2 in the sketch. Setting the strip length to 3 and re-uploading the sketch, data started to appear at the strip's output. Again, a nice square signal, 4.8-5V.
So these strips can work with a 5V data signal. I can only put my failure to get it to work like this, and the OP's difficulties, to the power supply, which was the only different component. It would have been interesting to check the signals on the 'scope using the PSU I had been using at home, to see how that looked by comparison to the signal using the bench power supply.
PaulRB:
But we still haven't resolved the question of whether a 12V data signal is a good thing for the chips in the long term.
Frankly, I cannot see what this is all about.
Both chips operate on 5 V logic. 6 V or 7 V are specified as absolute maximum. They incorporate an "active Zener" - a shunt regulator - which with the specified drive current set by the series resistor maintains 5 V (± 0.5) on Vdd. Their input logic levels are thus the same as any 5 V logic, nominally 3.5 V HIGH and the output will approximate the Vdd of 5 V. Their specification (for both) is that the logic voltage does not exceed Vdd by more than a diode drop and Vdd is always 5 V.
In fact, the only pins on the chips that ever see more than Vdd are the open-drain output current drivers - just like a TPIC6B595.
I just cannot see a cause for confusion here, it is not that hard to understand the datasheet.
A 3.3 V logic device - such as the ESP8266/ WeMOS boards - might drive them satisfactorily, but is clearly on the edge of the specifications. At the high data rates involved and if there is any suggestion of cable length, a passive pull-up level shifter will require particularly "stiff" pull-ups - basically the lowest permissible for the Arduino/ ESP8266 pins - but an active level shifter such as a 74HCT14 would be greatly preferable.