Confounding Flicker with WS2812 strips and OctoWS2811 on Teesny 3.1

[Dr.Rockzo]

Hello all,

I am hoping someone can help me figure this flicker out...i have read through similar threads but nothing suggested in them has worked for me and I am unsure how to proceed.

The basic idea of my project is to accept 32 channels of DMX (4 channels per strip, with 1 unused channel) and use them to control (8)x 1 meter sections of LED flex strip. When the DMX signal is received, the new color "wipes" or "pours" down the flex strip. I have the DMX working great (thanks to Paul for pointing me toward the library elsewhere on the forum) and the strips "wipe/pour" correctly, I can do something different on all 8 strips without issue.

BUT there is a random flicker that I cannot get rid of. It moves up and down the strip, some colors act up more than others. The really confounding thing is that when I set white at full power it works fine; red, green, and blue at full power also work fine. It seems that anything less than full on generates a flicker. I had a similar issue the the FastLED library, but it only had issues at full power and everything in the middle work fine; I wasn't able to resolve it and moved on to OctoWS2811.

At first I though it was a power thing but after checking, i see 4.9V at the front of the strip and 4.6V at the last LED; I know that's close to being out of spec, but one thing at a time. I really don't think it is power becuase it middle of the strip may flicker while the end after it is fine.

I'm not sure what all needs to be know, but here are all of the details I can think of.

My computer:
Operating System: Windows 8, 64-bit
Arduino 1.0.5 with Teensyduino 1.18-rc1

My system:
Power supply: Mean Well RS-50-5 (5V / 10A)
LED strips Adafruit 144 LED/meter WS2812b (they only have 4-pins) strips (only testing with one strip currently)
TI SN74HCT245N octal bus transceiver (for level shifting) with 100 ohm resistors inline
TI SN65HVD1786 differential bus transceiver (DMX input)
Teensy 3.1 and all other hardware currently on the bread board.

Below is all of my code (please excuse my n00bish formatting):

// library #includes
#include <OctoWS2811.h>
#include <DmxReceiver.h> // this uses UART0 (serial1) for DMX input

// DMX #defines and varibles
DmxReceiver dmx = DmxReceiver();
IntervalTimer bufferService;
//byte dmx_address = 0;
//byte dmx_data[32] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};


// octoWS2811 LED #defines and varibles
const int ledsPerStrip = 140;
DMAMEM int displayMemory[ledsPerStrip * 6];
int drawingMemory[ledsPerStrip*6];
const int config = WS2811_GRB | WS2811_800kHz;
OctoWS2811 leds(ledsPerStrip, displayMemory, drawingMemory, config);
#define strip_enable 9 

// setup / initalization stuff
void setup()
{
  pinMode(0, INPUT);
  bufferService.begin(BufferService, 1500);
  dmx.begin();  //start the DMX
  
  pinMode(strip_enable, OUTPUT);
  digitalWrite(strip_enable, LOW); // enable the buffer
  leds.begin(); //start octoWS2811
  leds.show();  //turn off all the LEDs
  
  delay(1000);
}
  
void loop()
{
 strip_pour();
 delay(10);
}



void BufferService()
{
  dmx.bufferService();
}

void strip_uniform()
{
  for(int x = 0; x <= (ledsPerStrip-1); x++)
     {
       //Strip 1
       leds.setPixel((x+(ledsPerStrip*0)), dmx.getDimmer(1), dmx.getDimmer(2), dmx.getDimmer(3));
       //Strip 2
       leds.setPixel((x+(ledsPerStrip*1)), dmx.getDimmer(5), dmx.getDimmer(6), dmx.getDimmer(7));
       //Strip 3
       leds.setPixel((x+(ledsPerStrip*2)), dmx.getDimmer(9), dmx.getDimmer(10), dmx.getDimmer(11));
       //Strip 4
       leds.setPixel((x+(ledsPerStrip*3)), dmx.getDimmer(13), dmx.getDimmer(14), dmx.getDimmer(15));
       //Strip 5
       leds.setPixel((x+(ledsPerStrip*4)), dmx.getDimmer(17), dmx.getDimmer(18), dmx.getDimmer(19));
       //Strip 6
       leds.setPixel((x+(ledsPerStrip*5)), dmx.getDimmer(21), dmx.getDimmer(22), dmx.getDimmer(23));
       //Strip 7
       leds.setPixel((x+(ledsPerStrip*6)), dmx.getDimmer(25), dmx.getDimmer(26), dmx.getDimmer(27));
       //Strip 8
       leds.setPixel((x+(ledsPerStrip*7)), dmx.getDimmer(29), dmx.getDimmer(30), dmx.getDimmer(31));
     }
       if (leds.busy() == false)
          {
            leds.show();
            delay(5);
          }
}

