LED coffee table with Teensy 3.2+OctoWS -- animations while headless? How?

Status
Not open for further replies.
S

SaturnV

Member
Two questions I am stuck on with my design which will be a (10 or) 12x10 WS2812 array in the table top for an outdoor LED coffee table project. I want to have the table cycle through a few modes automatically-- like a rainbow, starry night, Larsen Scanner, dropping bars like the movie, "The Matrix" as well as I'd like to have scrolling text displaying the time and outdoor temperature for instance.

1) If I go with the Teensy 3.2 + OctoWS2811 + CG-500 enclosure-- can I get away with just the one Octo adapter for a 10x12 arrangement? It seems from the pjrc site under the, "in this example, each OctoWS2811 signal feeds 4 LED strips in back and forth rows."-- would that mean I could go with 3 sets of 4 back and forth rows, 10 LEDs in each row?

2) Is there anything already out there that I can port into the coding for the various animations and scrolling text features that I am after? Sure, I see all the examples of wonderful projects that many have done but specifics in driving animations is scarce. Aside: If I could adapt Tetris or tic tac toe to a 10x12 grid, that would be crazy cool to incorporate a controller but perhaps for a later add-on.

Maybe the hardware is overkill for a such a small array and low resolution. I'm open to FASTled -- maybe there is more out there going that way.

Appreciate the advice-- HELP!
 
For 120 LEDs I think you'd be able to manage 60fps with either FastLED or OctoWS2811. Even if you go with FastLED and only use 1 pin you'll need something to level shift the Teensy pin to 5V so using the OctoWS2811 adapter will save you from having to make your own circuit for that.

FastLED does have some pretty cool features like color space conversion (animations like fade in / out are easier in HSV than in RGB) but that code is pretty easy to copy over to a WS2811 library based project if needed.

In terms of the programming, if it were me I'd write a wrapper or table to turn X,Y coordinates into physical LED addresses. Once you have that working there's lots of examples out on the web that will do low resolution 2D animations, for example I turned up https://www.youtube.com/watch?v=N2IgLlKsQlE and https://www.youtube.com/watch?v=o6_UYb6I4x4 by googling "led matrix animation code".
 
Sorry, I just realized I didn't answer your #1 question very well.

For 10x12 you're going to have to do some cable path management either way. If you go with a single pin and FastLED you can snake the data line back and forth easily, then map physical address to logical location.

If you go with OctoWS2811 and 8 lines you'll either have to arrange things so each pin controls 15 LEDs (e.g. one pin does 10 LEDs of one strip and 5 of the next, the next pin does the remaining 5 LEDs and the next strip of 10) or have a different number of LEDs per pin (e.g. only use 4 pins and have each control 3 strips of 10, or use all 8 pins and have some pins control 10 strips and some control 20). Either way you'll need to map the physical addresses to logical locations, just like you'll have to do with FastLED.

Either will work. FastLED and one pin will be easier to wire (one pin from the Teensy to the first strip, then daisy chain the strips) but even using all 8 pins isn't going to be overly complicated.
 
SaturnV said:
1) If I go with the Teensy 3.2 + OctoWS2811 + CG-500 enclosure-- can I get away with just the one Octo adapter for a 10x12 arrangement?
Click to expand...

Yes, only 1 octo board would be needed. Even that could be considered overkill for only 120 LEDs. But you do need some why to boost the 3.3V signals up to 5V and it does that very nicely.

One Teensy LC could also run this 120 LED project from its single 5V buffer pin. You'd use FastLED or Adafruit_Neopixel to drive just that 1 pin, and of course connect all the LEDs in a single serpentine strip.

2) Is there anything already out there that I can port into the coding for the various animations and scrolling text features that I am after?
Click to expand...

The usual way involves cobbling something together from the many examples that come with these libraries and can be found on websites. Generally the way this goes is you run each example and modify it to suit your needs. Maybe you even write some of your own from scratch, or starting from the examples but changing most of the code. The idea is to get each one working by itself.

