WS2811 on Teensy 3.0 using FastSPI_LED library

Status
Not open for further replies.
I know OctoWS2811 is designed for multiple large led strips, but do you think it would be ok to use for just 28? I am experiencing a lot of weirdness and instability with both fastspi libraries, it seems that some leds trigger at different times ruining the POV effect. T3 @ 96mHz
 
Can you give me a few more details on the issues you're seeing w/ws2811 and the teensy 3 and fastspi? I'm currently working on trying to get the ws2811 timings solidified, the lack of solid docs are being a pain, but i'm narrowing things down.

Also - another thing to keep in mind - right now, the ws2811 code for both versions of the library halts interrupts, which means that, among other things, the clock stops running - so if you are using micros/millis to determine when to push frames, your timings are going to be off. I'm working on making it so that the library kicks the timers by the appropriate amount, but won't have that done for a little bit yet (my most immediate focus at the moment is cleaning up the teensy 3 SPI code and adding DMA).
 
Well they display colors very well and correctly, but when I display a bitmap or pixelmap of say a square, or any straight line and take a photo of it with a camera it is very noticeable that they dont trigger exactly when they should. The straight line will not be even, some leds trigger correctly and the rest trigger what looks like 1-3 frames after they should, randomly. The accuracy will raise if I add in a delay after every LED.showRGB((byte*)leds, NUM_LEDS); but that isn't going to work considering the computations that are needed to process and automate the next frame.
And no I am not manually using any timers or any other libraries. I've been playing with the timing also and haven't found the sweet spot.
I very much appreciate your library, it is definitely working batter than any other one. Thank you dgarcia42!
 
what are you doing to determine what frame should be shown and when? If you're doing any checking of micros/millis values to determine what should get shown - then that's going to throw things off. I suspect this is more of an issue of when you are sending frames out - the ws2811's are a bit too simple to do things like, say, have individual leds show pixel values out of order.

Also - how many frames/second are you shooting for?
 
I am just using a camera, not using anything that actually determines when leds trigger ect... I can post an image soon to show you an example if you would like.
But basically I am storing a pixel map into an array, say 28 (width) * 30 (height or frames), I run that into a for loop; once it displays the frame it then does some calculations for color automation ect... then right back in the for loop to display the next frame, very basic.
 
Each WS2811 LED takes 30 us. Using only 28 will cause FastSPI_LED to disable interrupts for approx 0.84 ms. That's less than the 1ms millis() update, so it shouldn't impact time keeping.

OctoWS2811 can be used for any number of LEDs, even just 1, though it's massively overkill for 1 LED! The downside of OctoWS2811 is it will use up 8 pins, and memory for 8 strips, even if you connect only 1 strip. Maybe that's ok for this project? You might as well give it a try.

You could also try Adafruit's Neopixel library. For the WS2811, it ought to be about the same as FastSPI_LED because the design is similar.

Odds are, all 3 libraries might give similar results. That would be a really strong indication you need a better design for when to send the updates. You might consider using an elapsedMicro variable, rather than just a fixed delay. For example, something like this will update every 1.5 ms, even if interrupts consume CPU time.

Code: 
elapsedMicros usec;

void loop() {
  if (usec > 1500) {
    usec = usec - 1500;
    FastSPI_LED.show();
  }
}
 
Paul - do microsecond timers also get disabled when interrupts are disabled on the teensy 3? They do on AVR. At 30 fps, a .84ms slip is 25ms/s, or 90s/hour, or 36 minutes/day.
 
They slip if interrupts are disabled long enough to miss the 1ms interrupt.

The microsecond resolution is computed by reading the value of the timer to see how far it is between 1ms intervals.
 
Right, but how is it counting the distance between 1ms intervals, is that tracking another firing timer/interrupt? (or is it a timer/counter that will fire/count even if interrupts are disabled?)
 
It sounds like you are concerned with drift, and compounded error of timing. Possibly a keyframe would be useful.
Maybe use an RTC to determine how many frames you should have at a certain time (like 5 minutes), and pad or eliminate frames.
Or measure the actual frames captured over say 5 minutes, and compute the actual frames/second (ie 29.97 instead of expected 30).
 
