WS2811 on Teensy 3.0 using FastSPI_LED library

Status
Not open for further replies.
The fonts are being displayed with the video display feature of the OctoWS2811 LED library.
I used an old copy of Adobe Premiere To create an extremely high aspect ratio video file.
I then Used the Credits Roll text feature to add the text. I saved the file as an mpeg.
The reason the text scrolls so smoothly is because it is being aliased as it moves from one pixel to the next.
However the speckalation is due to artifacts from the video compression and rescaling.
 
I've being following this thread with interest. Thanks to Paul and others for sharing your experience.

I'm building a mark II LED costume. First version used an arduino uno, analog 300 waterproof 5050 RGB SMD Strip and my own shift registers circuit. (http://www.youtube.com/watch?v=keVk7orBRHU).
It is for at night at festivals, battery powered, so I never used it full white or full power and was able to keep the current under 1A

Just wondering what the extra overhead for a Teensy 3.0 and WS2811 is. Could someone who has a set give me approximate current for say 600 (or whatever you have) WS2811 with Teensy at RGB 64,64,0

Thanks
Dave
 
I have a clock that's currently running off of a 1Amp USB charger that has 216 ws2811 leds and is using a teensy 3.0, and don't appear to be having any power issues with it. (Also, I should note - these are 5v ws2811's)
 
PaulStoffregen said:
Finally, OctoWS2811 is released.

http://www.pjrc.com/teensy/td_libs_OctoWS2811.html
Click to expand...

Thank you so much for posting this detailed description!

You mentioned that "When the LED is off, the WS2811 chip consumes approximately 0.9 mA of current. For battery powered LEDs, this current can easily drain the battery" and described a circuit to deactivate the LEDs. I suppose this is deactivating the LEDs completely, not simply pulling down the control temporarily.

No way to simply cut the WS2811s power consumption without deactivating all the LEDs on the strip?
 
Last edited:
Hi nyarlathotep,

As fas as I know there is no way to separate out the power for the LED's from the power for the driver embedded in each LED. The circuit shown cuts off all power to the strip when the LEDs are not in use.

David
 
Alright cool, maybe I'll just unplug the larger strip sets at times. I'm doing an outfit for festivals so it needs to both put on a show at times and provide safety illumination for an extended periods, but I don't need this part automated.

I'll maybe modify the library to use ten or twelve control lines instead of eight, whatever minimizes the wasted memory from using different lengths strips, which depends upon my final layout. So I've two more questions :

(1) Any recommendations for which additional pins to use first? I haven't completely figured out how I'm controlling this yet, so perhaps I'll avoid the SPI pins in case I want them for bluetooth. If I wind up using IR then seemingly most pins work.

(2) Any suggestions for a version of the 74HCT245 with more than eight lines? Just use two I suppose?

Thanks again for writing the library and posting the how-to!
 
Hey I want to thank all the contributors thus far, I'm still having trouble with my pixels and in troubleshooting I tried another strip from an independent source. It worked perfectly, indicating something is wrong, either I have defective pixels or they use another control standard. Can anyone recommend a LED forum where people might be able to help troubleshoot the pixels now that I have the microcontroller figured out?
 
I have heard reports of people getting ws2811 strips where the timings were fairly different from what's spec'd - if you're using FastSPI_LED2 - you can go into the header file to see how the timing supports are defined:

template <uint8_t DATA_PIN>
class WS2811Controller800Mhz : public ClocklessController<DATA_PIN, NS(320), NS(320), NS(550)> {};

You can do something similar to define a new controller - and try juggling the timing numbers - the first number is the number of ns between raising the line high and where it gets dropped for a 0 bit. The second number is how much longer the line needs to be held high for a 1 bit, and then the third number is how long the low should be held for. So, the numbers above mean, roughly, that a 0 will be high for 320ns and low for 880ns, and a 1 will be high for 640ns and low for 550 - roughly.
 
Hey all, I just wanted to let you know my 16x16 rgb matrix pcbs are in! I have a little over 12000 WS2812s on reels waiting to be placed. I am combining these with some nice 300W = 60A x 5V power supplies and deans connectors to gang everything together. My order for a few Teensy 3.0s is finally in place as well. I am looking forward to getting this all up and running! Big challenge will be the actuall mounting of things. I am leaning towards MicroRax right now.

BGO7UsuCEAE7tor.jpg

EDIT - I should clarify I still really wanna do a 128x64 display (8192). Gonna scale up from 32x16 (512) then 64x32 (2048).
 
Last edited:
Paul, I recevied my teensies (2) and was getting started on coding some stuff up.

I was trying to understand the memory setup and was trying to figure out 2 things:

1. Why is the displayMemory an int array (2 bytes) versus a byte array (1 byte)?
2. Why is the ledsPerStrip Multiplied by 6? Seems like only 3 would be needed (3 bytes per pixel, 1 byte per color)

Code: 
DMAMEM int displayMemory[ledsPerStrip*6];
int drawingMemory[ledsPerStrip*6];

Based on these memory requirements the max display size would be 64*32=2056 (~14.4K bytes of memory) using a 16x16 pixel set. Any help is appreciated. I'm just trying to better understand the memory setup.
 
ohararp said:
1. Why is the displayMemory an int array (2 bytes) versus a byte array (1 byte)?
Click to expand...

4 bytes, not 2. Teensy 3.0 is a 32 bit processor, so int is 32 bits. :)

