How to control WS281x RGB LED strip?

[luz]

@Alexandr-Didenko
It definitely sounds like a hardware problem.

This is exactly what happens when the logic high output level of the 3.3V Omega2 is just at the minimum level for 5V WS2813 to be recognized.

For testing, it might help to lower the 5V supply a tiny bit (4.9V instead of 5V, easy to try if you have a lab power supply), because this also lowers the logic high threshold of the WS2813 chips a bit.

A logic level converter is certainly the way to go to make that reliable - but the type you chose is most certainly way too slow for the WS2813 signal. These bi-directional thingies are good for serial speeds (many offers do not properly spec, but those that do say max 28800bd). The WS281x signal is in the 1mbps range, however.

For that you want to use a unidirectional level shifter, such as the 74AHCT125 (or its single-gate version, 74AHCT1G125). I used that one successfully for my "pixelboard", see schematics, with 200 WS2813.

[Alexandr Didenko]

74AHCT1G125 litle improved situation.
But LEDs all the same, often have chaotically color.
Tried strip WS2813 in another packet.
Tried another power supply.

1. Video https://photos.app.goo.gl/Sd31jXaUses3iPKG2

[luz]

@Alexandr-Didenko I have no real idea why it does not work reliably in your case (it does in mine).

To make sure the timing works ok, you can check the stats of the ledchain driver:

root@pixelboard:~# cat /dev/ledchain1 
Ready
Last update: 0 repeats, last timeout=0 nS, max irq=9484 nS
Totals: updates=99756463, overruns=0, retries=3745, errors=4, irqs=2079220056

If you have a high errors number, then something (most probably another driver) is blocking IRQs too long, causing incomplete LED chain updates. Getting some retries is normal. In my example, the number seems high (3745) but that's over a uptime of 46 days, with 99 million full chain updates, so the retry rate is 0.0038%

However, I don't see how even lots of retries/errors would cause anything else than the chain not fully updating. But not completely chaotic colors.

So I still suspect something in the hardware. The really sharp downwards spikes seen on your scope screenshots look suspicious. I can't really make sense of these, occuring only every 5th falling edge.

How do you power the LED strip? Direct fat wires from the LED strip to the PSU, for +5V and GND?

[Alexandr Didenko]

@luz thanx for support.
New video: youtube.com/watch?v=5GpZlGmnKGs.
I send string many times:
echo -en '\x10\x00\x00\x10\x00\x00\x10\x00\x00' >/dev/ledchain0
And here is chaotic colors.
But!
Sometimes led strip work properly.

cat /dev/ledchain0:
Ready
Last update: 0 repeats, last timeout=0 nS, max irq=10575 nS
Totals: updates=87, overruns=0, retries=0, errors=0, irqs=286

Strip power:
From laboratory power supply +5V to +5V strip and to AMS1117_3.3. GND to Omega and to GND strip.
Data wire from pwm0 (G18) to pin 2 74AHCT1G125.
74AHCT1G125: 1 and 3 pin to GND, 5 pin to +5V, 4 pin to strip WS2813 pin DI.
Three LEDS don't need in fat wires.

[Alexandr Didenko]

@luz
in your schematics LEDCHAIN_DATA_3V connect to G46/UA_RX1.
I connecting to pwm0 (G18).
Does it matter?

[Alexandr Didenko]

@luz Thanx! WS2813 and WS2818 work!
https://www.youtube.com/watch?v=rqpyM6vhPLA

[luz]

@Alexandr-Didenko nice device! I assume your I/O are i2c or SPI based? If so, your hardware could run as a digitalSTROM gateway, just by running my vdcd on it. Any plans to open source your device? Or produce and sell it?

BTW: how did you get the WS281x to work, finally?

[luz]

@Alexandr-Didenko nice device! I assume your I/O are i2c or SPI based? If so, your hardware could run as a digitalSTROM gateway, just by running my vdcd on it. Any plans to open source your device? Or produce and sell it?

[Alexandr Didenko]

@luz I/O - MCP23017 - i2c. My plans - to sell it.
I don't know what I do, that WS281x to work
Honestly!
It suddenly began to work.
I thing that oscilloscope give interference.

[luz]

@Alexandr-Didenko said in How to control WS281x RGB LED strip?:

@luz I/O - MCP23017 - i2c. My plans - to sell it.

Let me know when it becomes available

I don't know what I do, that WS281x to work
Honestly!
It suddenly began to work.

I think that oscilloscope give interference.

Could be, depending on the probe. Anyway, I'm glad you have it working now!

[Alexandr Didenko]

@luz!!!
In your schematics I see v-net on the Omega.
What is this?
And how work ETHLED_AMPEN (PWM/G18)?
I connect to G18 (PMW0) LEDCHAIN_DATA_3V.
Why you connect LEDCHAIN_DATA_3V to G46/UA_RX1?
G45 and G46 (UART1) doesn't have PWM

[luz]

Hi @Alexandr-Didenko !!!!!