void strip_pour()
{
  for(int x = 0; x <= (ledsPerStrip-1); x++)
     {
       //Strip 1
       leds.setPixel((x+(ledsPerStrip*0)), dmx.getDimmer(1), dmx.getDimmer(2), dmx.getDimmer(3));
       //Strip 2
       leds.setPixel((x+(ledsPerStrip*1)), dmx.getDimmer(5), dmx.getDimmer(6), dmx.getDimmer(7));
       //Strip 3
       leds.setPixel((x+(ledsPerStrip*2)), dmx.getDimmer(9), dmx.getDimmer(10), dmx.getDimmer(11));
       //Strip 4
       leds.setPixel((x+(ledsPerStrip*3)), dmx.getDimmer(13), dmx.getDimmer(14), dmx.getDimmer(15));
       //Strip 5
       leds.setPixel((x+(ledsPerStrip*4)), dmx.getDimmer(17), dmx.getDimmer(18), dmx.getDimmer(19));
       //Strip 6
       leds.setPixel((x+(ledsPerStrip*5)), dmx.getDimmer(21), dmx.getDimmer(22), dmx.getDimmer(23));
       //Strip 7
       leds.setPixel((x+(ledsPerStrip*6)), dmx.getDimmer(25), dmx.getDimmer(26), dmx.getDimmer(27));
       //Strip 8
       leds.setPixel((x+(ledsPerStrip*7)), dmx.getDimmer(29), dmx.getDimmer(30), dmx.getDimmer(31));
       
       if (leds.busy() == false)
          {
            leds.show();
            delay(5);
          }
     }
}

So, does anybody have any thoughts?

Thanks, Tony.

 

[tetsuo]

I doubt it's anythign wrong w/ the code. Nothing jumps out, and your symptoms sound like common behavior for WS281x LEDs (they're actually picky little buggers compared to the old WS2801's)

Is the flicker always toward the end of the strip (or at least never on the first few pixels)? I've found that cases where only the later LEDs are flaky come down to voltage or grounding issues (or both). IN particular, cases such as pink/blue flickering on the last 1/4th of the strip during the rainbow test animation were solved by better grounding or better power cabling to the strips. I've also run into issue where one LED in a strip produces noisy output, so flickering/noise was easy to track down in cases where a strip always worked up to a specific LED, after which it was noisy (in one case, I re-flowed the solder joints for the LED and the adjacent cap and all was well. In other cases, I had to replace the noisy LED)

If the flicker isn't isolated to part of the strip; for example, whole strip occasionally blinks or has "noise", then it's either noise from grounding issues (yup, grounds again) or otherwise poor signal quality and/or timing. I doubt there are timing issues (OctoWS2811 contains very well-researched defaults). I did find that alternate timings to Paul's defaults performed a bit better in certain noisy conditions, but timing tweaks never fully fixed such issues; the right solution was always to address the underlying signal/ground problem.

A few last questions/thoughts/suggestions:
- often WS28xx flickering is a combination of factors. For example, ground-related noise AND a poorly matched resistor value.
- How are the strips grounded? Grounded @ both ends? Far end back to Teensy GND?
- try dropping the Vcc of the HCT245 to around 4.6V if you can. 3.3V is too low, but the LEDs are much pickier when DIN voltage exceeds the strip voltage.
- what kind of wire are you using for the data? 100 Ohm is great for CAT5e or CAT6, not so great for RG6 or 22AWG speaker wire.

 

[Dr.Rockzo]

Hi tetsuo,

I read some of your other posts about the WS2812 LEDs, sounds like you've chased some ghosts too.

The flicker seems to be "provoked" by certain colors like orange and lower brightness levels; sometimes only the center area of the strip is affected and sometimes it is only the far end..but a swear I may have seen it earlier in the strip as well.

I am powering the strip at three locations, the beginning, middle and end of the strip i think each feed is 20awg; I also soldered a .1uF cap across the far end of the strip's power, which seemed to help some. The three 20awg feeds tie into a 3-conductor/16awg, unshielded (+5V, ground, and data) jumper that goes for a few feet into the power supply, there the data splits off into a smaller jumper to the bread board; the +5V power for the bread board comes directly off of the power supply as well.

I am thinking about running the data on its own twisted pair or shielded twisted pair, but was concerned about creating ground loops.

Far end back to Teensy GND? - Never thought of that, what's the reasoning behind it?

What would you suggest I try for my matching resistor? I did try a range from 47 to 470 ohms, it got worse the higher I went.

I was wondering about signal quality. When I scope the data coming from my SN65HVD1786 into the Teensy it is crisp and square, but the waveform the Teensy is outputting to the SN74HCT245N is pretty round and has fluctuating "dips" in it, these also appear int the SN74HCT245N's output. I chalked it up to my cheap scope not having the resolution to really see what is going on, but could I actually need something to clean up my waveform? Could it be power supply noise?

I will try lowering the SN74HCT245N's VCC to 4.6V and post my results.

Tony

 

[Dr.Rockzo]

Okay, so I've tried a few things today but no solution yet.

Re-wired the power and data - I ran the data down a section of CAT5 from my bread board to the strip and now have a separate 16awg feed from the power supply; I am still powering the strip at three locations. Power for the bread board is now being tapped off near the strip to attempt matching the VCC(s). No real change was noticed.

I tried grounding the Teensy at the far end of the strip, no change noticed.

I also inserted a diode in series with the buffer IC's VCC do drop it down. Flicker got worse.

The Mean Well power supply was also buzzing at low output levels (with increased flicker); so I changed to a 20A @ 5V TDK-Lambda power supply, the flicker did improve some. My new power supply also has "sense" inputs so it can compensate for voltage drop along my power cable if I wire it correctly.

I ordered some various caps to improved my power supply bypassing. I'm thinking its power supply noise, does anyone have any thoughts on this?

I'm also going to try using a Schmitt Trigger on the outputs to clean them up, does anyone have any thoughts on this?

The hunt continues...

 

[PaulStoffregen]

Can you post a photo of how it's wired up?

Generally the best strategy is locating the power supplies close to the LEDs, connected with large and short wires running directly to the LEDs. It's best for the data plus ground to run from the Teensy to the LEDs, with the grounds meeting at or near the LEDs.

Long strips, where over 60 LEDs is entering "long" territory, often need power applied at both ends.

One simple test you can do is turn all the LEDs on to maximum brightness. Then use a voltmeter to measure the 5V power at various locations, like both ends of each LED strip, and in the middle if you access the strip (eg, not encased in a clear rubber tube). You're looking for any location that drops more than about 0.3 volts from whatever the power supply actually puts out.

 

[tetsuo]

Darn I wish I had some other suggestions for you. I think you're onto something re: your findings with the scope and signal quality. If I just run the teensy w/o any LEDs connected, the signal after a 100 Ohm cap and 20' of CAT-6 looks almost perfect. Once I connect the strips, the noise starts to pick up a bit, and the more PSU's and teensies I add to the mix, the more noise there is, but it never looks ~that~ much worse than this:

Keep in mind, all of my experience is from the 30 led/meter variety, and I was applying power to LEDs in groups of 42. 144 of these LEDs at full-on is 8.54 amps, so your 20A supply should be fine.... Honestly, I'm out of ideas beyond what's been covered.

 

