I’m currently attempting to get a WS2814A strip working with Pixelblaze. Currently unsuccessfully.
I’m not sure I understand these comments entirely - will that strip inly work with an Output Expander? And it needs to have its firmware modified?
Hi @esben,
Yes, the WS2814 color order that we’ve seen is supported by recent versions of Pixelblaze (V3.40) and the output expander when used with the new versions. The output expander does not need any updates, just the Pixelblaze.
Can you post some more details on your connection, power, etc., and what you’ve tried?
Hi @wizard,
Thanks for your quick reply!
Okay, that’s great - exactly what i’d hoped for when buying a pb.
Just out of curiosity, does that mean that the output expander with “standard” esp board such as a wemos d1 would also support it?
In therms of hardware, I’m powering the strip with a 320W 12V psu.
The actual strip is a bit of a novelty though - I need a number of weather proof, diffused LED tubes with 360deg viewing angle. So I had a local company that works with LED fixtures make them custom for me. Trouble is, they’re more of a DMX/Same-color-LED-company, so they’re not too helpful in terms of support. It seems they mostly made them in the blind, not even able to test the end product.
For some reason, the chose the WS2814A protocol (don’t know if there’s actual differences with WS2814?) and solved the requirements by sliding two strips back-to-back into a silicon tube and enclosing it in an acrylic tube. I have w 5-lead wire (red, white, green, blue, black), and they tell me red and white is 12v+, blue and green is 12v- and black is shared data. Due to the construction, I cant see it for myself though, and i wouldn’t be all too surprised if they have wired it wrong internally. Or soldered the wires to the output end or something like that.
I have tried various neopixel and FastLED configurations on an arduino UNO with no result whatsoever.
Then I tried protocols WS281x, SK6812 and TM1814 on WLED on a Wemos. This also did not work, although I did in all fairness also not use a logic level shifter here.
Then I have tried all (I think) combinations on the pixelblaze.
I have not, however, tried the pixelblaze with an output expander! So this is the first thing I will do tomorrow.
Do I just select Output Expander as LED type on the PixelBlaze settings, and then select the correct color order?
If it’s not working on the Pixelblaze, I don’t think you will have more luck with the output expander, the protocol they generate is the same. It won’t hurt anything but is more complicated than trying it with a Pixelblaze alone.
More details on expander setup here:
https://electromage.com/docs/output-expander
You will need to power Pixelblaze with 5V, and tie the GND (or negative) side of your power supplies together when you connect the data of the WS2814.
The WS2814 and WS2814A are pretty much the same, the A variant has a higher voltage tolerance but works the same otherwise.
You might have to disassemble one to figure out what the wiring actually is doing, connecting 12V to the wrong lines can permanently damage things.
Okay, so a couple of weeks’ summer vacation and some strongly worded emails, my supplier picked up one of the tubes and took it home to see if they could breathe life into it. Eventually, they disassembled it and found that they had indeed soldered the wires on the wrong end of the strip.
After fixing this, it works as expected.
2 Likes
Okay, I retract above message - it almost works as expected.
Using a Pixelblaze Output Expander, I’m able to run 8 WS2814A, each with between 33 and 51 pixels.
I use the esp8266 driver on an Wemos d1 mini because I need to stream the pixels from a pc to the pixels.
It works - I can eg. make a red pixel chase along the strips.
But when attempting to turn all pixels on at 255 on al channels, i noticed heavy flickering or distortion.
Strangely, if I make clean red (255,0,0,0), it works as expected. If I add full power to one more channel, it’s also mostly ok. If I add a third, it starts flickering randomly. And if I add the fourth channel, it seems to actually do it right every other time I call the driver.show function, but show randomly colored pixels on the rest.
So i’m wondering if this is an issue with the code or the wiring.
The strips are located in the next room, so wires are quite long - about 8 meters, and they are bundled in cables along with the 12vs.
Here’s setup and loop of the sample code I’m using for debugging:
//Function prototypes: (function body at bottom of program)
const int PixelSum(const uint8_t* _strips, const uint8_t _numStrips); //function to calculate the sum of elements in array
//Pixel variables:
const uint8_t strips[] = {50, 50, 50, 50, 48, 48, 33, 51}; //Array of strips with their pixel count
const uint8_t totalStrips = sizeof(strips); //Amount of strips
const int totalPixels = PixelSum(strips, totalStrips); //Total amount of pixels
//Buffer size is number of pixels times 4 (RGBW) plus header size
const int bufferSize = totalPixels * 4 + HEADER_SIZE;
byte* buffer = new byte[bufferSize];
void setup() {
//1mbps - we need a lot of data
Serial.begin(1000000);
//Pointer array for PBChannel structs(basicly LED-strip objects)
std::unique_ptr<std::vector<PBChannel>> channels(new std::vector<PBChannel>(totalStrips));
//Updating variable values in the PBChannel structs:
int _startIndex = 0;
for (int i = 0; i < totalStrips; i++) {
(*channels)[i].channelId = i;
(*channels)[i].channelType = CHANNEL_WS2812;
(*channels)[i].numElements = 4;
(*channels)[i].redi = 1;
(*channels)[i].greeni = 2;
(*channels)[i].bluei = 3;
(*channels)[i].whitei = 0;
(*channels)[i].pixels = strips[i];
(*channels)[i].startIndex = _startIndex;
_startIndex += strips[i];
(*channels)[i].frequency = 800000;
}
//Driver configuration
driver.configureChannels(std::move(channels));
driver.begin();
//Serial connection between wemos and pixelblade expander:
Serial1.end();
//Serial1.begin(2000000L, SERIAL_8N1, -1, 10); //<--Copied from exampel code which doesn't compile
Serial1.begin(2000000, SERIAL_8N1);
}
void loop() {
driver.show(
totalPixels-51, [&](uint16_t index, uint8_t rgbv[]) {
//Logic that controls pixel colors:
//uint8_t _rgbw[4] = { 255, 0, 0 0 }; // Works perfectly
//uint8_t _rgbw[4] = { 255, 255, 0, 0 }; // Also works perfectly-ish
//uint8_t _rgbw[4] = { 255, 255, 255, 0 }; // Quite bad
uint8_t _rgbw[4] = { 255, 255, 255, 255 }; // Also very bad, though it actually works every other time
memcpy(rgbv, _rgbw, 4);
},
[&](PBChannel* ch) {
});
delay(500);
return;
}
What really confuses me is that it works perfectly well with a clean read, but seems to function worse the higher values I send. If it was an issue with distance to first pixel or wiring, wouldn’t plain red also not work? But then what could it be? Am I misunderstanding the driver.show callbacks?
Hoping @wizard or another pixel mage has an idea!
Here’s a video of how the above code with uint8_t _rgbw[4] = { 255, 255, 255, 255 } ind driver.show:
(and heres a google photos link, if video doesn’t work: https://photos.app.goo.gl/VjFiYeCm3jBFHezR6)
This sounds like a power and/or ground signal related issue that is creeping in when power draw increases. It doesn’t sound like an issue with your code.
8M is quite a long distance for this type of LED data signal. I suspect that once power draw really kicks in, the difference between the signal ground and your power ground becomes higher, and is pushing it outside of operating margins. You might get it to work better with improved ground wiring.
For distances this long, I would add in some differential transceivers, like RS422 / RS485.
If feasible for you, another working option would be to move the expander closer to the LEDs and run a long expander data line instead. Its protocol will handle communication errors much better. It can also be extended with a differential transceiver.
Some forum posts to check out:
@wizard once again, thank you for a quick reply.
I was able to reduce the length of most of the cables, and that did somewhat improve the situation.
What really helped (ridiculously 
) was plugging my laptop into power. Apparently, the wemos was slightly underpowered when the laptop was running on battery only …
2 Likes
That actually sounds more like a grounding issue to me then.
1 Like
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.