Thursday, August 16, 2012

Raspberry Pi and the WS2801

Update (August 19th):- Pixel Invaders support provided in the 1.3.0-Beta4 release of pixel controller (Here: https://github.com/neophob/PixelController/downloads)
- Tested and working with the latest checked in version of PixelPi
- Run it like this: " sudo python pixelpi.py --chip WS2801 --mode all_off "
- It works by sending the pixel data to the pixelPi software using a UDP network connection. So in pixelcontroller you must setup a UDP output device with the IP set to the IP address of your Raspberry Pi board (Keep the port set at 6803)
- The PixelPi software receives the packet and sets the pixels accordingly.

What it does so far:
- Supports POV LED Strip (Like the original Adafruit Software)
- Now Support matrix displays (2D Panels)
- Added some test modes (fade and chase modes)
- Supports pixel remapping (by using a CSV file with the location of your pixels in the array)
- Adjustable refresh rate / chase rate
- All options selectable by command line args (no python tweaking required (hopefully))

What's up next.
- panning on large images across the pixel array. Ideally I was thinking it would be cool to pass in some images from vgamaps.com and have it pan around them.
- animation support (maybe animated GIF)
- TCP/IP support (support sending display data from another PC)

Wire up the RGB LED string:
I did something similar to this:
http://learn.adafruit.com/light-painting-with-raspberry-pi/hardwareMy starting point:
http://learn.adafruit.com/light-painting-with-raspberry-pi/software

Oops lol. Turns out I ordered 2x 50 LED chains but there were actually 52 LEDs in each chain and I hadn't actually counted them.

However, having 52-LEDs chains works well as when you connect 2 chains together you get a number of leds that's divisible by 8. so in pixel invaders, after a bit of faffing around in the configs I got it working with a 8 x 13 grid.

My non-default settings (config.properties) for PixelController are as follows:

I can't seem to get the PixelInvaders part to work. Everything else works fine, but as soon as I start PixelController I get the first frame of the animation and that's it... If I quickly turn the power off and on to the LPD8806 strip it seems like the animation is playing.

Hey, that's cool project. I'd like to know, if it can support multiple LED strips, if they are not chained together but are in different locations. It probably needs multiple output pins and I don't know how many RPi have. But I already have a RPi and some WS2801 LEDs and I'd like, if they can work in different locations far from eachother, on different pins.

I made some fixes to the LPD8806 support in your latest revision (Sep 25, 2012). I don't know the first thing about using git, so I'll just post them here and you can incorporate them if you wish:

1) New users should not that the "--mode" argument has been removed. You now use the mode you want as an argument all by itself (e.g. sudo pixelpi.py chase). This is not noted anywhere on this site or "--h" that I could find.

2) The --chip argument (line 423) was listening for LDP8806 instead of LPD8806.

3) write_stream needs to send an empty blank byte for LPD8806 such as (starting at line 177):

Hope this is legible. I can send you the .py file if you'd like. One last note: I found the strip sometimes didn't respond after a cold RPi boot, but if I ran the chase test everything started working okay.

Scott, really nice job, i love it. I have a question scott, is posible that you can adapt glediator software as you did with pixelinvader. The gladiator software already has artnet UDP transmition, but I have tryed to connected with your pixelpi and I got some error. Well the only thing I did was sudo python pixelpi.py pixelinvaders --chip WS2801 --refresh_rate 200 --udp-ip 192.168.1.105 --udp-port 6454 .anyhelp will be great because this software accept gif pics, thank and great job

Dominic: I'm afraid if I try to mess with git I'll mess something up. I'll learn it eventually but for now you guys can incorporate my fixes if you want (otherwise, at least they're here for others to follow).

As for the chipname, it is currently fixed everywhere except in line 423 (where the argument is declared). I assume you fixed this too, but maybe it was overwritten accidentally.

Jerermy, it's impossible to mess anyone else's stuff up when you use git. The only thing that might happen is you mess your own git repo up. but because of the way it works you'd have one copy on github and another on your machine. Plus you can back up your own copy too.

If someone wants to use glediator this is what I did and it works so far, I know its not the best solution. but for what I see the artnet packet send 18 extras at the start of the package, so I just took the first 18, and then I added 18 characters at the end of the package so its doesnt get alter. and it works

As cool as the PixelInvaders/glediator are, I quite like the direction the original PixelPi was headed in being self-sufficient. Before everyone heads off to the new branch, could someone help me extent PixelPi to play animations? Maybe a kind of extended "array" mode that takes multiple .png arguments and loops playback using a refresh_rate? I've been trying to do this for many hours and have gotten nowhere.

Thanks, Luis, but Scott added animation support to the old PixelPi branch that works great. You can see the changes on github. For my purposes I didn't want a client/server setup, but prefer to have the RPi run independently.

Hello. I made a matrix 41*17, when I tried the chase mode works perfectly, but when I try the fade mode it doesnt work properly, also with pixel invader it doesnt work properlly niether, its like the firt 8 *41 works good but the rest its randomly, I dont know it has something to do with 1024 bites. Any help will be great. thank you