Then you would find some way to merge them all. Usually this involves turning each example's loop() into some function you call. Or if it's written as a loop, copy to its own function and edit something in the code so it runs a certain number of times. Then your new loop() function becomes just calls to all those others in whatever order you want the patterns to play.

But the first step is to just run the examples as-is and see them work. Then modify each. That's how you do most bigger projects... you start by getting the pieces working, with an plan to put to them together, but start with small successes and slow work towards leveraging those smaller successes into the bigger project.
 
I think the Octo is over-engineering for this project. I assume the Teensy LC is preferred over an Uno, for example, is for the speed? Can you expound on the, "One Teensy LC could also run this 120 LED project from its single 5V buffer pin"-- What pin is the 5V buffer pin? Now I am curious, if I supply 5V to a Teensy LC-- what voltage comes out at the GPIO? Does the signal driving the WS2812s have to be 5V then?
 
The LC will have more of everything over a Uno, not by huge amounts but quite possible enough to matter if you need RAM for effects generation and CPU heavy lifting to produce them. With the 5V if you look at the teensy ref card on
https://www.pjrc.com/teensy/teensyLC.html
On the end there is a '17 at VIN', which has the output of the 3.3V pin 17 boosted to vin (normally 5V). The signals driveing WS2812 have been repeatedly proven to be 0.7 of your supply for stable operation. If you supply 5V that's 3.5V logic, so not much of a boost but certainly needed.

Edit: a Uno has 2k RAM so a theoretical max of 666 neopixels, 8k in a LC gets a max of 2666. clock speed is 16 vs 48mhz where LC will be doing single command math on things bigger than bytes, where Uno will need to step them through 8bit chunks. Uno can do 100 odd leds, but there will not be much headroom in any direction which will constrain the design
 
Last edited:
YIKES! I see the section under 5V Buffer, just up from Pinouts. I ask then, what is the minimum V logic that the WS2812 demands?
 
you'd need to check the data sheet but the 12V strips are supposed to be running logic at 5V internally, unsure how they do the step down.

edit, may have the wrong chips when I was thinking 2812 as 12V power 5V logic, random data sheet is
https://cdn-shop.adafruit.com/datasheets/WS2812.pdf
which is not hugely helpful but does indicate 0.7 as the ratio of power supply to input high and lower power supply voltage.
 
Last edited:
SaturnV said:
I ask then, what is the minimum V logic that the WS2812 demands?
Click to expand...

There are several ways to think about this question.

If a reliable datasheet for WS2812 existed, you could just read the specs. But the datasheets for these parts are horrible. Early versions even had obviously contradictory info. I personally have no confidence the specs in these datasheets are based on the sort of rigorous design validation you see from reputable semiconductor companies like Texas Instruments, NXP, Fairchild Semiconductor, Analog Devices, etc.

The most conservative approach is to output a 5V logic signal that swings very close to GND and 5V.

The other approach is to actually test. Plenty of reports from actual testing suggest the earliest WS2812 were able to accept 3.3V logic, at least at commonly used temperatures. Many of the WS2812 in the 2014-2015 era did not work at all with 3.3V logic (but the datasheet specs didn't change). Many modern ones seem to work with 3.3V logic, though reports vary even today. Use of 3.3V signals is risky, even it if it does work in many cases with today's WS2812 LEDs.

Another factor is ground shift. Many of these projects involve dozens or even hundreds of amps flowing through the ground wires. Even heavy gauge wires will have a small voltage drop, and use of skimpy wires will be much worse. When the ground is different at the receiver, the effective signal voltage changes. If the voltage changes 0.4 volts along the ground wire (varying of course with color and the ~420 Hz PWM of the chips), then your 3.3V logic high looks like 2.9V at the WS2812 pin. This is the reason why PJRC recommends running the power supply wires directly to the LED strips, and joining the Teensy GND to the LED GND at the strip.

Of course, a true 5V signal like the Octo board is also the recommended way. When you're building a large LED project, the extra cost and effort to get a proper 5V signal is so much less than the cost and work to use so many LEDs and their power supplies. Skimping on the 5V buffers usually isn't "worth it".
 
Status
Not open for further replies.
Back
Top