Hello everyone, I have constructed a 56x119 ws 2811 screen and am using octo video example. I'm using 7 teensies to run the thing, each accounting for 8 strips of 119.

Unfortunately, only 5 of the 7 teensies seem to function. Which 5 are working does not seem consistent. Does anyone have any thoughts on what might be causing this?

A little more information.
-I am using a multi TT USB hub.
-I have added a 100 ohm resistor onto the sync pin.
-The screen is running off of 4 500 watt 5v power supplies.
-Each teensy is running 13% of the screen and I have verified that they are all correctly offset.
 
Mongoose said:
Unfortunately, only 5 of the 7 teensies seem to function. Which 5 are working does not seem consistent. Does anyone have any thoughts on what might be causing this?
Click to expand...

Very difficult to know from only this 1 post.

Are you using Mac, Linux or Windows?

Do all 7 serial devices appear on the computer?

Are you running the Processing program? Is it printing any errors in the console panel?
 
PaulStoffregen said:
Very difficult to know from only this 1 post.

Are you using Mac, Linux or Windows?

Do all 7 serial devices appear on the computer?

Are you running the Processing program? Is it printing any errors in the console panel?
Click to expand...

Thanks for the quick reply.

I am using windows 7, all 7 serial devices are recognized by the OS, and processing is running and reporting no errors. I added some command line outputs to verify that each teensy is connected and gave correct size/offset information. They all seem to do this correctly.

After a fair amount of trial and error, I noticed that my 7 port multi TT USB hub appears as a 3 port hub and a 4 port hub to the OS. The two failing teensies always seem to be connected to the three port component, so I am beginning to suspect that this is a hardware issue.
 
Some quick advice:
1. Windows likes to change serial ports around for no reason. Make sure you check for this.
2. Have you tried threading out the teensy sends in processing? This way you'll be sending all 7 serial data streams at the same time.
 
Yeah, I have noticed windows capacity to mix up com ports. I have had to change their names several dozen times now.

I have not tried threading the com sends but that does make a lot of sense. I've never dabbled with threading using processing but ill certainly give it a try.
 
Mongoose said:
Fugly code is kinda my specialty. Have you tested it?
Click to expand...

Everyday and then some... But it should be used as an example of threading that works (at least for what I'm doing). It's not plug-n-play or a library or anything like that.
 
Thanks for the tip. Renaming com ports was getting tedious.
Does anyone have any other thoughts as to how to get all the teensies to react? I was hoping I wouldnt have to heavily modify the video example to get 7 teensies working.
 
PaulStoffregen said:
Definitely try swapping out that suspicious USB hub before chasing after software hacks!
Click to expand...

In that case, can anyone recommend a specific model of usb hub? I bought this one specifically for this screen and it was advertised as meeting your requirements.

Also, I couldn't resist a quick hack so I tried threading the send commands. It didn't make anything noticeably worse but the issue remained.
 
Mongoose said:
Also, I couldn't resist a quick hack so I tried threading the send commands.
Click to expand...

Nice! I hope you'll post that code. :)

I have a 7 port hub here that works great. Admittedly, I've only used with with 4 devices. I tried to buy 2 more on Amazon recently (the picture looked identical), but the ones that arrived were completely different, not even similar in appearance. Amazon refunded and they're being returned... but I'm no closer to finding a source for that hub.
 
Very frustrating. I guess ill keep searching.
When I view the properties of mine, it is identified as being two multi tt hubs and they consume very little bandwidth when the screen is running. The only reason I suspect the hub is because two of the three teensies running off of the three port hub fail. From what I can tell, its the one teensy with the lowest com port number that does manage to function on that hub.
 
I wonder if it's not worth just getting another identical 7 port hub, and move the 3 teensy3's to those same ports that are working.

Typically, I get a 7-port USB hubs with the highest rated wattage, but never use all 7. They usually falter at delivering the specified 500mA per port.

I wonder if 4 of your ports may be getting more power than the other 3.

If you have another 2 USB ports on your PC, you might want to try just plugging those 2 failing t3's into those ports.
 
Status
Not open for further replies.
Back
Top