WS2811/12B support

[MathieuMH]

Hi guys!

Currently I'm very excited about the upcoming support for fadecandy. This seems to be a good solution for controlling a lot of WS2811/12B leds. Recently a guy named Jeremy Graff wrote a lib to support WS2811/12B directly from the raspberry pi. So keeping this in mind I thought I share it with you. Might be interesting to implement this as well? What do you think?

An basic implementation can be found here: https://learn.adafruit.com/neopixels-on-raspberry-pi/overview

Enjoy the holidays!

[nomis52]

The library is https://github.com/jgarff/rpi_ws281x

Looking at the code quickly, it appears to require root.

[sashabeep]

Also interested with that...

[peternewman]

See also https://groups.google.com/forum/#!topic/open-lighting/kMiO5pIJ5yk and http://git.stuge.se/spidev-ws2811_ws2812.git which doesn't look like it needs root.

[Osmii]

I really would like to see that also :D Any proggres?

[nomis52]

Patches are welcome!

[bbx10]

I wrote up my experiment in driving ws281x LEDs using OLA and rpi-ws281x library. OLA does not run as root because a separate program runs an OPC server and drives the LEDs using rpi-ws281x. No changes are required to OLA since it has OPC client support. This is all experimental work so use with extreme caution.

http://x10linux.blogspot.com/2015/08/driving-ws281xs-leds-on-raspberry-pi.html

[ArosPrince]

bbx10: I just tried it. I just have one question. It does not work right away. I always have to launch strandtest.py, from ws281x lib then close it and then I can finally launch to opc server it starts to drive the LEDs. It seems to me that there may be some important initialization missing in the OPC server. Is that possible?

//also NODE is almost impossible to install. It took a a whole day and it is nowhere that simple as you describe it. Probably some apt-get update ruined the initial "simpleness".

[Ph0N37Ic5]

So I sort of kludged WS2812b support using the spi plugin. The whole thing with this is really that each data bit needs an 1 added before it and a 0 added after, when running spi output at 2.4MHz.

What I did were using too many dmx channels, mapping each pixel to 9 channels to get the spi interface to output the right bytes. For someone who is actually familiar with the programming of the spi plugin, this shouldn't be to hard to implement.

This is the command I used to send data to three pixels rotating black and 2 colours: watch "ola_streaming_client -d 146,73,36,146,73,36,146,73,36,211,77,180,154,109,54,210,77,182,154,109,52,218,77,182,146,109,164, -u 0 && sleep 1 && ola_streaming_client -d 211,77,180,154,109,54,210,77,182,154,109,52,218,77,182,146,109,164,146,73,36,146,73,36,146,73,36 -u 0 && sleep 1 && ola_streaming_client -d 154,109,52,218,77,182,146,109,164,146,73,36,146,73,36,146,73,36,211,77,180,154,109,54,210,77,182 -u 0 && sleep 1"

The 146,73,36 sequence is basically what needs to be sent per colour channel to set it to all zeros, it's equivalent to octal 44444444, any other data is the same but modified with octal 6 in stead of 4 when a "one bit" is needed.

[peternewman]

@bbx10 @Ph0N37Ic5 as @nomis52 said, patches welcome. Especially if your stuff is reliable enough it should just work for other people too?

[Ph0N37Ic5]

I'm afraid I'm not much of a programmer, at least not in C++. Nor do I really understand the structure of the SPI plugin. It would be better if someone else implemented this, unless someone wish to give me a crash course. Still would like to see this implemented.

[Ph0N37Ic5]

Not really sure if these work 100% but I seem to have got them to compile at least, not sure what other changes are needed, but I think the encoding should be right.

SPIOutput.cpp.diff.txt SPIOutput.h.diff.txt

[peternewman]

Brilliant thanks @Ph0N37Ic5 . Would you mind doing them as a Pull Request please (fork OLA to your own repo on GitHub, clone that to your local machine, make the changes there, commit and push back), it makes it much easier for us to comment and review your changes.

[Ph0N37Ic5]

Done. I'll try to mash together some hardware to test it.

[peternewman]

See https://github.com/OpenLightingProject/ola/pull/1382

[peternewman]

