I have some framerate issues with a WS2801 strip of 120 pixels. It runs on an Arduino UNO.
I would like to run at at least 30 fps, but fades don’t go smooth so I probably won’t make it to that rate. I use Processing to control an effect with a baudrate of 250000 (based on the video2serial idea in the OctoWS2811 library of Paul Stoffregen). I think that’s the serial speednot the issue, it should be sufficient. I also tried a setup with ArtNet and I have the same issues.
bps: 30fps * 120 pixels * 24 bits = 86400 bps
I read everywhere that the WS2801 is not the best choice, however I can’t change it right now.
I’m thinking of two other scenarios to solve this problem. Maybe someone has already an idea what works and what doesn’t.
-
Speed of the UNO?
I have a Teensy 3.0 lying around, could that help. Or is the UNO fast enough?
-
Smaller strips?
Can I split up the strip in 4 and use 4 software outputs? I don’t know if this is possible yet, but it seems possible from what I read on this forum:
http://forum.pjrc.com/threads/23545-Teensy-3-0-WS2801
Any other idea’s are welcome as well.
first question - what pins do you have the leds on? If you have them on the non-hardware SPI pins, then it’s actually pushing the led data at a slower rate than it could be (my data rate to bit-bang timing mapping appears to be a bit off). Though I’m not entirely sure what the data rate there would end up being.
second question - how many FPS are you pushing data from your processing script? Are you doing it as fast as possible, or are you setting it to run at a certain frame rate? I’m curious how many frames per second you’re actually sending from processing and is getting handled by the arduino. (One idea - have your code count frames and return to processing how many frames it has processed, you can roughly figure out the frame rate from there).
Oddly enough, I have heard of people having problems writing data too quickly to the led strips! One possible problem may be that some WS2801 chips require a longer intra-frame delay than I had written into the code. That will be fixed in the next push of the code (hopefully over the next couple of days).
There’s no benefit to running the strips in parallel - there’s no parallel output (yet) - so you would still take the same amount of time to write out data to the strips. Also, that forum link references a much much older, and buggier, version of the library (it was a very very early preview release 
I tried both as well the hardware SPI pins as the software pins (clock on 8, data on 9). I didn’t notice any big difference visually.
I push with Processing at 30fps (I tried 25 as well). Because as fast as possible would be 60fps with Processing I think.
On Arduino it’s checked when all the serial data is received read. The code in the loop is pretty simple:
int startChar = Serial.read();
if (startChar == ‘*’) {
memset(leds, 0, NUM_LEDS * sizeof(struct CRGB));
int count = Serial.readBytes((char *)leds, sizeof(leds));
if (count == sizeof(leds))
{ FastLED.show();
}
}
I did a circle setup, so I clearly see a small delay (really a fraction but visible) between the led 0 and led 120 (because they are next to each other). I thought that pushing it too smaller segments, might solve that.
My understanding of the way the WS2801 chip works is it doesn’t lock in the new led values until it has finished the PWM cycle of the current displayed value. It takes 3ms to write out the led data, so some the leds at the end of the chain are going to be 3ms behind the leds at the beginning of the chain, not counting the delay from going around to the next PWM cycle (it might even be higher, with some of SPI’s other overhead).
Smaller segments might solve that for the individual segment, but since you’d still have to be writing to multiple segments to get your full 120 leds, you’ll still see that delay between led 0 and led 120, in fact, it’d probably be even longer/more noticeable.
Also, have you verified whether or not you are dropping frames? You might want to have your arduino code send a response back to Processing to say “done writing led data, ready for the next frame” – If you’re pushing a frame, and then you start pushing the next frame before the library finishes writing out the current frame, then that frame is going to be skipped, which could end up resulting in a lower actually frame rate, as fas as the leds being updated. The Serial buffer on the arduinos is fairly small, and can overflow quickly.
I will build a done routine with Serial. Thanks for that tip.
By the way I think I found the intra-frame delay already in the changes section (at least I don’t know if you refer to this change https://code.google.com/p/fastspi/source/detail?r=216). I just download RC5 and modified that line as well. I did this already before starting yesterday.
I already saw that the WS2801 is not a really smart buy. In your chipset overview you point also to the WS2811/WS2812. Do they suffer from the same 3ms delay? Since their data rate is even slower.
You seem pretty enthusiastic about the lpd8806, but won’t you see the less detail in color in fades or smooth transitions?
Most of my led arrangements don’t have the first and last leds placed right next to each other, so the delay isn’t as noticeable.
The WS2811/12 data rate is slow than the WS2801, but the big thing that’s nice about the WS2812 is the LED and IC are in the same package, which allows for some really dense led placement (as well as less fragile strips - I’ve had WS2801 strips pop the legs off of the chips frequently, it’s very frustrating).
You may be right with the LPD8806 - for me the big thing with the 8806 was the data rate that we could push with it - I actually haven’t done any installations yet with the 8806, most of my stuff is either TM1809 or WS2812 based.
Depending on how fine a graduation of color changes you want, you may want to take a look at the fade candy project that I linked to previously (though, it’s dedicated hardware directed at the WS2811/12 family of led chipsets).
Personally, i’m looking forward to the 12 and 16 bit led chipsets that are coming down the line. I already have a couple of 12-bit per color (vs. the 8 bit per color everything else is) chipsets at home to start working on once this release is finalized, and out the door.
Thanks for the tips. I’m curious in those new developments as well. Is there a site that has a overview with new and upcoming chipsets already?
One of the wiki pages for the library has a list of the chipsets, including some of the ones that are upcoming, support wise (I’m in an airport right now on a pretty crappy connection, otherwise i’d dig it up).
Not directly related to this main question but my WS2801 strip run on 5V, but there are also strips that run on 12V.
What are the pros/cons of both voltages?
Power, mostly, you can do longer runs of 12v wire for a given gauge. Also, if you’re working with 12v power sources, you aren’t going to be burning power converting to 5v. There’s a couple of other folks in the community who can speak a lot more specifically to 5 vs 12 volt advantages/disadvantages
I did a check where Arduino confirms the frameNumber send by Processing and I can get it stable up until 35 fps (40fps didn’t work well). So sending/receiving the Serial data doesn’t seem to cause the perception of a lower frame rate.
Put the strips on hardware spi and try bumping the data rate up to 2 or 4mhz (I believe one of the commented out lines in one of the examples shows how - if not, I should be someplace where I can look at code in an hour or so)
I’ve used this line:
LEDS.addLeds<WS2801, 11, 13, RBG, DATA_RATE_MHZ(2)>(leds, NUM_LEDS);
2 works (like 1), 4 seems too high (a lot of colors).
However I didn’t see much improvement between 1 and 2.
I was working on a brightness level of 32, while I work now on full brightness. That blinks less, so I think it’s just the blinking of PWM.
That makes me wonder. Are there techniques to make leds seem to blink less. I can image this is a common issue? Any interesting sources to read about this? Will 12bit/16bit instead of 8 be the solution?