• V-NET is not connected on the Omega2. It is here for compatibility with the Omega1 which had different ethernet PHY logic that needed a bias voltage on the center taps of the ethernet transformers. I started with Pixelboard before the Omega2 came out...

• ETHLED_AMPEN is just a GPIO I'm using for switching the audio on and off in the Pixelboard as it is now, but I had variants w/o audio so I also connected it to the ethernet jack's LED. The idea was to have it show ethernet activity using the ledtrig-netdev LED kernel module. I tried once briefly, but it didn't work right away.

• PWM on G46: the pin mux in the MT7688 has several options of exposing the PWM outputs, not just GPIO 18 and 19. A while back I posted a annotated pinout of the Omega2 (and 2S) with all possible pin functions labelled - that helped me a lot to design Omega2(S) circuits.
  You can switch the uart1 group to pwm01 with omega2-ctrl to get PWM1 on G46.

[Alexandr Didenko]

@luz said in How to control WS281x RGB LED strip?:

You can switch the uart1 group to pwm01 with omega2-ctrl to get PWM1 on G46.

How? On the Omega2S+ omega2-ctrl gpiomux get say that uart1 doesn't have pwm options.

root@Omega-6E01:~# omega2-ctrl gpiomux get
Group i2c - [i2c] gpio
Group uart0 - [uart] gpio
Group uart1 - [uart] gpio
Group uart2 - [uart] gpio pwm
Group pwm0 - [pwm] gpio
Group pwm1 - pwm [gpio]
Group refclk - refclk [gpio]
Group spi_s - spi_s [gpio]
Group spi_cs1 - [spi_cs1] gpio refclk
Group i2s - i2s [gpio] pcm
Group ephy - [ephy] gpio
Group wled - wled [gpio]

[luz]

Hi @Alexandr-Didenko, are you sure you have the latest omega2-ctrl? Your screendump looks like a version prior to April 2017, when @Lazar-Demin merged my patch fixing exactly those missing modes for the uart groups.

Judging from the makefile in the Onion OpenWrt feed, any build of omega2-ctrl done since April 2017 would have pulled from the omega2-ctrl HEAD and thus included the patch.

However, it seems that @onion might have forgotten to bump the package version back then, and if they never rebuilt the FW from scratch since, it might be that even recent FW builds still contain the pre-April 2017 version

Maybe just try to force-update it via opkg:

opkg update
opkg --force-reinstall omega2-ctrl

The April 2017 version will show:

root@Omega-WXYZ:~# omega2-ctrl gpiomux get
Group i2c - [i2c] gpio 
Group uart0 - [uart] gpio 
Group uart1 - uart [gpio] pwm01 
Group uart2 - uart [gpio] pwm23 
Group pwm0 - pwm [gpio] 
Group pwm1 - pwm [gpio] 
Group refclk - refclk [gpio] 
Group spi_s - spi_s [gpio] pwm01_uart2 
Group spi_cs1 - [spi_cs1] gpio refclk 
Group i2s - i2s [gpio] pcm 
Group ephy - [ephy] gpio 
Group wled - wled [gpio]

[Lazar Demin]

@luz Good catch! We, in fact, did not up the version number of omega2-ctrl
I've upped it now and a v0.2 will be available when we release the next fw build

[Alexandr Didenko]

Dear @luz
I found the bug.

• 1. If disconnect WS2813 from omega2 pin and connect again - then WS2813 behaves wrong.
     If remove the power and then power on - then work as it should.
• 1. First pixel sometimes shifting. For strip consisting of 10 LEDs - in programm we must write 11 LEDs

I thought it was a problem on my side. But no. It in Omega or yours side.

However! Thanx for your job! You are the only one who did it! Low bow!

Unfortunately, I do not know how to solve it so that it is stable and accurate.

[luz]

@Alexandr-Didenko said in How to control WS281x RGB LED strip?:

• 1. If disconnect WS2813 from omega2 pin and connect again - then WS2813 behaves wrong.

Note that WS2813 DIN pins are quite delicate, and very easy to destroy or at least get a latch-up.

• Never send a data signal to a WS2813 which is not powered with 5V properly.
• if the cable is longer than a few inches, use a shielded cable for the data.
• maybe use a serial resistor in the data line to dampen spikes a bit - you have quite heavy undershoots on your scope diagrams you posted earlier in this thread.

• 1. First pixel sometimes shifting. For strip consisting of 10 LEDs - in programm we must write 11 LEDs

Sounds like a damaged first LED to me.

I thought it was a problem on my side. But no. It in Omega or yours side.

I'd be surprised.

Because in the meantime, I have used the exact same circuitry for a large installation with 20 Omega2 each driving 518 WS2813, and all of them ran 100% stable severals days uninterrupted. One of these panels still is in my office and I use it to test new stuff every day, and it runs practically 24/7.

Only one caveat: if you have software installed that makes use of the other hardware PWM unit's interrupt, please make sure to use the latest p44-ledchain (OpenWrt 18.06 build here), because there was a bug in handling the PWM interrupts.