OLA + Fadecandy + WS2811

[Alexander Balagurov]

My chinese supplier send me WS2811 instead of 2801 pixels and i want to drive it on Raspberry pi using fadecandy board. What i should do?
3*50 pixels = 150 pixels chain. Can i attach all 150 to port 0 and it will works? On the image shown that only 64 pixels works in one port.

[Peter Stuge]

Alexander Balagurov wrote:
> My chinese supplier send me WS2811 instead of 2801 pixels and i want to
> drive it on Raspberry pi using fadecandy board. What i should do?

Try a simpler solution.

http://git.stuge.se/spidev-ws2811_ws2812.git

> 3*50 pixels = 150 pixels chain. Can i attach all 150 to port 0 and it
> will works? On the image shown that only 64 pixels works in one port.

My little program above is untested, but if it doesn't work then the
problem is most likely very easy to fix. I'd appreciate to hear what
your results are.


//Peter

[Steve French]

Alexander,

I have heard good things about Fadecandy, but it is limited on pixels per string as you already know....also it requires the extra USB hardware (almost doubling your hardware cost).  There are recent efforts to drive WS2811/WS2812 pixels directly from an embedded linux system despite the "timing challenges".  There is the solution that Peter mentioned in the previous response and also I have recently run across this tutorial which allegedly uses PWM and DMA techniques to get around the rPi/Linux timing problem... (I havent tried it myself yet)...

https://learn.adafruit.com/neopixels-on-raspberry-pi/overview

Peter,

Regarding your below code, do you think this is something that would work on Embedded Linux system in general (rPi and BBB and others) or is it specific to the rPi?  I would be glad to test it on both the rPi and the BBB later this week if I can figure out how to use it.  It appears as if everything is contained within the file called "spidev-ws2811_ws2812.c".  So do put that file somewhere inside of the OLA tree and re-build OLA to include it as a plug-in?

Peter and Alexander,

Just pointing out that there is another solution specific to the BBB that uses the built-in PRU (programmable realtime unit), which are essentially built-in microcontrollers that run alongside the LinuxOS....(just sharing it for completeness...it does not use the rPi!)

https://github.com/osresearch/LEDscape

respect,

frenchy aka Steve French

www.voltvision.com

[Peter Stuge]

Steve French wrote:
> Peter,
> Regarding your below code, do you think this is something that would work
> on Embedded Linux system in general (rPi and BBB and others) or is it
> specific to the rPi?

It is a completely generic way to drive the pixels on any Linux
system with an spidev interface. This includes both rpi and the
beagles and tons of other Linux boards. The only requirement for the
program to work as intended is that there is hardware SPI support
(spidev) and that the SPI hardware can be clocked at 4 MHz or 8 MHz
for WS2811 or WS2812B respectively. These two clock rates are likely
to be widely supported.

> I would be glad to test it on both the rPi and the BBB later this week
> if I can figure out how to use it.

Cool! I'd be happy to chat on IRC for some realtime back-and-forth if
you like. Let me know when is a good time for you.

> It appears as if everything is contained within the file called
> "spidev-ws2811_ws2812.c

..

> So do put that file somewhere inside of the OLA tree and re-build OLA to
> include it as a plug-in?

The source file compiles to a standalone program which isn't
integrated into OLA. It can be used to set colours of attached pixels
from the command line. Download the .c file and the Makefile,
(git clone may be easiest), run make, then run the program:

syntax: ./spidev-ws2811_ws2812 [-h] [-n] [-d /dev/spidevX.Y] [-l] rrggbb... [rrggbb...]
-h shows this help
-n do not open SPI device and instead hexdump SPI words
-d specify SPI device (default: /dev/spidev1.0)
-l enable low-speed mode

Specify -l for WS2811 speed. Do not specify -l for WS2812B speed.

If your SPI hardware is /dev/spidev1.0 (the default for -d) then you
can set the first pixel to pink simply by running:

./spidev-ws2811_ws2812 ff00ff

You can specify any number of colours/pixels, either as a single
really long argument or with each pixel colour as individual
argument, or any combination thereof.


Once it is clear that this works as intended it would most likely be
trivial to create a plugin for OLA which drives pixels directly the
same way.

> Just pointing out that there is another solution specific to the BBB that
> uses the built-in PRU (programmable realtime unit)

Yep, on the beaglebone the PRU is a good option.


//Peter

[Alexander Balagurov]

Sorry guys, i don't understand nothing. I am building led panel which will work with Raspberry PI as artnet interface with OLA, no direct programming. On the OLA page http://docs.openlighting.org/doc/latest/classola_1_1plugin_1_1usbdmx_1_1_scanlime_fadecandy.html i found that fadecandy is supported by OLA but i dont understand what means "Ideally this means we'd model each Fadecandy port as an OLA port, but that introduces syncronization issues, since the underlying protocol models all 8 ports as a flat pixel array. For now we just expose the first 170 pixels."
Mine panel is 15*10=150, smaller than one universe, i didn't get only one thing - all the 150 need to be connected to first 0 port or not?

[Peter Newman]

Hi Alexander,

As per normal Fadecandy wiring, you can only have 64 pixels per port; the 65th one is then attached to the next port etc. See here for more info:
https://github.com/scanlime/fadecandy/#why-cant-you-use-more-than-64-leds-per-strip

[Alexander Balagurov]

On Wednesday, January 28, 2015 at 1:37:17 AM UTC+3, Peter Newman wrote:

Hi Alexander,

As per normal Fadecandy wiring, you can only have 64 pixels per port; the 65th one is then attached to the next port etc. See here for more info:
https://github.com/scanlime/fadecandy/#why-cant-you-use-more-than-64-leds-per-strip

OK, i will solder it to 0-1-2 ports but i want to know is anybody do this before me :)
 

[Peter Newman]

I wrote the Fadecandy code in the USB DMX plugin and tested it with two strings of Neopixels on different ports Alexander; it worked fine for me.

You'll need to split the string into different bits obviously (or at least the data bus).

[Steve French]

Peter Stuge,

I apologize for not getting back to you sooner on this like I had indicated.  The good news is that I will start testing it tonight!  Let me know if any updates...you will probably hear from me @ some point tonight or tomorrow morning/afternoon.  I am EST (UTC-5).  Thx and talk soon!

-frenchy