Duty Cycle of FastLED output for WS2811 on Wemos D1 #523
Comments
|
The difference is that FastLED is allowing interrupts to process between each led while it's using bitbanging output - this will introduce a slightly longer gap in between each led's worth of data - you can disable interrupts using: #define FASTLED_ALLOW_INTERRUPTS 0 or you can try tweaking the retry count: #define FASTLED_INTERRUPT_RETRY_COUNT 1 (the flickering that you're seeing may be the result of an interrupt running too long and the frame getting reset and starting back at the first led again, or a retry attempt happening too quickly, which is not starting at the beginning of the switch - that code's only really been timed/tuned to WS2812B's, and I haven't gotten a good system in place for the reset times of other chips, like the WS2811 (which has different reset timing). |
|
I do have interrupts disabled. I described exactly what I saw on the scope.
Here's the first few lines of mycode:#include "FastLED.h"
#define NUM_LEDS 1100
#define DATA_PIN 3
#define FASTLED_ESP8266_RAW_PIN_ORDER
#define FASTLED_ALLOW_INTERRUPTS 0
// This is an array of leds. One item for each led in your strip.
CRGBArray<NUM_LEDS+1> leds;
And I'm not using the serial port or WiFi...
…-Darren
On Friday, November 17, 2017, 6:24:34 PM CST, Daniel Garcia <notifications@github.com> wrote:
The difference is that FastLED is allowing interrupts to process between each led while it's using bitbanging output - this will introduce a slightly longer gap in between each led's worth of data - you can disable interrupts using:
#define FASTLED_ALLOW_INTERRUPTS 0
or you can try tweaking the retry count:
#define FASTLED_INTERRUPT_RETRY_COUNT 1
(the flickering that you're seeing may be the result of an interrupt running too long and the frame getting reset and starting back at the first led again, or a retry attempt happening too quickly, which is not starting at the beginning of the switch - that code's only really been timed/tuned to WS2812B's, and I haven't gotten a good system in place for the reset times of other chips, like the WS2811 (which has different reset timing).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Huh - weird - when I did the code originally wkth a scope the timings were much tighter - what version of arduino and the arduino esp8266 library are you using? Also - what are you using for the led definition on addLeds? WS2811 or somethig else? |
|
Also the duty cycle perecentages are less important than the amount of time the pin is held high and the total amount of time of each cycle - what are the actual times that you are seeing on the scope? |
|
I agree with the timing. Thanks for being so responsive! It's getting late here (Austin, TX). I'll send some scope captures in the morning. Please don't assume I'm condemning the FastLED library. As far as I can tell, it's a great piece of work! I'm just experiencing some flickering issues (even with the example DemoReel). I fully admin it may be the fault of my coding, but the waveforms seem to be just at bit off compared to alternatives. |
|
No worries! The 8266 code is also more fragile than I’d like - and it needs to be rewritten at some point - what version of arduino and the esp8266 library are you using? I’ve had changes in arduino and compiler versions cause me problems in the past on various platforms. |
|
Good Morning from Texas! I'm using FastLED 3.1.6 The attached scope captures are from a T1000S which works great, but is limited to the included library of animations. The benefit is that no coding is required. Note that it outputs a full 5V with a duty cycle of approximately 73/27. The NeoPixelBus capture shows that it outputs about 3.8V with a duty cycle of 72/28. The FastLED capture shows a 3.8V output with a duty cycle close to 52/48. The 3.8V output is fine since the first WS2811 acts as a level shifter and outputs 5V to all the following LEDs...
You are obviously very aware of the WS2811 waveform pic attached. The WS2811 specs shows the datasheet timing for T0H, T0L, T1H, T1L, and RES. Note that the time is 1/2 of the datasheet values since I'm running the strip at "high speed" = 800kHz. All this said, the only theory I have regarding the flickering, is that the FastLED output for a "1 code" is too close to a 50/50 duty cycle for the WS2811 to reliably decode. Both the T1000S and NeoPixelBus output a '1' with a much greater duty cycle (like 70/30). Is there anywhere in the FastLED code that I can modify a value to tweak the duty cycle? Many thanks for your support! |
|
BTW, I'm using Wemos D1 v2 boards with ESP8266 modules installed. |
|
Ah! I see what's happened. At some point - WorldSemi changed the WS2811 timings to be inline with the WS2812 timings - they published new datasheets (when I originally did FastLED's WS2811 support, I was working from a translated chinese datasheet). The original data sheets that I had had the timings at, for low speed, 800ns high, 1700ns low for a 0 and 1600ns high, 900ns low for a 1 - and half that for the 800khz timing - but they specified 320ns high, 960ns low for a 0 and 640ns high, 640ns low for a 1. Try changing the chipset in your addLeds definition to WS2812 or WS2812B - those timings are in line with what the modern WS2811 datasheet has on it. |
|
The early days of the WS2811 were a nightmare - I, at one point, had at least three different data sheets with wildly different timings for the WS2811 on them :( |
|
Sorry for hijacking this issue a bit but, is ESP8266 able to run both WiFi (with moderate traffic, only for changing patterns) and > 60 WS281x LEDs? This is very interesting that changing to |
|
I can take Antoine's question. I should mention that this list isn't meant
for this kind of question.
A 3.3v signal to a system that recognizes 5V as "true" is risky, providing
only 67% of the "true" signal level. Most datasheets report that you need
0.8*Vcc for "true", and this won't cut it. Anecdotally, sometimes this
works, sometimes it won't.
The "correct" solution is a high-speed level shifter. I've had a lot of
luck with this
<https://www.amazon.com/TXB0104-Breakout-Bidirectional-Voltage-Translator/dp/B00FGD7ZZ4/ref=sr_1_1?ie=UTF8&qid=1511221839&sr=8-1&keywords=TXB0104>
4-channel
shifter. Many level-shifters are too slow for this application. The
MM74HCT245
<https://github.com/the-magister/pentaphilia/blob/master/datasheets/MM74HCT245.pdf>
is
the gold-standard for unidirectional, high-speed shifting.
Any 3-wire protocol requires exact timing, and an interrupt from the WiFi
firing during a .show() will probably trash that pass. Thus, there's
facility for disallowing interrupts during a .show() and/or attempting to
pick up again after returning from an ISR. Regardless, you're playing a
"balancing act"--you have a device with two features (WiFi, FastLED) that
rely on interrupts, and there's no getting around that.
…On Mon, Nov 20, 2017 at 12:56 PM, Antoine Bertin ***@***.***> wrote:
Sorry for hijacking this issue a bit but, is ESP8266 able to run both WiFi
(with moderate traffic, only for changing patterns) and > 60 WS281x LEDs?
Can I drive them straight from ESP8266's GPIO or do I need a 5V level
shifter?
What are the downsides of using #define FASTLED_ALLOW_INTERRUPTS 0 or #define
FASTLED_INTERRUPT_RETRY_COUNT 1? Would I have a flaky WiFi?
This is very interesting that changing to WS2812 or WS2812B would solve
some flickering issues, I had issues like that in the past and basically
gave up driving the LEDs straight out the ESP8266...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#523 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJr5Higet36tmpEq_5MHJxojg9ljm7eLks5s4edwgaJpZM4Qiwxo>
.
--
Mike Dodds
magister@the-magister.com
|
|
And folks - please don't hijack issues - if you have a "how do I" question - use the g+ group (http://fastled.io/+) or open an new issue. |
|
Well, hijacking is probably the wrong term as I am experiencing the exact same issue with the exact same components and only asking questions related to it. I just don't have an oscilloscope and probably the knowledge to troubleshoot it as @the-magister did. The level shifter is a bit out topic but here is a quote from @the-magister that made me curious about it.
As for the suggested solutions, I'm not a big fan of "try this, try that" kind of solutions and pray for it to work. I like to understand what I do and why I do it. How are users supposed to know that they have to specify WS2812 when they bought WS2811? Or disable interrupts? Or know the limitations of doing so? Anyway thanks for your answers, I'll experiment and hope that disabling interrupts don't screw up the WiFi too much. |
|
So this is the first time that i've seen WS2811's expecting WS2812 timings - which is why I'm suspecting that WS2811 production changed at some point over the past 4 or 5 years - and until dsjleds replies with whether or not it even works, there's no guarantee that it's going to end up being useful advice. https://github.com/FastLED/FastLED/wiki/Interrupt-problems talks about issues with interrupts and disabling them. And unfortunately - because there's so much involved here that's poorly documented combined with the joys of electronics, life with addressable leds and MCUs is often a lot of "try this, try that" |
|
Hey everyone, thanks for all the help! Sorry for taking so long to respond, but I had a bunch of family in for the Thanksgiving holidays. Regarding the lights: I selected the WS2812 chipset and all is great now! Specifically, I included: I only rarely see any flicker now. Again, many thanks for the prompt, accurate support. Sincerely, |
Hello,
I've written many animations for a long (1100 LED) strip of WS2811 pixels. These are on my Christmas tree.
When using FastLED I get a lot of flickering of individual pixels, or sections of pixels. When using Adafruit NeoPixelBus, there is no flicker. I used an oscilloscope to compare the waveforms and noticed that the NeoPixelBus outputs approximately 30%/70% or 70%/30% duty cycle, whereas the FastLED outputs 20%/80% or 55%/45% duty cycles. The FastLED 55% output is marginal for the WS2811 chips, thus they sometimes interpret the value incorrectly.
Is there a way to increase the duty cycle to about 80%/20% ???
The text was updated successfully, but these errors were encountered: