Hello! I'm looking for some debug inspiration for my project and the problem I'm

Archive FastLED Archive
,
1

Hello! I’m looking for some debug inspiration for my project and the problem I’m currently dealing with - first a short rundown of the setup: ESP32, 3 strips of WS2812B LEDs (60, 99 and 198 LEDs each), data lines are level shifted from 3V3->5V, FastLED 3.1.8 fork of Sam Guyer using RMT, 430Ohm resistor in each data line, 1000µF/10V cap at each LED strip, shared 5V MW power supply, multiple power injections per LED strip, data lines use shielded cables.

The problem I’m facing right now: Two of the three LED strips don’t show anything - the 60 LED strip works without problems. But whenever I cut the power to the power supply and the 5V start to fade away, the two non-working strips do show the correct color values for a fraction of a second before the 5V are gone entirely. The video shows this behavior while sending CRGB::White to all LEDs of each strip - when enabling the power supply only the 60 LED strip in the middle lights up, the other two strips stay dark until the power gets cut (you can hear the 230V relay clicking when listen carefully).

Things I’ve tried so far that didn’t helped: Swaping data line pins between LED strips. Only addressing the first ~15 LEDs per strip - same behavior. Only enabling one LED strip at a time - same behavior, only the 60 LED strip works. Removed the data line resistor as well as the cap - no difference. Cross-checked with a different, older WS2812B LED strip which works perfectly on all of the three data line pins.

My current assumption is that I’m using some of those newer WS2812B versions with an increased RES time which might explain why some older WS2812B LEDs work without problem. I tried to increase the RES time in fastled_esp32.h but this didn’t helped either. Still I’m puzzled why the other two strips start to work when the power gets cut. The length of the data lines to the first LED of each strip is basically identical - I can’t imagine that this is triggered by a general wiring error.

Right now I’m running out of ideas to pinpoint the source of the issue and I’m close to get myself an oscilloscope to be able to dive into the joy of double-checking the dataline timings of the LED strips :wink: Before doing so - does anyone have an idea what the root cause could be or other things that I could check? Thanks!

2

Hey @Markus_Lang , I have noticed some weirdness in my code when the strips are different lengths. Can you post the code? Or at least the setup code?

3

@Sam_Guyer Sure, that’s the FastLED related code:

#define LED1_NUM 198
#define LED2_NUM 60
#define LED3_NUM 99
#define LED1_TYPE WS2812B
#define LED2_TYPE WS2812B
#define LED3_TYPE WS2812B
#define FRAMES_PER_SECOND 30

namespace LedHandler {
const unsigned int FRAMES_PER_SECOND_DELAY = 1000/FRAMES_PER_SECOND;

const uint8_t LED1_PIN = 14;
const uint8_t LED2_PIN = 15;
const uint8_t LED3_PIN = 27;
const unsigned int NUM_LEDS = LED1_NUM + LED2_NUM + LED3_NUM;

CRGBArray<NUM_LEDS> gLeds;

static TaskHandle_t fastLedTaskHandle = 0;
static TaskHandle_t currentTaskHandle = 0;

void handle() {
	EVERY_N_MILLISECONDS(FRAMES_PER_SECOND_DELAY) {
		// call active led mode which will modify gLeds array
		...

		if (currentTaskHandle == 0) {
			const TickType_t xMaxBlockTime = pdMS_TO_TICKS(200);
			currentTaskHandle = xTaskGetCurrentTaskHandle();
			xTaskNotifyGive(fastLedTaskHandle);
			ulTaskNotifyTake(pdTRUE, xMaxBlockTime);
			currentTaskHandle = 0;
		}
	}
}

void fastLedTask(void *pvParameters) {
	while(1) {
		ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
		FastLED.show();
		xTaskNotifyGive(currentTaskHandle);
	}
}

void begin() {
	pinMode(LED1_PIN, OUTPUT);
	pinMode(LED2_PIN, OUTPUT);
	pinMode(LED3_PIN, OUTPUT);
	FastLED.addLeds<LED1_TYPE, LED1_PIN, GRB>(gLeds, LED1_NUM).setCorrection(TypicalSMD5050);
	FastLED.addLeds<LED2_TYPE, LED2_PIN, GRB>(gLeds, LED1_NUM, LED2_NUM).setCorrection(TypicalSMD5050);
	FastLED.addLeds<LED3_TYPE, LED3_PIN, GRB>(gLeds, LED1_NUM + LED2_NUM, LED3_NUM).setCorrection(TypicalSMD5050);

	gLeds.fill_solid(CRGB::Black);

	xTaskCreatePinnedToCore(fastLedTask, "fastLedTask", 2048, NULL, 2, &fastLedTaskHandle, 0);
}

}

