Hi, thank’s to Daniel i’m running on my first LED installation, I’m planning to control like 1200 WS2801 pixel leds from Adafruit using data from a node.js script that will calculate the amount of leds to be lit and expose that number to an URL like http://theguaz.com/leds.php.
Now I’m using an Arduino DUE because of the RAM and the robust proccesor, I ran some tests using 50 of these things: https://vimeo.com/101716673
Do you think that controlling 1200 leds on a Loop to turn them on (maybe randomly) would be a good idea?.
I say this because I merged the code from the examples of the Ethernet shield and the FastLed library and when I set the number of leds above like 500 the speed af the script starts to be kind of slow.
All ideas, comments and opinions are welcome.
The ws2801 datarate is 1mhz, or 24us per led which means that updating 1200 LEDS will take 28.8ms, or to put another way you are capped at 34fps if you spent 100% of your time writing LEDS. If you wanted to spend, say, half of your cpu time building frames you’d be at 17fps, well below the threshold for smooth motion.
For large numbers of LEDS and decent frame rates , I’d either recommend the 24mhz lpd8806 or parallel ws2812 setups (octows2811, fade candy, or hopefully soon, an 8-30 way parallel output option for FastLED).
8-30-way parallel output you say? 
Thank’s Daniel, as you can see on my video I’m not aiming to realtime refresh of the leds, instead i’m looking for robust control at large number of leds without making RAM mistakes or other related isues of using two SPI based devices(the ethernet shield & the strands).
The arduino see the continuous strand as one SPI device or as 1200?
Should I use pin 52 of the DUE as CI for the strands?
thank’s Daniel for yor answers
Ok, last night I’ve ran some tests with the DUE and my strands. http://instagram.com/p/rQoLD9hKzN/?modal=false
I used the board SPI pins and also bitbanging, the refresh rate when I explicitely wrote that was using 50 leds was almost inmediate, but as I set the number on higher amounts the refresh rate was slowing down; when I finally set the number to 1038 the system took almost 20 seconds to update all the leds.
Is there anything that i’m doing wrong?, here is the code I used.
http://theguaz.com/leds.ino
It takes 24ms to write out a frame of leds. Then you have another 10ms delay in there. Your code is going to have to loop over 1038 leds to turn them all on, which is about 35 seconds (1038 * (24+10)). The fact that it runs in 20s means my bitbanging timing is a bit off, and it’s actually running faster than it should
Also, your clearOnLeds function is going to be REALLY inefficient, as it is going to show 1038 frames to clear all the leds - it would be enough to just do this:
Serial.println(“Clear all leds”);
for(int i = 0 ; i <= NUM_LEDS; ++i) {
leds[i] = CRGB::Black;
}
FastLED.show();
Note that I moved the FastLED.show() out of your loop, which should make clearing all the leds much faster.
FastLED.show() writes out data for all the leds, so you should only call it when you’ve finished setting all the leds you want to set for a single frame.
(Also, in the link you pasted, your turnOneLed function doesn’t do anything)
thank’s for your reply, I agree on the things you stated.
Now I can understand how to use the show() function on updating my leds.
About the turnOneLed function, I wrote that to turn one randomly based on a previously defined array that holds the exact random order in which each led has to be lit to reveal the phrase.
I will use one Arduino to control the leds this time but to be completely clear on the “how”, the refresh rate for the 1038 LEDs is because of I’m trying to control them with only one controller? should I divide the task on a few ones? a powerful and faster controller like the Pi could be more suitable for driving a large number of ws2801?
than’s again Daniel for all the help
The problem with the WS2801 is a low data rate, it has little to do with how fast the controller is, at least for the code you have written now (I was able to drive 2880 leds w/a due at about 15+ FPS with some code that i’ll be releasing shortly). To drive data to WS2801’s faster, you have to push data to them in parallel. I haven’t yet planned out parallel output for bit-bang’d SPI, but that will hopefully happen eventually.
If you really want to use SPI and lots of leds, I’d highly recommend the LPD8806 (other members here can give you more details on getting them) - it has a data rate nearly 20 times faster than the WS2801.
The fact that so many led chipsets have such a low data rate is why i’ve been working on a couple of different types of parallel led output.
Hi Daniel, when u are talking about driving 2880 leds are you refering to 2880 WS2801 leds?
No, 2880 WS2812 leds, using 24 separate lines of leds with an experimental 30-way led driver on the digix (which is like an arduino due but with more pins) - though they have a lower data rate (800khz) than the WS2801’s, but they’re also a bit easier to parallelize than the WS2801 is. (On the flip side, once I work out whether or not my idea for parallelizing WS2801 or LPD8806 will actually work - I may be able to use/abuse the due’s DMA engine for more efficiency - but that’s a bit off, still
Three more things that I’ve learned today thank’s to Daniel:
I don’t think its fare to say that the WS2812 is better than WS2801. It really depends on the application and your desired result. If refresh rates are important WS2812 are not the ideal.
Because you can parallelize more easily with ws2812 - it’s better than 2801 for thousands of LEDS off a single controller. If you want the refresh rate, go lpd8806. I’d love to see the ws2801 die off.
(Won’t even mention the packaging advantage the ws2812b has
I agree completely… However, if you are using pixels and not strip then the packaging is not an advantage until they start making pixels with the integrated WS2812 LED.
I just think if you make a generalization here you should justify it clearly… I know people look to these communities to make decisions…
no - but the parallelization advantage is still there (it’s how i drove 2880 leds off of a due a few weeks ago - half the pixels were ws2812 strips, the other half were ws2812 pixels on strings). Also, don’t discount the extra flexibility from only 3 wires between each pixel vs. 4.
Personally, I actively discourage new projects from using the WS2801. (That’s even before we get into what the dark power-draw of the controller chip is - 60mw/chip for the WS2801 vs. 5mw/chip for the WS2811/2). While it hasn’t quite passed into the level of history that the HL1606 and LPD6803 have, it is likely the next candidate for voting off the island
(Also - I do generally justify my recommendations/suggestions to people with far more nuance than Luis copied into his comment above - he was summarizing a much longer g+ chat conversation - the WS2812 comment specifically there was in reference to large installations (multi-thousand leds) being driven by computer - where, right now, a multiple fade candy controller setup is likely the best solution available)
Hi, i’ve read the comments above, and I have to say that after the chat I had with Daniel the other night I did my own research; and yes, in order to drive thousands of individual lights with accuracy and ease the WS2812 and some fadeCandy usb controllers looks like the right solution to me, because I’m not a very experimented electronic guy as you are.
Right now I’m doing a propossal to do a new installation, again more than 1000 leds, and now I will go for neopixels and fade candy’s. I will save the WS2801 for later use maybe on another installation and driving them in sets.
Daniel was right on his opinion and advice because after reading over the internet the neopixels and fadecandy are my choice for next project. And because I have to run with the project as usual I’ll buy them from adafruit again.
regards.
OK, finally the 1028 leds arrived, I’ve managed to controll them all with the DUE and the library.
Using 5 switch power sources I energized all of them and all worked well driving them to full White and Blue, except that the last leds of the strand flickered a bit.
The 50 leds compose a character, and each character cable was extended by soldering at the input end to make them longer.
I injected current every 50 leds, at the beginning and not at the output end.
And here is the funny thing, when the crew screwed the acrylic characters to the sign the characters started to show some odd behavior, random flickering at the last leds of the strands (even in short groups of 200-250 leds) and also a random flickering when I’m driving the LEDS as the characters are filled with a solid color.
Today I connected a strand of 150 leds on the ground without any frame at all, ran my code and everything worked as expected, the strands gets filled with the color sequentially from 0 to 150. Then at 40 meters above the ground I ran the same test on 3 characters (150leds) and again the odd behavior, flickering, and random colors are shown as the sequence moves forward.
DO you have any ideas on what could be wrong here?, could be the leds being sandwiched between the acrylic the problem?, maybe something was disconnected or get loose when the crew lifted the whole piece to the final location?
I’m kind of lost here.
Do you have a common ground for all power supplies? Have you tried adding strips incrementally? Are they all daisy chained?
Hi Justin:
- I do have a common ground
- I added strands incrementally, but on the test outside of the sign because of time and rush I did not exposed the middle connection between each set of 50 leds to the rear of the panel, now I see a flaw of design on that. So I have now 20 characters made of 25 leds on each of them but with only an IN and an OUT on each.
- I have my leds daisy chained, but today I ran tests on each character separately resulting on flickering and random behavior on the ones i’ve applied the test.
I will try to upload a video of the misbehavior and the normal one today (Sun).
Ok, today I tested all my characters separately and some of the characters were shorting as the guys that screwed them maybe drilled some of the cables.
I changed the DUE to a UNO, and I may use like 3-4 of them chained together via xbees to lit groups of leds. I did not felt secure using the beta IDE.
Maybe I will buy a MEGA to avoid the odd ide, the idea is that during the next 20 days I have to lit a character a day based on data received from youtube API; so, I will lit random leds on the first characters until I get new strands to repair the damaged ones.
I will keep you posted on the updates of the project.
cheers