We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

How to control WS281x RGB LED strip?



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

    opkg install --force-depends kmod-p44-ledchain*

    Error.

    0_1526819269787_004d57de-cb8b-48f3-9fe5-ec66b505970f-image.png



  • @luz
    In first time when do this:
    insmod /lib/modules/4.4.61/p44-ledchain.ko ledchain0=0,10,2
    omega2-ctrl gpiomux set pwm0 pwm
    echo -en '\xFF\xFF\xFF\xFF\x00\x00\x00\xFF\x00\x00\x00\xFF' >/dev/ledchain0
    Oscilloscope show signal.
    After reboot - signal is disabled.
    Repeat command - doesnot give effect.
    I do this for pwm1:
    insmod /lib/modules/4.4.61/p44-ledchain.ko ledchain1=0,10,2
    omega2-ctrl gpiomux set pwm1 pwm
    echo -en '\xFF\xFF\xFF\xFF\x00\x00\x00\xFF\x00\x00\x00\xFF' >/dev/ledchain1
    Oscilloscope show signal on pwm1.
    After reboot I cant get signal on pwm0 or pwm1



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

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

    opkg install --force-depends kmod-p44-ledchain*

    Error.

    Yeah, that's a bit confusing. opkg displays the error (which is more of a warning in this case, meaning that installation would have failed if the --force-depends option was not set) altough the operation has succeeded.

    So everything's fine so far šŸ˜‰

    Now for the signal disappearing after reboot: omega2-ctrl settings are not permanent, and activation of p44-ledchain via insmod isn't, either (only installation via opkg is!).

    To get the ledchain ready automatically after boot, just put the omega2-ctrl and insmod lines into a startup script.

    /etc/rc.local is a good place for that, unless you have your own startup script for your application, where you can put such initialisation code as well.



  • @luz!
    Thanx for all!
    Signal on oscilloscope - i see.
    Connect strip.
    write string:
    echo -en '\xFF\x00\x00\xFF\x00\x00' >/dev/ledchain0
    And repeat this about 3 second.
    And strip behaves strangely.
    First two diodes some times is red.
    But mostly they are not red.
    And mostly first 3-4 LEDs are lighting too. And all colors of all 2-4 LEDs are random.

    insmod /lib/modules/4.4.61/p44-ledchain.ko ledchain0=0,2,2
    Try ledtype 0,2,*(0-4).
    Try inverted 1,2,2.

    String
    echo -en '\x00\x00\x00\x00\x00\x00' >/dev/ledchain0
    switching off 2-4 LEDs not the first time. And this string switch off 3 and 4 LEDs too. sometimes šŸ™‚

    Strip I connect through logic level converter 3.3V<->5V. He is worked with arduino and ESP8266.
    And try connect directly to omega2.

    Strip still behaves strangely.
    1.
    0_1526990510251_067b46f1-a481-4fe9-8b27-753eb624cb1d-image.png
    2.
    0_1526990576122_eabf665e-da03-4a3c-940d-aaae23defe57-image.png
    3.
    0_1526990431883_3e3923a9-88e0-4a55-b653-8a19a8af8460-image.png

    0_1526990664902_91773e35-d7e1-4263-8ec3-dda31e5d1f95-image.png



  • @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.



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

    0_1527249566359_e96243e0-2893-490b-ae89-dc8247c0a527-image.png

    0_1527249593319_2837172b-2654-449a-b990-4a238bdcc038-image.png

    0_1527249620688_f25c0b0d-8d98-4c37-a292-3cec0dd36d2f-image.png

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


  • @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?



  • @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
    

    0_1527529647250_ddc1f617-e21c-47e3-94fe-7b3d4c6eb667-image.png

    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.



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



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



  • @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?



  • @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?



  • @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.



  • @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!



  • @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



  • 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.



  • @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]
    


  • 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]

  • administrators

    @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



  • 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.


Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.