GS1903 Failures with WS2811/WS2812B mode

[tkerby]

Describe the bug Many vendors are now selling GS1903 based strings rather than WS2811 chipsets. They claim these are fully compatible but the timings are different and the margins tighter. This often results in a marginal chip within the chain appearing to intermittently fail, causing later LEDs to strobe or not change colour. This is most often seen on 12V strips or 5V strings as both use the chipset rather than the silicon built into SMD LEDs

To Reproduce Run the library with a GS1903 chipset string. Ideally more than 100 pixels as it seems to occur more often with the timings associated with longer strings (e.g. the host having to clock out more data).

Expected behavior LEDs light normally

The timings are as follows:

GS1903 - from http://read.pudn.com/downloads743/ebook/2961967/GS1903%E8%A7%84%E6%A0%BC%E4%B9%A6-%E4%B8%AD%E6%96%87%E8%B5%84%E6%96%99.pdf

WS2812B

It may be that GS1903 needs to be added as another supported LED or the option to pass the timing details to the library when called are added,

[Makuna]

What specific Arduino board are you using?
Unfortunately, many won't be able to be accurate enough to support this +-50ns requirement and are just barely able to provide the current settings.

[tkerby]

ESP8285 2MB version in this case. I'm running WLED on the SP501E 'FairyNest' hardware. I suspect even if the accuracy can't be supported a slight change in the core timing may be helpful. I currently see a few issues. One pixel doesn't want to turn off its blue channel at times on one string and on another longer string powered at multiple points I've seen a failure for data to transmit beyond a certain LED and also random strobing of parts of the string.

[Makuna]

Which method? What speed are you using from the drop down menu (not that I really noted this effected the hardware much)?

The measured pulses for Esp8266 using DMA method are about 333ns and 836ns with little ability to improve this.

The DMA speed is selected to send 4 state changes per 1200ns (a pulse that defines the bit for the required data).

The total width of 1200ns is broken into 4 parts, 0001 is short pulse, 0111 is the long pulse; this should equal 300ns and 900ns but due to the hardware limitations it comes out as a higher amounts and often not even consistent but within the +-150ns.

Doubling the frequency to send faster data so that 8 state changes per pulse doesn't help. It increased the back buffer 2x but provided no better resolution as it would jump up or down by over 100ns the which was almost the same as the current frequency.

The only two platforms I support directly that might be able to support this is Esp32 (RMT method has direct pulse control) and NRF52840 (hardware PWM has direct pulse control).

If you want to play with minor adjustments to the speed, you can modify the file directly and see if you can find something that works well.

In the file NeoEsp8266DmaMethod.h, line 104, you will find this

class NeoEsp8266DmaSpeed800KbpsBase : public NeoEsp8266DmaSpeedBase
{
public:
    const static uint32_t I2sClockDivisor = 3;
    const static uint32_t I2sBaseClockDivisor = 16;
    const static uint32_t ByteSendTimeUs = 10; // us it takes to send a single pixel element at 800khz speed
};

Try adjusting the I2sBaseClockDivisor to 17, 18, or even 15 and see if it helps at all.

If you find something that works, let me know.

[Makuna]

BTW, some of the things you mentioned can be caused by other artifacts. Ringing = pulse start or end doesn't go flat causing issues; fixed by filtering (caps and resistors). Noise = data line next to other lines and not shielded well, gnd loop acting like antenna. Improper data voltage = Esp8266 is 3.3v, LED chip needs 3.6v minimum, long data line may lower it even more.

[tkerby]

Thanks for this. I'm using DMA on GPIO3. The board does level shifting and is next to the first LED. Works ok with some alternative WS2811 strings.

I suspect it's timing for a few reasons. The chain (3x50 pixel strings) itself has some 1000uF caps between each string and an 8A supply fed into each string to string connection in a star topology. I believe the chips buffer the DO signal so beyond the first LED the level should be ok.

The issues always seem to occur with the same LED with that LED misbehaving and either not lighting the LEDs after or intermittent performance. I suspect it's just some devices on the edge of the timing.

[Makuna]

Note that the DMA method was updated earlier this year to improve overall bit rate as it was running slightly fast causing some chips to not work well. Not sure it effects this chip though.

Looking at that change may give you an idea on how to increase it (opposite direction of the values) that may get the pulses closer. Unfortunately, only ESP32 RMT hardware gives me the ability to set arbitrary pulse values.

[Makuna]

@tkerby Did you try the latest version and see if it is fixed. We found that the timing was a little fast and some LEDs at or around 80-90 into the strip would have an issue. The timing was improved, and this fixed it for another person.

[Kenai23]

Hi @tkerby, i unfortunately did also receive a GS1903 strip and have to get it running with WLED. Did you mastered it? If so can you give me anny hint? I run a NodeMCU with this 24V strip and already installed level converter. Thank you Kenai23

[Makuna]

I am unsure what version of WLED you are using and what version of my library that version of WLED is using. This won't guarantee it will work though.

Unfortunately, the ESP8266 just doesn't have the ability to provide accurate and consistent enough pulses the spec looks like they require. The ESP32 using RMT method would be able to.

[Kenai23]

ok, thank you. i just ordered the V43 Board with ESP32. give it a try : -)

[Makuna]

https://github.com/Makuna/NeoPixelBus/pull/725

This adds the following methods... NeoEsp32Rmt0Gs1903Method NeoEsp32Rmt1Gs1903Method NeoEsp32Rmt2Gs1903Method NeoEsp32Rmt3Gs1903Method NeoEsp32Rmt4Gs1903Method NeoEsp32Rmt5Gs1903Method NeoEsp32Rmt6Gs1903Method NeoEsp32Rmt7Gs1903Method NeoEsp32RmtNGs1903Method NeoGs1903Method // used when RMT is default, not by default on ESP32, but is on ESP32S2, ESP32S3, and ESP32C3

[Kenai23]

Wow, thank you. I will try if my ESP32 board arrives. Bad that this 1903 doesn't work on the others 😕 Have a nice evening

Michael Miller @.***> schrieb am So., 9. Juli 2023, 19:03:

#725 https://github.com/Makuna/NeoPixelBus/pull/725

This adds the following methods... NeoEsp32Rmt0Gs1903Method NeoEsp32Rmt1Gs1903Method NeoEsp32Rmt2Gs1903Method NeoEsp32Rmt3Gs1903Method NeoEsp32Rmt4Gs1903Method NeoEsp32Rmt5Gs1903Method NeoEsp32Rmt6Gs1903Method NeoEsp32Rmt7Gs1903Method NeoEsp32RmtNGs1903Method NeoGs1903Method // used when RMT is default, not by default on ESP32, but is on ESP32S2, ESP32S3, and ESP32C3

— Reply to this email directly, view it on GitHub https://github.com/Makuna/NeoPixelBus/issues/387#issuecomment-1627773683, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBEPQGDMPRMKXL5EAPCCUELXPLP4ZANCNFSM4U2UMBUA . You are receiving this because you commented.Message ID: @.***>