OCTOWS2811 and DOTSTAR problems

[JGwinner]

Hi

I purchased the Teensy 3.2 and the OCTOWS2811, and intended on using them to drive several DOTSTAR strands (144 LED's/m). I have 14 total meters, but I'm only hooking up 2 meters (288 LED's), and have run into problems.

The LED's work fine for the first 100 or so, then 'peter out' into abstract weirdness.

So, I tightened down everything, double checked wiring, cut the USB power trace so the Teensy board is getting all it's power from +5V / GND connections from my power supply (24V, to a 5V buck converter).

I'm using the blue and orange wires (T568B), from pins 2 and 14, as the APA102 needs a data and clock, and the line:

	FastLED.addLeds<DOTSTAR, 2, 14, BGR>(ledStripTotal, TOTAL_LEDS);

to setup the LED's (FastLED.h). Still the same results - the same sketch still works fine with the Leonardo, but with a slow update rate (which will only get worse with all 14 meters).

So, I cut up yet another Cat5/6 cable. (these might be Cat5). It was slightly thicker wire (24g), but I'm getting slightly worse results. I've connected them 2-3 different ways, same results - only about 50 to 100 LED's light correctly, and the rest fade out into a random hash of colors. It's as if the OCTOWS2811 isn't pushing enough voltage or current.

I'm not using the OCTOWS2811 library, I thought maybe that was a difference between the Leonardo and the Teensy.

I'd just solder wires directly there, but it doesn't seem like there are pads from the 74HCT245 other than the RJ-45 on the OCTOWS2811 board. I'm working on wiring up a custom proto board for the Due, with 74HCT245n's, but not sure I have time (trying to bring it to Yuri's night, tomorrow night!)

I checked current and voltage; the strands are pulling about 2.6A to 3.2A and the voltage is stable at 4.91 (I used pretty thin wire for the prototype, the main cube will be 16 or 12g to the LED's +5, 22g signal wire).

I don't think it's a power supply problem as the same strands work perfectly (slow) with the Leo. I even wired up the Leonardo to the +5V supply as the Teensy, and tried both without their USB connections - same weirdness either way.

Here's the code (only change one pin and processor between the Leo and Teensy).

#include "FastLED.h"
#include "chipsets.h"

/**************** Status LED Defines ************/
// Teensy 3.x / Teensy LC have the LED on pin 13
// Leonardo also has an LED on pin 13 - use for 'health' status
const int ledPin = 13;


/**************** LED Defines ************/

#define NUM_LEDS 144
//max number is 2016, 
#define TOTAL_LEDS 288 
#define LED_MAX_SIDE 2

CRGB ledStripTotal[TOTAL_LEDS];

int iLastLED = 0;

// the setup function runs once when you press reset or power the board
void setup(void)
{
	Serial.begin(9600); //jdg: Just to make sure. Might make faster ...  
	delay(1000);//JDG: with the Leonardo, we need a small delay here
				//or we don't get the welcome aboard message
	Serial.print("Welcome to the LED Test program\nVer 0.71 ALPHA\n\n");

	//setup the built-in LED pin
	pinMode(ledPin, OUTPUT); //to blink the onboard LED

	FastLED.addLeds<DOTSTAR, 2, 14, BGR>(ledStripTotal, TOTAL_LEDS);
	//for Leonardo, use 2 and 7
	//FastLED.addLeds<DOTSTAR, 2, 7, BGR>(ledStripTotal, TOTAL_LEDS);

	iLastLED = 0;

}

void loop(void)
{
	//now, flash the LED's. (TTD: Serial might interupt?)
	//light up the segments
	int i;

	for (i = 0; i < TOTAL_LEDS; i++)
	{
		if (i == iLastLED)
			ledStripTotal[i] = CRGB::White;
		else if (i>iLastLED)
			ledStripTotal[i] = CRGB::Blue;
		else
			ledStripTotal[i] = CRGB::Red;

	}
	digitalWrite(ledPin, LOW);    // set the LED off
								  //it will be dark while the code runs the 'show' line.

	FastLED.show(); //this seems to take some time!
	++iLastLED;
	iLastLED = iLastLED%TOTAL_LEDS;
	if (iLastLED == 0)
		Serial.print("Looping back to first LED\n");
	delay(1); //run it fast!

	digitalWrite(ledPin, HIGH);    // set the LED off


	//Serial.print("Showing LED: ");
	//Serial.print(iLastLED);
	//Serial.print("\n");

}

Any ideas?

== John ==

 

[potatotron]

I doubt it's an issue with the wiring, especially from the 245 chip to the RJ45 connector.

You won't be able to use the PJRC OctoWS2811 library; it's written for WS2812 LEDs (what Adafruit calls "Neopixel").

You can rule out voltage issues by limiting the maximum brightness on the APA102s (what Adafruit calls "Dotstar") with FastLED.setBrightness(32) or so. If you do that do you get the same glitching?

What capacitor(s) do you have between the output of the Buck converter and the LEDs?

Have you tried running the T3.2 at a lower clock rate?

 

[JGwinner]

You can rule out voltage issues by limiting the maximum brightness on the APA102s (what Adafruit calls "Dotstar") with FastLED.setBrightness(32) or so. If you do that do you get the same glitching?

Yes Even with just 1 segment (and no glitching with up to 3 segments with the Leonardo or Mega)

What capacitor(s) do you have between the output of the Buck converter and the LEDs?

Based on Adafruit tech support, no capacitor (for either uC).

Have you tried running the T3.2 at a lower clock rate?

Yes, was running it at default (no overclock). Actually, I even tried slowing down the updates with a delay(1000) to see if maybe the Teensy was overdriving ... which would be weird, I mean, people do use the Teensy with the APA102's.

I doubt it's an issue with the wiring, especially from the 245 chip to the RJ45 connector.

If I wiggle the wires it did get worse, but I've rewired it 2-3 times and it never gets 'right'. Now it's fairly stable, I ditched the connectors and twisted the wires together, and put it in a Wago lever nut. Flicking the connectors doesn't change the lighting, and it's still glitchy at the end (but not the start).

Here's an example; should be red all the way around (yes, some are bright white). Changing the brightness doesn't change the glitched LED's

== John ==​

 

[GremlinWrangler]

The clock rate menioned above is the SPI clock feeding the strips. Each chip does a bit of re-shaping to the signal and I found about 1.5 meters into my naked strips I could see pretty much sine waves when I looked with a scope. Dropping the clock rate so there was time for things to stabilise before the next clock pulse sorted it out, but will need to look up how I dropped down from the default max speed (which looks to be only good for short runs).

Edit: for fastled see second para here for reducing the data rate to the strips https://github.com/FastLED/FastLED/wiki/SPI-Hardware-or-Bit-banging

 

[JGwinner]

THANK YOU

Ah! That worked , although it slowed them down enough I'm back to the original problem, updates like molasses

I found I could get about 5Mhz to 2.5m with 576 LED's (4m). WAY far away from my 14M I was hoping to get POV effects from. Good thing I got a Due and 10 75HCT245's

Now I'm questioning the concept that APA102's are faster than WS2812's .

with 3m, I can get 5Mhz. I'm going to build a spreadsheet for the data-rate (empirical values).

Gotta work the math ...

== John ==​

P.S. For a sec, I didn't get why the Leonardo could push 576 (4m) without a problem, then I realize it's naturally driving a much slower data rate.
P.P.S. Sounds like I need a real scope too - at least 10Mhz, probably 40 to really see any of this. Those Arduino based scopes had been looking pretty good, but this would have been way over their heads.

 

[PaulStoffregen]

Just curious, which boards and which driver circuitry are you actually using? Earlier you mentioned Teensy 3.2 and the Octo28 board. Now Due and Leonardo? Are those using the Octo28 board drive the signals? Even if you use the same parts, small details in construction, such as the way grounds are connected, can make a difference in signal quality.

Indeed, a good scope is needed to really see what's going on with the signals. Most people focus only on bandwidth when shopping for scopes, but you should also look for the waveforms/second capture+render rate. A wide bandwidth slow updating scope is much less useful than you might imagine when troubleshooting real problems.

 

[GremlinWrangler]

If you can afford it a not rubbish 'real' scope will save you so much hair pulling, as mine did when I had the same 'why don't my strips work' problem. In theory the reshaping hardware on the chips should be cleaning things up but looking at mine at least the clock was distorting with respect to the data. I don't think any high speed interface is going to handle 14 meters so that run will probably need some sort of slave controller setup at points down the strip, and a fair bit of care with signal managment at the input end.

It might be possible to do your own reshaping mid span with some form of very high speed buffer IC but doing that would involve shopping for a bunch of them and doing some empirical testing.

If you want to get real empirical about it you could tap a second teensy into the far end of the strip and run frequency counter code with a fixed pixel pattern for a fixed time and get better length/errors numbers.

 

[JGwinner]

Paul:
I've got the Teensy 3.2 w/pins + Octo28.

I also was using the Leonardo and Mega2560.

The Due isn't hooked up yet.

The grounds/power are hooked up as identically as possible between the Teensy/Octo and the Leo/Mega driving directly. I made sure the USB wasn't powering any of the boards, to try to eliminate any floating ground problems. The Mega/Leo drove things pretty reliably, but even at the best they don't have the update rate the Teensy has, which is probably where the waveform degradation comes in, which is why it seemed like they were driving 'cleaner'. Sure enough, the frequency of update seemed to be the problem, depending on the length.

I'm actually starting to wonder if the whole thing, even with the shortest strand of 161, won't quite be POV anyway.

Gremlin:

Thanks! Any recommendations for scope brands?

It seems like the older and crankier I get, I get more empirical Instead, I'm thinking of trying to recall my engineer roots and lookup the frequency and work out what lengths are actually possible in a spreadsheet. I don't see any of these numbers anywhere on the web, really. I guess Adafruit might be worried no one will buy if they knew the raw numbers? heh.

I could actually do some strands in parallel, so I'm trying to work out what patterns I need vs. what is possible - thus the thought for the spreadsheet.

The big thing I need to do is when the robot spins (a cube/wheel chair base), the 'front' lights need to say in one place, until the cube stops and drives off again (in which case white/red lights will slew to their proper place). In other words, the lights stay in place as the physical cube (and LED's) rotate. I'll need to work out what the max 'spin' frequency is, then work that backwards to what speed I need.

== John ==​