WS2811 on Teensy 3.0 using FastSPI_LED library

Status
Not open for further replies.
I did some signal quality testing, to come up with a recommended source impedance. Luckily, a higher bandwidth scope is on temporary lone at the moment, so it's easy to see the transmission line effects. :)

Here's how the signal looks after 12 inches of wire connected directly to the Teensy 3.0 pin, and a 12 inch ground wire located about 1-2 inches away from the signal wire. This is measured right at the WS2811 input, both the scope probe tip and ground.

scope_21.png

Here's the exact same wires, but with a 220 ohm resistor between the Teensy 3.0 pin and the wire going to the LEDs. Again, this measurement is the signal arriving very close to the WS2811 input.

scope_22.png

If a tightly twisted pair of wires were used, a 100 ohm resistor might be more appropriate. But I believe this wiring setup is pretty typical of how many people will probably connect their LED projects.
 
I didn't consider using any resistors for my setup which is WS2801 currently. Should I put some between DOUT / SCK and the strip?
 
If I read the (minimal) ws2811 reference / spec sheet correctly, doesn't the chip act as a signal repeater / reshaper on the DI line? If so the signal quality should only matter up to the first chip in the line, isn't it?
Built in signal reshaping circuit,after wave reshaping to the next driver, ensure wave-form distortion not accumulate.
Click to expand...
Maybe you could wire up the scope to the DI-out of a chip and compare it to DI-in...
 
Last edited:
raydee said:
If I read the (minimal) ws2811 reference / spec sheet correctly, doesn't the chip act as a signal repeater / reshaper on the DI line? If so the signal quality should only matter up to the first chip in the line, isn't it?
Click to expand...

Yes. It does create a new copy of the signal between each LED. This signal quality issue is indeed only to the first chip on the strip.

However, as you can see, it's pretty significant. I had some LEDs update incorrectly using the 3.3 volt signal without a resistor. With a 5 volt signal, the spikes and ringing is probably even worse, but there's more noise margin because 5 volts isn't nearly as close to the chip's switching threshold.

Maybe you could wire up the scope to the DI-out of a chip and compare it to DI-in...
Click to expand...

I did this. Actually, I looked at the signal after 10 LEDs. It is indeed a new signal, even with slightly different timing. The chip appears to trigger on the rising edge of the waveform, but otherwise do everything based on one-shot timers inside the chip.
 
Also, in additional to dramatically improving the signal quality, a 220 ohm resistor also gives some degree of protection from destroying the Teensy if the 3.3 volt signal line accidentally touches one of the 5 volt power lines.
 
PaulStoffregen said:
Also, in additional to dramatically improving the signal quality, a 220 ohm resistor also gives some degree of protection from destroying the Teensy if the 3.3 volt signal line accidentally touches one of the 5 volt power lines.
Click to expand...

Thanks for this insight! I've been trying to drive a WS2811 strip with 240 LEDs using a Teensy 3.0, and the errant behavior was making me pull my hair out. I was about to revert to a board with 5v logic, but throwing a 220 ohm resistor on the signal line immediately solved my issue.
 
Received my 68 pixel/meter light strips

I received my 20m of GreeLed GE68RGB2811C 68 Pixel/meter WS2811 light strips the other day and have had a chance to play with them a little.

They are very bright, and dense, with a pixel pitch of 0.58in or 14.7mm.

They can use a lot of power (over 4 Amps/meter at 255,255,255) so I had to purchase a power supply. I ordered this one: AliExpress 5V 70A from Ray Wu
Until that arrives, I can't fire them all up at once.

Here's a closeup photo with the silicone waterproofing removed:
2013-02-02 20.06.31.jpg
Click for a larger image ....... Samsung Galaxy S3

Also, here's a video that I made that show the strips in action: WS2811 YouTube Video

I updated my earlier post with order details and a time line because these are ordered directly from the manufacturer for $14.50/meter + air freight.

Unfortunately one of the 5 m rolls was damaged and had a a few defective pixels. I was able to cut out the 5 defective pixels, and salvage the rest of the strip, but it's cut up into 5 short segments.
I contacted Britney in sales about this. She was profusely apologetic, and will send me a replacement.

Update: So now GreeLed saying that they will ship the replacement only after I return the defective roll to them in China. They are not offering to pay for the return shipping!

Update2: Greeled Just contacted me and said that there's no need to return the defective 5m light strip. They will replace it for me at no charge.
 
Last edited:
Very nice! And thanks for the video. I really enjoyed that "trip" ;-)

I'm going to order a roll of these myself in a month or so, as I currently don't have the time to play with them. But I can't wait to get these into my LED staffs, as I'm getting bored already with just 8 pixels per staff end for POV. I should be able to get 16 with these, and have some extra space for logic and wiring.
 
Not to create a GreeLED vs. Ray @ Aliexpress battle :)

but one thing to note, if you wish to customize your LED spacing without needing to design/build your own pcb with decoupling cap, and keep the flexibility...the LEDs I ordered had a slightly different configuration between LEDs than the GreeLEDs.

solder-pads.jpg

I basically cut from the left edge of the left set of pads to the right edge of the right set of pads, soldered the pads together, and voila! ~12mm spacing, or 83 LEDs/m for those keeping score. Obviously a bit of work on my end, but wasn't too painful, actually. And maintained most of its flexibility. Definitely a bonus.

Ray mentioned he could do custom spacing...would love to get this down to 10mm spacing. I'll update if I hear anything promising.

Cheers,
David
 
virtualdave - you can also buy the LEDs themselves from Ray and put them on your on flex PCB/PCB :) Not much cheaper than the strips, but handy if you're doing a custom project.
 