Is there any update? How could I get Ws2812b leds running via OLA on my Pi 4? I have already a working C-program, with which I can control at least 1000 WS2812 leds (for help: https://github.com/jbentham/rpi). Now I wish I could build a system that takes Artnet Signal as Input and turn it into WS signal (eventually combined with my working code). As a newbie I would like to know if OLA can help me for this target. Otherwise what else could you recommend to me? Thanks for any feedback.

Originally posted by @kevinIvan in https://github.com/OpenLightingProject/ola/issues/1382#issuecomment-871348558

Which is explained in more detail here: https://iosoft.blog/2020/09/29/raspberry-pi-multi-channel-ws2812/

This currently seems to require root, which wouldn't work directly with OLAd. The client could be run with root privileges and hook into the OLA core that way, see an example of our client API code: http://docs.openlighting.org/ola/doc/latest/client_tutorial.html#sec_Receiver

Do please comment here if you attempt and get anywhere with this approach.

[gmeader]

This might be helpful to those trying to use OLA on a RPi to control ws2812 https://www.instructables.com/Remote-Big-Led-Matrix-Artnet-Raspberry-Pi/

[peternewman]

This might be helpful to those trying to use OLA on a RPi to control ws2812 https://www.instructables.com/Remote-Big-Led-Matrix-Artnet-Raspberry-Pi/

Thanks @gmeader . That project just appears to be about how to use WS2801 with OLA, which we already support (and is what the project is instructing the setup of), whereas this issue is about using the WS2811/12B pixels which use an alternative protocol/connectivity.

[ryanriccio1]

sACN to WS2811/2b on RPI4 (WIP) https://github.com/ryanriccio1/rpi-sacn-neopixel

[peternewman]

sACN to WS2811/2b on RPI4 (WIP) https://github.com/ryanriccio1/rpi-sacn-neopixel

Looks good @ryanriccio1 . Out of interest, did you consider using the OLA Python API or adding it as an option?

[ryanriccio1]

@peternewman I did not think to do that, mostly because I did not have to worry about the implementation and just needed a quick way of getting it to work that was easy to test. However now that you mention that, I'll definitely look into that. I just don't want to have to worry about threading as the module I use in mine handles it for me. It looks like I could make the leap it just depends on if I have the time or not.

[ryanriccio1]

@peternewman I've figured out how to get the devices but I haven't figured out how to control the patching going to the python API

[peternewman]

@peternewman However now that you mention that, I'll definitely look into that. I just don't want to have to worry about threading as the module I use in mine handles it for me.

I don't immediately see another loop in your code, so I think you could just call the write function each time you get new DMX data.

@peternewman I've figured out how to get the devices but I haven't figured out how to control the patching going to the python API

That's great, however general idea would be you wouldn't Ryan, either you always listen to universes 1-10 in OLA land say: https://www.openlighting.org/ola/developer-documentation/python-api/#Receiving_DMX

Or better yet, you let user specify which OLA universes to listen to, and they patch them in OLA as required.

If you really want to duplicate the OLA patching, you could see some example code here: https://github.com/OpenLightingProject/ola/blob/master/python/examples/ola_patch_unpatch.py

But consider I might want to HTP/LTP merge two inputs, or fail over with priority or whatever. Or simply run from ola_recorder, which as another client doesn't show up to patch to.

[ryanriccio1]

@peternewman

I don't immediately see another loop in your code, so I think you could just call the write function each time you get new DMX data.

To my knowledge, the sacn module I was using executes the callback function on a separate thread and continues the receiver thread on main. That means the callback (and by proxy PixelStrand.write()) are on a separate thread that goes away at the end of the callback. This means I can write to multiple GPIOs from multiple universes at the same time without having to worry about other strands stuttering. My goal is to have at least 3 GPIO pins have valid output, and to be able to have more than 170 pixels per GPIO (have multiple universes write to the same pin). The neopixel library handles writing to different sections of the strand just fine, it's the asynchronous data coming in from multiple universes that could pose a problem.

I've also figured out how it listens to the specified universe and doesn't need patching the way I assumed. This could make for an easy transition to OLA, however I'm still worried about the threading issue. I'm not sure how the ClientWrapper scheduling works. And at this point, I'd only be using OLA for the web interface and merge algorithms.