[tetsuo]

One other test tip if you're playing w/ a scope or an analyzer. In addition to testing at full #FFFFFF, try #AAAAAA and #555555 as your test colors - they're a perfect 0101010 cadence so any bit errors tend to jump out a little more. Using grayscale values and cycling between dim and bright is also a handy test to visual inspection; the load/voltage will vary and even small errors appear as conspicuous color "blips" on an otherwise-white array.

Good luck!

 

[mortonkopf]

probably not this, but my 144led/m strip acted up with random flicker only when plugged into the laptop usb, and only when the laptop was connected to the mains. Random dots would appear anywhere on the strip (running one meter), but would almost appear cyclical. Might be worth running the teensy with a test sketch not connected to usb port just to rule out noise from this end? Although, no one else seems to have had this issue.

 

[Dr.Rockzo]

Hi guys,

Thanks for the responses, I think I'm getting somewhere.

Paul, I posted some pictures of how everything is currently wired up. I didn't take a picture of the middle of the strip, but there is a feed there too. When I put my meter on the power "rails" I get 4.9V at the feed-end and about 4.6V at the far end with everything white (and also most no flicker). In the blue CAT5 I have the green pair as ground, the orange is 5V to the bread board, blue/white is data and blue is also a ground, I am not using the brown pair.

tetsuo, when I test at full white there is little to no flicker; when I "dim" white with my DMX console I get various brightness flickers and different color flickers. My signals going out look horrible compared to what you have, there are "dips" in the highs and other "noise".

mortonkopf, I think I saw that in one of the thread I read. I am only connecting to USB when I change the program, otherwise the system runs via DMX control.

The Schmitt Triggers should arrive today, I will post my results.

 

[tetsuo]

. In the blue CAT5 I have the green pair as ground, the orange is 5V to the bread board, blue/white is data and blue is also a ground, I am not using the brown pair.

