Skip to content
This repository has been archived by the owner on Nov 18, 2020. It is now read-only.

Flickering LEDs + Possible solution #30

Closed
LarsMichelsen opened this issue Dec 15, 2019 · 10 comments · Fixed by #37
Closed

Flickering LEDs + Possible solution #30

LarsMichelsen opened this issue Dec 15, 2019 · 10 comments · Fixed by #37
Labels
bug Something isn't working discussion enhancement New feature or request

Comments

@LarsMichelsen
Copy link
Collaborator

I'm building my second lamp right now. It has 100 LEDs and has flickering problems with some animations from the beginning. Especially "Night rider" and "Color wipe" were a problem from the beginning.

My first lamp with 60 LEDs never had a problem of this kind.

I've spent a lot of hours studying different theories now.

a) Power consumption: The power supply has 6A, so it should be large enough.
b) Defective hardware: I replaced everything, the LED strips, the power supply, the board, every cable: No major difference.
c) Too little memory: I measured everything and couldn't find a problem.
d) Hanging because of some interrupts. I have removed all other functions of the board, no improvement.
e) I went back to commits in history to rule out a bug in recent changes.
f) I have updated all libraries and tried older versions as well.
g) Looking for bugs in some timing functions (e.g. EVERY_N_MILLISECONDS).

Nothing helped at all. And I was pretty frustrated.

By chance I found an interesting track today. I played with the timing of an animation and added Serial.Println statements, suddenly the flickering was gone. I removed some of those calls again and the flickering was there again.

This made me think that the updates through the board might just be too fast for the 100 WS2821B LEDs, so the LEDs can't process the updates fast enough. This leads to different instabilities of the animations, depending on the timing of the code.

After I found this out, I simply added an EVERY_N_MILLISECONDS(16) to handleMode(), which immediately removed the flickering.

What do you think?

LarsMichelsen added a commit to LarsMichelsen/Super-Simple-RGB-WiFi-Lamp that referenced this issue Dec 15, 2019
See thebigpotatoe#30
for further information

Fixes thebigpotatoe#30
@thebigpotatoe
Copy link
Owner

I think you're right that the refresh time might have something to do with it. I also noticed a massive increase in flicker when trying to update to the arduino core 2.6.0 as well. So it may be software related.

What I actually think may be the case is the voltage levels along such long lengths of strips at the data rates we are trying (and hence why lowering the rate imporves flicker). The WS2812b's are 5V devices and the data pin should run at 5V, but in my design this is not the case. A logic level shifter may help to get higher bandwidths for more lights.

@LarsMichelsen
Copy link
Collaborator Author

May be. I also thought about that and added wires every 25 LEDs for better power distribution. This did not solve the problem.

Level shifter might me a solution, I did not try that.

However, do you see any drawbacks applying the changes of #31 ?

@thebigpotatoe
Copy link
Owner

The ws2812b's are far less reliant on propper power than dumb strips due to their onboard constant current driver. That's why I love these things, and probably why adding power along the strip wouldn't help much.

I haven't read the code properly and I'm off travelling for the Christmas period so I won't be able to play with any code till after. As far as I can tell I don't see any issues with the merge. Any additions that make the leds more stable regardless of how they are built are always good. I'll have a play with it when I get home see if there is anything else I can add too.

@thebigpotatoe thebigpotatoe added bug Something isn't working discussion enhancement New feature or request labels Dec 30, 2019
@thebigpotatoe
Copy link
Owner

This issue has been addressed by several pull requests (#31, #33) and a couple of hardware suggestions above, but I see interesting results on the strip. To make sure that this is being addressed correctly I propose a short list of checks to see if any suggested changes have worked;

  • Test on current master with ESP core of 2.5.2
  • Test on current master with latest ESP core (may require manual led control until website issue is also fixed)
  • Test other suggestions to see if they offer the same results or use a similar method

The aim would be to find a method or combination of methods to reduce flicker from short and long strips. I feel this may require slowing down the refresh rate (or make it variable for users), as well as small hardware improvements perhaps?

LarsMichelsen added a commit to LarsMichelsen/Super-Simple-RGB-WiFi-Lamp that referenced this issue Dec 30, 2019
See thebigpotatoe#30
for further information

Fixes thebigpotatoe#30
@LarsMichelsen
Copy link
Collaborator Author

Tested #37:

  • Test on current master with ESP core of 2.5.2: Works.
  • Test on current master with ESP core of 2.6.3: Works.

--

Tested 1cac87c from #33:

  • Test on current master with ESP core of 2.5.2: 100 LEDs + Color wipe: Works.
  • Test on current master with ESP core of 2.6.3: 100 LEDs + Color wipe: Flickering

It seems to me that the approach from 1cac87c randomly solves the problem for timing reasons. Just like the print statements randomly solved it in my experiments.

Side note: The 1cac87c commit makes both format changes and the flicker fix. To make changes easier to track, this should be split into at least two commits.

--

In the meantime I found something interesting in the comments of this article: https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/

However, you should note that the WS2812 is PWM based with a frequency of roughly 400 Hz. There is visible flicker when moving the LEDs quickly.

Without the limitation it was previously possible to get above 400 FPS without problems, which may have led to the random flickering.

@thebigpotatoe
Copy link
Owner

I updated #30 to match all of the new pull requests that have been made. I found I did not get the same result for ESP core of 2.6.3. Not sure why and I haven't dug into it yet. If you give it a go with the updates see if you get the same result?

I am aware of 1cac87c and the fact it needs to be split. But I think your right, it works as there is a delay allowing the device to catch up and deliver the data.

I also think your right that the flicker is timing related, if we slow the frame rate down enough then strips of any length should be feasible. It just needs to be as fast as possible for smooth effects of course. Maybe having a #define FRAME_RATE would be useful?

LarsMichelsen added a commit to LarsMichelsen/Super-Simple-RGB-WiFi-Lamp that referenced this issue Dec 31, 2019
See thebigpotatoe#30
for further information

Fixes thebigpotatoe#30
@LarsMichelsen
Copy link
Collaborator Author

Just rebased #37 to current upstream/master and tried it together with ESP 2.6.3: Works without issues.
What problems do you experience with it?

I also added a FRAME_RATE macro as suggested.

@thebigpotatoe
Copy link
Owner

thebigpotatoe commented Jan 2, 2020

Seems like the flickering is more server in 2.6.3 where longer parts of the strip flash the wrong colour compared to the issues in 2.5.2. Have a look at the video I attached, its running #37.

Had a play with the frame rate. Went right down. Still saw flicker albeit less. The macro is great. Handy for changing the rate up and down to suit what you need.

This might be hardware issues and I might have to change the power supply. Currently it running on a Dev one.

Update: Changed power supply no difference
videotogif_2020 01 02_18 12 42

@LarsMichelsen
Copy link
Collaborator Author

I never had issues with the rainbow mode. Must be another issue.

Do you experience the same issue when lowering the brightness?

Well, if you look at the bug reports for FastLED, you can assume that flickering can have many different causes. Let's merge this here, then we have one less possible cause of error.

btw. what's that round black thing?

@thebigpotatoe
Copy link
Owner

Its the same on all modes, just most obvious here. So yes i think the merge here will be useful for others.

Brightness and frame rate have no effect, have not tested a clean install with no interrupts to mess with timing though. Such is the way of DIY electronics, so many potential bugs.

The round black thing is a chromecast audio. I was using it to stream music to the ESP for the visualiser mode which was also going to be in another write up. Then I found out google doesn't sell then anymore so it through a stick in the works. Been there since then. It wont have an effect on the ESP, isn't even plugged into it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working discussion enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants