OctoWS2811, Bug in library or hardware fault.

Status
Not open for further replies.

johnnyfp

Well-known member

What's going on on 1st line?

All I'm running is the Basic Octo library example with a new stripe routine, IE to iterate through the columns instead of rows.

So the Column stripe works fine I don't get any corruption on line one, But if I run the ColorWipe example the first line corrupts.

I've also tried the Plasma and Video example, and row one always corrupts (and in the plasma example row 4 also corrupts).

My circuit is a Teensy3.1 connected through a LVC4245A Voltage level buffer, 3v3v on input and 5v on output.

I've got 135Ohm resisters on the output, and have attempted to change that on channel 1 down to 82Ohms with no effect. There is also a Bypass cap on the buffer to help it.

Another experiment I've tried is just to put a dot on each pixel, and what I observed was that if the any colour was above 0x2F it would not light up later on on line 1 and 4. But the others where fine.

Any Ideas?
 
If you swap wires around, does the error follow the LED strip, or the output pin?
 
So I swap the line and it works fine.
I then connected a croc clip to the wire to a multimeter probe to then put it on the LED strip to see if it was one of the LED's playing up with its Stream reshaping.

But what was weird was that if I touched the Multimeter probe to the first one (IE like it was soldered). It works. No more glitching. So I re soldered the wire, and the glitching comes back.
Now, If I touch the multimeter probe (not connected to anything), while the wire is soldered, the glitching goes away!. WTF?

So does this mean I need to put some capacitors on each line because some bouncing or ringing is still happening?
 
I had problems similar to what you exhibit. I suggest you consider the following:


First, I had problems with this code. Do you have a different drawBuffer and frameBuffer declared?

if (drawBuffer != frameBuffer) {
// TODO: this could be faster with DMA, especially if the
// buffers are 32 bit aligned... but does it matter?
memcpy(frameBuffer, drawBuffer, stripLen * 24);
}

Second: You may have a loop which is updating data in your drawbuffer or framebuffer too fast for the draw() update rate causing tearing.

It is not uncommon to have this type of problem occur where touching a meter or scope probe changes the impedance. Find the underlying problem causing it as the meter or scope probe is not relevant.

You'll get it.

Richard
 
post the reworked code and I /someone else can run it to see if it reproduces on a know good setup. This way the hardware /software issue quirks can be split out.
 
But what was weird was that if I touched the Multimeter probe to the first one (IE like it was soldered). It works. No more glitching. So I re soldered the wire, and the glitching comes back.
Now, If I touch the multimeter probe (not connected to anything), while the wire is soldered, the glitching goes away!. WTF?

This sounds like a signal quality problem. Your description mentions a level shifter and resistors, so if those resistors are well matched to the cables, in theory the signals should be good.

In practice, impedance mismatch causes funny ringing and other signal issues. Limiting the bandwidth slightly, like forming a low-pass filter with the 135 ohm resistor and capacitance of your multimeter, can slow the signals enough to lessen those issues.

The new OctoWS2811 adaptor board was made to help with exactly these sorts of issues. CAT6 cable is precisely controlled for 100 ohm impedance on each twisted pair, so it always matches closely to the 100 ohm resistors on the circuit board.

http://www.pjrc.com/store/octo28_adaptor.html

I know this sounds like a sales pitch, and truthfully it is. Get this $10 board. ;)

In hindsight, I should have made this adaptor a year ago. In fact, earlier I designed another much bigger one with power distribution and fuses, which looked awesome, like professional-looking industrial control modules often look. But it was entirely the wrong idea. The last thing you want to do is have the LED ground current running through the same ground wire that is the signal's ground. But that's the way most people hook these projects up, because the 3 wires run together with the LED strip, so it seems intuitive to run them together when you wire things.

Using CAT6 cable, where each signal gets its own ground, and a wiring approach where the LED power grounds are separate and meet at the LEDs, not at the Teensy, gives you the best chance of reliable signals. Well, the best chance without resorting to much more expensive ways of doing things.

I really did make this $10, not because a $10 product is going to be huge for PJRC sales-wise, but because these big LED projects are so easy to build but so hard to make really reliable. There are dozens of threads on these forums, and hundreds of old emails I've answered, with all sorts of really difficult "basically works, but flickers when..." issues, which have almost all turned out to be signal quality problems.

My hope is this adaptor will save you and everyone else a lot of grief.
 
Last edited:
The thing is that the cables are not very long at all (150mm max). And we are only talking about 800khz here, which amazes me that there's so much corruption.

What also gets me is why is it only happening on the first line but the rest are fine. Same ribbon cable goes to each row, be it a few mm shorter per wire to get a neater solder fitting.

So what would you recommend the correct method is to Impedance match a line would be then? Overall resistance? Overall Capacitance?
 
Status
Not open for further replies.
Back
Top