OctoWS2811 requires the data to be 32 bit aligned. The compiler does that automatically with 32 bit data types. If it were char or byte, an attribute to specify memory alignment would be needed.

2. Why is the ledsPerStrip Multiplied by 6? Seems like only 3 would be needed (3 bytes per pixel, 1 byte per color)
Click to expand...

Remember, ledsPerStrip is only 1/8th of the total number of LEDs. 6 ints at 4 bytes each is 24 bytes for each in ledsPerStrip, which results in 3 bytes per LED in the entire array.
 
Can anyone point me to basic POV in Arduino? I am using the Teensy 3.0 and ws2811 and have the system set up and running. I would like to get some basic POV patterns running at random.

I have seen the tutorials where a PIC controller is used with LED's on individual pins but the LED strips seems like it is different, needing a library.
 
Up and Running

I was able to get my pick and place up and running and was able to assemble some of my 8x8 matrices in a 8x64 configuration. I am currently running an mBed and the Plasma Pattern in Paul's OctoWS2811 library. I am awaiting a breakout board for the Teensy and expect this to be running on Teensy without a problem. I am looking forward to getting some animations up and running like Wozzy.

BHDuVlMCQAE2Wu2.jpg

I have one of Tautic's Color sensor to determine the Lux output of these leds relative to the PWM register settings. I'll report back on these results. I happened on this based upon the Gamma correction that is part of the Plasma Example. Enabling the Gamma correction made the display much more "reactive".

I designed the displays to use HobbyKing Connector's XT60 in a series configuration. Using large power planes on the pcb coupled with 12AWG silicone wire keeps voltage drop to 0.15V from one end of the display to the next. I only implemented a single piece of Microrax in this picture, but am planning on building a larger frame or box for this display.

BHDvtIdCYAEilfs.jpg
 
Real late to the party here. We founded Blinkiverse as an offshoot of the HackRockCity Domestar project. We've got some good, working (if not polished) stuff for driving large amounts of the LPD8806 style strips:

https://github.com/blinkiverse/blinkyboard8
https://github.com/hackrockcity/domeTransmitter

We've fallen completely behind on the WS2811 while trying to finish up our LPD8806 projects, but we're working on catching up. This library looks amazing. Paul wrote the first proof of concept code that we used to get the Domestar working, and it looks like he's done it again with the WS2811. I look forward to testing this out when I get back to the office.

We don't have forums of our own yet, but feel free to reach out if you have any questions about driving large amounts of LPD8806. We'll have high-quality LPD8806 and WS2811 strips for sale in the near future as well.

Thanks for all the hard work, Paul!
 
If I understand, the 74HCT245 picture in the OctoWS2811 page has been labeled as part of the circuit diagram. So it describes OE be wired to ground and DIR wired to +5V.

I haven't gleaned much from the 74HCT245 datasheet description that "[the] 74HCT245 features an output enable input (OE) for easy cascading and a send/receive input (DIR) for direction control. OE controls the outputs so that the buses are effectively isolated." but..

In the functional diagram on page 5 of the data sheet and your gif, if I read the little circles as nots and the top guys as and gates, then the seemingly proposed wiring sends +5V down the right hand central line and ground down the left hand central line. So I presume this means all the right hand triangles replace their incoming voltage while all the left side ones ignore their input. Am I reading all this correctly?

All the above is consistent with the fact that OctoWS2811.cpp calls only pinMode(..., OUTPUT); for those pins, of course. As an aside, I'm curious what one does with +5V inputs and outputs. If you wire up a 74HCT245 with +5V on Vcc and +3.3V from the Teensy's 3.3V out, does it translate signals going the other way back to the +3.3V? That's my loose reading of the functional diagram.
 
The '245 can be used in both directions. That's what those control signals do. But the WS2811 data is always in only one direction, so I recommend just wiring those signals to always use the '245 in only the way you need.
 
Alright, I take it I read everything correctly, i.e. DIR to +5V and OE to GND, thanks! I'm curious how one sets the voltage for going back the other way, but obviously I've no need for that here.
 
nyarlathotep said:
I'm curious how one sets the voltage for going back the other way, but obviously I've no need for that here.
Click to expand...

You don't. The 74HCT245 chip always output 5 volt signals, so it can really only be used with Teensy 3.0 in one direction.

That recommendation is for a specific use with OctoWS2811, and NOT as a general purpose chip to convert all types of signals in either direction. This chip can be used in more ways in other types of systems, but those uses just aren't workable here, which is the reason I recommended connecting the control signals a particular way.

I recommended to 74HCT245 chip for this particular use because it is well suited for this particular task, and 74HCT245 is a very common and inexpensive part.

There are lots of other chips which can be used in a variety of ways. Most of the ones which can be used in more ways with fewer limitations cost more and are not as readily available. Most people design cheaper chips into their products, so the cheaper less-functional parts are more readily available.
 
Paul's EE knowledge is leaps and bounds beyond mine,
however I've been using 20m of GreeLED WS2811 lightstrips without voltage level-shifters and with only series resistors.
They have never skipped a single beat on the Teensy 3.0 using the OctoWS2811 library.
 
Last edited:
Status
Not open for further replies.
Back
Top