I have done a lot of test, and this is what happens, in the fade mode when is getting bright the problem start and when is desvaneshig it show all 697 pixels, If you have an email I can send you a little video so you can see whats going on. I will do what you said about the debug.

Well, yes Apply V to each 50 LEd Strips and it work. I am working with glediator, and it work fine, but the is a big delay between what it shows on glediator and what is happening in the LED, its like 5 seconds delay. and also it doesnt look like continues. if I just do like 200 LED its perfect, but with 615 LED show the delays. Scott, do you know if its something to do with raspberry Speed or its something that can be fixed? thank you Scott, great job.

Here I am posting 2 videos. the first one is a 20 by 10. the second one is 41 by 15. as you can noticed the 20*10 its smooth, the movement are continues, but the 41*15 are not. Also in the 41*15 as I said before has like 5 second delay for what it shows at the glediator and what is happening in the LED. Any suggestions will be great, I will like to fix this and put it at front of my store by December, lol. Also I am using a Power supply of 5 V 60 amps. and its apply 5V to every 100 LED (2 strip of 50 LED) note(the power supply cost $35 from aliexpress.http://www.youtube.com/watch?v=GhsAn5k4_30http://www.youtube.com/watch?v=w2rYcgd5iyU

this is the link for the power supply http://www.aliexpress.com/wholesaleproduct/wholesaleProductDetail.htm?productId=289599937&productSubject=350W-Dual-Output-Switching-Power-Supply-88-264VAC-input-5V-350W-output-CE-and-ROHS-approved

Hey Luis; Awesome builds. For the lag;what is likely happening is once the packet gets over 1500bytes it is fragmented. Its a tricky situation; the lag could be on the glediator side; or upon reassembly on the raspberry pi. At what frequency does glediator send the packets? Could it be flooding the link? You could experiment with different numbers of pixels to see if its a fragmentation problem (happens at once if packet size is above 1500) or if it happens at a different size.

In an effort to resolve it could you try pixelInvaders to compare the performance?

Scott, I just did what you mentioned, so with 170 LED works perfect, with 256 LED, works ok, not perfect because sometimes has 1 sec delay. After that starts the bigs delays. I did all these test with pixelinvader. I tried with 170 LED because will send less than 512 bytes, so I think after that has some problem, for some reason the artnet protocol package just allow 170 LED per universe, may be it because of something like this, I am just guessing. Let me know if you find out something, thank you Scott.

Right; so Artnet is a DMX512 container essentially; each pixel takes 3 DMX channels (RGB) so the most it will put in a packet is 512/3 = 170 pixels. However pixelinvaders mode doesn't use artnet; it just packs the pixel data into a UDP packet and pixelPi receives it. I have it installed at home so I'll take a wireshark capture and see where it leads.

I already did, thats how I could do the 41*15 LED, With the buffer size of 1024 its just display 341 LED. right now I have it 2048. As soon as the package go over 512 the delays start incresing. I read a lot about the UDP, and I think we can not go over 512, after that problems start, as delays and lost packages, I was thinking doing it with 4 raspberry pi, each one with 153 LED, but will increase the cost. there has to be another better way of doing it.

I dont know if this is true. But I think the problem is with the speed of the raspberry pi processing this part or its Python that is so slow. The UDP package got in time, but as soon as goes to this part of the program start the delay. I dont know if its possible to do this pixelpi in C and I can do the test.

Yeah that array manipulation is expensive; especially in python. Though I'm not sure if its the array manipulation or the actual writing to the bus. It would be interesting to know what the RaspberryPi SPI bus is clocked at by default; maybe it could be sped up. I read here that overclocking the Pi affects the SPI bus clock so it may be worth trying if you havn't already: http://raspberrypi.stackexchange.com/questions/3400/does-overclocking-affect-the-spi-apb-clock

You could try removing the filterPixel call; if you're using a WS2801 pixel you don't need to remap the RGB so you would just be loosing gamma correction. May be worth a try. The more I think about it though; for bit arrays writting a C version of this would be best; using ioctl on the spi bus you can set the frequency; and the code could be greatly optimized. Perhaps we should start a C implementation of the UDP Receiver / SPI bus writter.

Scott I followed all your advices and it works. I overclocked the pi to 1000, and the performance was way better, like 1 sec delay and after I did the removing the filterPixel and it was perfect, no delay at all. but the colors we rent great. well I dont know if I did exactly what you told me in the filterpixel, this is what I did. but really great your advices, genius.

if someone want to use glediator, this is the modified code to optimize the python code and also the RPI is overclocked to 1000. Still has one second delay from what it shows from glediator and what it shows in the matrix. This work just with ws2801 and no more than 682 pixels.This is the CMD

luis I wonder if you could provide more details as to how you configured glediator to work. I was able to use pixelinvader however when I run glediator the output does not appear to be the intended content (mostly off pixels with some patterns updating infrequently).

It seems to do not work for me.I cloned you git repo and used sudo python pixelpi.py all_on --chip WS2801 --num_leds 25to turn all leds on, but unfortunately it just turns the first led on with blue.When I try to do fade, it just turns the first 8 leds on and not the rest.Do you have any idea why? I use an 5v 4a power supply.