I'm not sure I follow correctly - are you using CAT5 to carry power to the strip? I can't see how you're getting 4.9V at the strip if that's the case (maybe at low brightness levels, but I'd expect that to drop well below 4V at full-strip-white).

Also, where is your resistor for the data? For data over CAT5, you should have a 100 Ohm resistor as close to the output pin of the HCT245 as possible.

For whatever it's worth, my setup is:
4AWG wire for a set of 504 LEDs, with the final 12"-24" as a pair of 16AWG to each 42-LED segment. (total: 6 pairs of 4AWG breaking out into 72 pairs of 16AWG). The CAT-6 carries only data. with half of each pair being connected to both GND at the strip and GND on the teensy. The 100 Ohm resistors are one protoboard hole away from the 74HCT245N outputs . I really MUST get some pictures... will try to do so tonight.

 

[tetsuo]

Ahh - wait, I see. You're running power to the connector for the strip, and then FROM that connector back to the teensy? I'm not sure what the pros/cons of such a layout would be, but it's certainly different than what I've seen elsewhere

 

[tetsuo]

One last thing! In addition to needing a 100 Ohm resistor near the transceiver, you probably need one where you're transitioning from CAT5 to whatever stranded copper you're using for the last 12+ inches. I mis-measured on one of my CAT6 cuts and when I tried to extend it a few extra inches w/ some extra 18AWG speaker wire and the signal quality went south. The extra 100-Ohm resistor at the transition fixed it right up!

 

[Dr.Rockzo]

Hi testsuo,

The CAT5 only powers from the connector to the bread board and carries data from the bread board to the connector. I need to be able to easily move this thing (to some degree) so I had to use something, that XLR plug is rated at like 16A per pin.

I tend to reinvent the wheel whenever possible...

 

[PaulStoffregen]

The CAT5 only powers from the connector to the bread board and carries data from the bread board to the connector.

Ok.

I need to be able to easily move this thing (to some degree) so I had to use something, that XLR plug is rated at like 16A per pin.

For the sake of troubleshooting, could you try a simple hard-wired test? Even though it's totally impractical for how you need to deploy this project, the idea isn't to make a final solution but instead to just try learning more about why it's flickering and possible solutions.

I'd suggest removing the cable and connectors. Put the LEDs on the table with the power supply. Run those heavy red and black wires directly into the power supply, with only a few inches of wire running between them. During this test, run just 1 twisted pair of the CAT5 cable between Teensy and the LEDs, for only signal and ground. Connect the grounds at the LEDs, or as close to the LEDs as reasonably possible (eg, do not wire the CAT5 ground to the power supply, get it connected at the LEDs). During this test, the Teensy will obviously need its own power. Best to use a battery or non-grounded power supply like a wall wart.

Again, this idea is only just for troubleshooting, to see if this connection style can solve the flickering. Even though you can't use it that way, at least finding some connection that eliminates the flickering will give you a solid starting point to work towards a wiring style that can meet your needs.

 

[Dr.Rockzo]

Hi again,

Paul, I took your advice and did a sanity check today. I removed my XLR plug and ran power directly into the supply with a twisted pair over to the bread board, the flicker still existed. I think tomorrow I'm going to get my Mega 2560 out and run the strandtest sketch on it to see if the flicker is still there.

Once the Schmitt triggers arrived i tried them, no improvements there either. Improved bypassing didn't seem to help, although I guess it couldn't hurt; 270uF low ESR electrolytic across the breadboard's power and a .1uF cap for each device where it pulls power.

I never mentioned I'm running at 48MHz, should I be running at one of the other frequencies? I'll try that tomorrow too.

I did notice some random pixels without the DMX cable connected to the controller today, all red moving in a pattern. I really thought I was on to something, I hadn't terminated the DMX cable with a 120 ohm resistor and was sure that I had found the source. Terminated the DMX cable correctly and...it still flickers (face palm).

I also connected an 8x8 matrix to the Teensy without the strip connected to the breadboard or power supply, the flicker was still present.

Could I be inadvertently disrupting something in the code?

I just don't get it....

 

[Dr.Rockzo]

Hey All,

So I did some further testing...

The flicker starts after the 53rd LED on both the 144LED/m strip and the 8x8 matrix I have.

If I connect the strip to channel #1 and the matrix to channel #2 they both flicker in time with each other.

If I connect only the matrix to channel #1 it flickers at the 53rd LED; the same with only the strip on channel #1

If I connect only the matrix to channel #2 it flickers at the 53rd LED; the same with only the strip on channel #2.

test sketches on the Mega 2560 work fine...

I'm starting to think it really isn't the power supply.

I made some changes to the code, let me know if anything seems out of place.

// library #includes
#include <OctoWS2811.h>
#include <DmxReceiver.h> // this uses UART0 (serial1) for DMX input

// DMX #defines and varibles
DmxReceiver dmx = DmxReceiver();


// octoWS2811 LED #defines and varibles
const int ledsPerStrip = 64;
DMAMEM int displayMemory[ledsPerStrip * 6];
int drawingMemory[ledsPerStrip*6];
const int config = WS2811_GRB | WS2811_800kHz;
OctoWS2811 leds(ledsPerStrip, displayMemory, drawingMemory, config);
#define strip_enable 9 


// setup / initalization stuff
void setup()
{
  pinMode(0, INPUT);
  dmx.begin();  //start the DMX
  
  pinMode(strip_enable, OUTPUT);
  digitalWrite(strip_enable, LOW); // enable the buffer
  leds.begin(); //start octoWS2811
  leds.show();  //turn off all the LEDs
  
  delay(1000);
}
  
void loop()
{
 strip_pour();
 for(byte x=0; x<=19; x++)
     {
       dmx.bufferService();
       delayMicroseconds(1500);
     }
}


void strip_pour()
{
  for(int x = 0; x <= (ledsPerStrip-1); x++)
     {
       dmx.bufferService();
       
       noInterrupts();
       
       //Strip 1
       leds.setPixel((x+(ledsPerStrip*0)), dmx.getDimmer(1), dmx.getDimmer(2), dmx.getDimmer(3));
       //Strip 2
       leds.setPixel((x+(ledsPerStrip*1)), dmx.getDimmer(5), dmx.getDimmer(6), dmx.getDimmer(7));
       //Strip 3
       leds.setPixel((x+(ledsPerStrip*2)), dmx.getDimmer(9), dmx.getDimmer(10), dmx.getDimmer(11));
       //Strip 4
       leds.setPixel((x+(ledsPerStrip*3)), dmx.getDimmer(13), dmx.getDimmer(14), dmx.getDimmer(15));
       //Strip 5
       leds.setPixel((x+(ledsPerStrip*4)), dmx.getDimmer(17), dmx.getDimmer(18), dmx.getDimmer(19));
       //Strip 6
       leds.setPixel((x+(ledsPerStrip*5)), dmx.getDimmer(21), dmx.getDimmer(22), dmx.getDimmer(23));
       //Strip 7
       leds.setPixel((x+(ledsPerStrip*6)), dmx.getDimmer(25), dmx.getDimmer(26), dmx.getDimmer(27));
       //Strip 8
       leds.setPixel((x+(ledsPerStrip*7)), dmx.getDimmer(29), dmx.getDimmer(30), dmx.getDimmer(31));
       
       interrupts();
       
       if (leds.busy() == false)
          {
            leds.show();
            for(byte x=0; x<=3; x++)
               {
                 dmx.bufferService();
                 delayMicroseconds(1500);
               }
          }
     }
}

If I test the code with "const int ledsPerStrip = 64;" set as 52, I never have any flicker. If I set "const int ledsPerStrip = 64;" to 53, the 53rd LED starts flickering; all LEDs after the 53rd LED are affected.

Any ideas?

 

[Dr.Rockzo]

SUCCESS!!

Just for fun I changed the order of my #includes from this:

#include <OctoWS2811.h>
#include <DmxReceiver.h> // this uses UART0 (serial1) for DMX input

To this:

#include <DmxReceiver.h> // this uses UART0 (serial1) for DMX input
#include <OctoWS2811.h>

and presto, no more flickers.

I'm glad everything is working now, but could someone explain why the order of the #includes caused the flicker?]

I also noticed that when they were hot (the matrix requires a heat sink apparently), they flickered more.

 

[tetsuo]

Wow... I'm glad you got it sorted out, but I have no clue as to what collision may have occurred between those two header files (that wouldn't have caused compilation errors).