4

@Markus_Lang , OK, this is going to seem crazy, but try adding the strips in order from shortest to longest in the set up code (in your case, add the 60 LED strip first, then the 99 LED strip, then the 198 LED strip). Let me know if that fixes the problem.

5

@Sam_Guyer Ooooh really?
[commenting to follow post]

6

This might not solve your problem, but you should not cut the power from the LEDs while you µC is still alive.
First shut the µC down, wait until all Caps are dis-charged and then it’s save to cut power.

7

@marmil I’m still trying to understand it, but it looks like what happens is that when the last strip is shorter than the others, once it finishes all the others stop as well. I have stared at the code a lot, but I cannot see why it’s happening. Concurrency is hard!

8

@Sam_Guyer I’ve tried reordering the led strip setup code as you suggested but it didn’t fix my problem. I’ll try to get my hands on a logic analyzer middle next week. I’ll hope this will bring some insight to what is going on…

9

What about just cheating and specify each strip to be the same length as the longest one !?

That will waste some memory but the ESP-32 probably has plenty !

10

@Markus_Lang Hi just an question i am not developper but i have an dual p5 panel and the power have an error and the panel if reach certain luminosity complete run out. And the teensy board need a complete power out for recovery

For 357 pixel (i am right ?) Is maximum of 357 x 0.06amp (60mah 20/color x pixel) in maximum of 5v 21.47amp if ou use 20 or 25 amp in chinese solder change or test the power supply. An power suply with 30amp or 35 amp is minimum for heat generation.

Your project go up and get run out after initialisation of 2 big led strip.

Is just an idea. I have an similal error and is the Chinese power supply have default.

11

@JP_Roy That’s what I’ve done in the cases where it has caused a problem. But I really just need to debug it and fix it!

12

@Markus_Lang Any progress? Rereading your post, it does seem more likely to be a power problem than a software problem, but you never know.

13

@Sam_Guyer Took a while to track down my problem since I had a combination of multiple f*ckups that lead me into the wrong directions first. Short version: bad data line signal quality.

Longer version: 1) Additional GND noise triggered by another device sharing the same 5V power supply. 2) A just worse / slow enough MOSFET level shifter that messed up two of my three LED strips data lines. At the end I was able to get all three of them running with changing the data line resistors in the 100-500Ohm range to match each LED strip data line individually - still I had some flickering once in a while.

Right now I’m driving the LED strips directly from the ESP32 at 3.3V without using a level shifter anymore which works fine so far. Might try a 74AHCT125 level shifter later.

Thanks to everyone sharing their thoughts regarding my problem!

14

@Markus_Lang Glad to hear! I never studied electrical engineering formally, so I’ve had to learn the hard way to pay attention to power issues.

15

@Sam_Guyer Regarding the LED strip order / length issue: While debugging my problem I’ve noticed a different behaviour if driving the strips serial vs. parallel: Right after the shortest LED strip is done the longest one gets delayed. The transmitted data is fine, still right amount of edges but an additional delay of 50us. Maybe that’s related to the concurrency issue you’re chasing.

missing/deleted image from Google+

16

@Sam_Guyer Serial version
missing/deleted image from Google+

17

@Sam_Guyer Some detail of the signal gap.
missing/deleted image from Google+

18

@Markus_Lang That’s really interesting. I have not had a chance to look at that level of detail. A 50us delay seems bad – like it would cause the long string to latch too early.

What is the order that you added the strips? From the serial version, it looks like the order is bottom to top.

Also: make you sure pull the latest version of my code – there was a painful bug in the previous version.

19

@Sam_Guyer I’ve missed your changes from 4 days ago. Just uploaded the new version to my ESP32 and everything looks good. LED order was: 198, 60 and than the 99 LEDs strip but I guess that isn’t that important anymore :wink:
missing/deleted image from Google+

20

@Markus_Lang Oh great – so the 50us gap went away?