and i'm currently sitting on 500 leds and 500 decoupling caps wondering how to do that. no idea how to go about designing/ordering flex pcb. as long as I bill myself out to myself at $.20/hr, I'm thinking it still comes out cheaper to snip the strips myself? ;)

Any pointer on where to look for making your own flex pcb?
 
I noticed that the strips have no flexibility at all in the lateral direction. If you want any lateral curvature, I have found that you need to cut and resolder with the correct curvature. Has anyone else found a better way?
 
dgarcia42 said:
Hi! I'm currently working on a rewrite of the FastSPI_LED library, in part to make it more easily portable to arduino variants (like the teensy 2.0/3.0) as well as other arduino platforms. [...] I'm hoping to have the rewrite done and up by the end of the month.
Click to expand...

I've just gotten my first WS2811 based LED strip in (60 LEDs/m) and I totally love it, as it works just wonderful with the adapted Adafruit_NeoPixel library.

However, my LED staffs I have more or less physically ready now are based on the WS2801 strips, which I want to replace with the 2811 now, so I'll have 16 pixels instead of 8 per side of the staff, or even more. This will get POV to really become something to look at. My code is currently based on your FastSPI lib, so I can't wait to be able to use the same lib for the WS2811s.

I also had some fun with an SD adapter that hooks onto the SPI bus (the one PJRC sells). I got this working, but once I init the card, FastSPI for the WS2801 becomes really slow in comparison to what it was before, and many of the POV and related effects I wrote algorithms for no longer look cool when swinging the staff. I implemented a cable select functioning by setting one of the pins high and low, connecting to an NPN transistor to interrupt the clock signal to the 2801 strip. Was planning to do the same for the data line on the 2811, but if somehow accessing anything else on the bus is screwing with the FastSPI speed, then it's not going to work for me. I'm now thinking perhaps to upload images using bluetooth, in run-time.

Anyway, thanks for your great work, and looking forward to the version that includes WS2811 support, like a lot of folks here probably ;-)

*EDIT* I now see Paul made a version of the FastSPI lib available with some changes for the 2811. Going to give that a spin. I should have read this thread better...
 
Last edited:
PaulStoffregen said:
Here's a few quick photos of the test setup I'm building for the new library.....
Click to expand...

Paul is up to something....

Paul, I hope you've got some sun glasses.
And don't forget your anti-seizure medication. :)
I can't wait to see a video of that test setup in operation.
 
BambooSam said:
How many frame/second are you getting out of the WS2811?
Click to expand...

I've been working with pacing the updates to the video frame rate, which is either 30 or 60 Hz. For that array (60 by 32 LEDs) Two Teensy 3.0 boards are used, one for each half of the array. I've been working on a sync signal, so they can sync their update even if there USB has some latency delivering the data. The frame sync allows any number of Teensy 3.0 boards to be used, so you can grow the array to incredibly large sizes by adding another Teensy 3.0 for each 1000 LEDs. Beyond about 20 Teensy boards, you'd need USB 3.0 hubs or multiple USB 2.0 cards and hubs, but with USB bandwidth, it's meant to scale to almost any size. So with the sync feature, the update rate is 30 or 60 Hz.

However, if you program it to update at maximum speed, not using the sync signal, the two Teensy 3.0 boards using the new library can update that entire array at 274 Hz (each board is responsible for half of the array). The new library has double buffering and leaves the CPU free during those updates, so if your code is efficient enough to produce new images faster than 274 Hz, it will not slow the update rate.

However, updating at 60 Hz with the sync signal is probably better than 274 Hz without sync between the board.
 
Hi all,
For those that have been playing with these LEDs, has anyone noticed that these draw a current even if the LEDs are off? I'm trying to figure out if this is actually what I'm seeing or some other issue. I'm seeing ~1mA/pixel. Is the ws2811 clip always "on"?
Thanks,
David
 
virtualdave: I see 190mA to my 240 LED strip when all the lights are off. So not quite 1mA per pixel, but definitely some current.
 
Paul is seeing something similar as well. Good to know. Yeah, looks like it's about 0.8mA/pixel. I've now added a little p-channel mosfet circuit so I can shut all power to the LEDs when they aren't being used. That extra current adds up pretty quickly, and gets to be a bit painful if trying to do some work under battery power!

Cheers,
David
 
Hey, I'm pretty much a total noob to microcontrollers and LED's but I decided to jump into the deep end with the teensy 3 and WS2811 pixel modules. When I first got them to turn on using the fastspi library, the colors seemed really washed out and the LED's never went completely off. I was banging my head against the wall when I tried lowering the clock speed to 24mhz. All of a sudden, nice clear colors. Washed out at 48 and 96 mhz. Can anyone tell me why?
 
deltaentropy said:
Hey, I'm pretty much a total noob to microcontrollers and LED's but I decided to jump into the deep end with the teensy 3 and WS2811 pixel modules. When I first got them to turn on using the fastspi library, the colors seemed really washed out and the LED's never went completely off. I was banging my head against the wall when I tried lowering the clock speed to 24mhz. All of a sudden, nice clear colors. Washed out at 48 and 96 mhz. Can anyone tell me why?
Click to expand...

The ws2811 has some pretty precise timing requirements and the code in the current version of the FastSPI_LED library was tuned for 16Mhz - I suspect at 24Mhz it was "close enough" to give you something close to working, but at the higher speeds it was definitely way out of spec.

In the next couple weeks i'll be releasing a new version (ground up rewrite) of the FastSPI_LED library that, among other things, will tune itself for chips like the ws2811 and tm1809 based on the clock speed of the processor you are building for, vs. needing to hand adjust timing when the clock speeds change. This should also speed up supporting variations on this style of chipset.
 
Status
Not open for further replies.
Back
Top