In any case, with all of the time and effort you've put into signal quality, you probably have a super-noise-resistant setup now!

 

[PaulStoffregen]

Wow, I would never have guess THAT.

I've put this on my list of strange stuff to (someday) investigate. When I do, I'll post a followup on this thread.

 

[cdorety]

This is mind-numbingly unbelievable.

I cannot thank you enough for trying this. It seems to have solved my flicker. I literally tried all the other fixes, my scope read super clean data everywhere, power is solid with tons of headroom... I just couldn't track down the problem. Thank you thank you thank you.


Note: this flicker is only seen with the ws2812B leds. the ws2811S version is much less finicky.

SUCCESS!!

Just for fun I changed the order of my #includes from this:

#include <OctoWS2811.h>
#include <DmxReceiver.h> // this uses UART0 (serial1) for DMX input

To this:

#include <DmxReceiver.h> // this uses UART0 (serial1) for DMX input
#include <OctoWS2811.h>

and presto, no more flickers.

I'm glad everything is working now, but could someone explain why the order of the #includes caused the flicker?]

I also noticed that when they were hot (the matrix requires a heat sink apparently), they flickered more.

 

[jimparis]

My guess is that changing the order of the #includes changed the code layout in flash. This causes different access patterns when running code, which will in turn affect bus arbitration, which is the cause of the flicker I saw in this thread. As you mention, the WS2812B are very finicky in this regard. My StableWS2811 code, linked in that thread, should do better, as it's not sensitive to bus arbitration delays.