Teensy 3.1 & Programmable WS2812B RGB LED POV Staff - Newbie Questions

Status
Not open for further replies.
andycomic said:
I used the tlc5947 + teensy3.1 for my poi, here is a vid https://www.youtube.com/watch?v=a1GYJMtcVts , no need SPI, even with bit banging, I need to slow it down still. Had a hard time filming this, look much better in real life. From what Ive read , all the off the shelf leds are too slow.
Click to expand...

thx, nice clothe.
I think i'd better give tries on TLC59xx chip, apa102, or ws2812 (but from suggestions above, they might end up being decorations)
to find which suits my need, thanks for everyone.
btw I would like to know if there's any POV project that already uses ADX3xxx (or other sensors perhaps) to correct the speed/angle ?
 
dgarcia42 said:
APA102's have a ... 20kHz PWM refresh rate, how this is too slow for POV?
Click to expand...

Where is this 20 kHz spec?

I read the APA102 datasheet on Adafruit's site. In doesn't spec the PWM frequency directly. But it does say the internal oscillator is 800 to 1200 kHz. At 1 MHz, with 8 bit PWM, I'd except the PWM carrier to be approx 3.9 kHz.

The TLC5947 seems even worse. It's internal osc is 4 MHz, but it divides by 4096, rather than only 256. It's actual PWM carrier ought to be slightly under 1 kHz.

Did I miss something on the datasheets? Opinions seem to be these chips have very fast PWM for POV applications.

Both are still much better than 425 Hz. I say 425 because I actually did measure it on a few WS2812B LEDs, using a 1 ohm resistor in series, and the capacitor replaced with only 1 nF. I used a 3 MHz bandwidth instrumentation amp chip to get the voltage on the 1 ohm resistor up to a level viewable on my scope. Aside from seeing 425 Hz, the other interesting result was a pretty substantial fixed off time, even when the WS2812B was set to 255,255,255.

Maybe I need to repeat the experiment with an APA102?
 
andycomic said:
I just wanted to answer one question from this old thread as I was casually browsing for this topic. The pic from A1 poi i think it is almost certainly seems to be the tlc59711 as its 12 channels (so 4 rgb leds per chip) and you can see the texas instrument logo on the chip. https://www.adafruit.com/datasheets/tlc59711.pdf

Just 2 cents as there seems to be a lot of ppl asking about what chips are used for these fast refresh rates. IMO if your after something along these lines then look into the TLC5940 as it has libraries that work for the arduino and teensy already at hand. Be warned that they do have some depreciated code in them depending on what IDE your using.
Click to expand...

Having pummeled this particular chip recently (the tlc59711) to puzzle out why it seems to flub (weird ghosting between channels on one chip, or between a given channel on multiple chips) when you try to push it at high refresh rates to support longer strings, I will caution that it's not really full SPI but more SPI-like in how it works, lack of chip select, etc.

The 'auto latching' it does can trip incorrectly quite easily if you don't have an absolutely rock-solid gap-free clock (and therefore data) stream, and that auto-latching being 'aborted' by more data just confuses matters more, causing random 1-bits to propegate down to the PWM counters it appears since it never dims channels only brightens them. So I suppose there's a race condition in the latching logic somewhere? Since even if the 'magic value' to allow the data to latch never shows up in the pixel-stream you can get the ghosting.

The Teensy 3.x can handle that w/ the SPIFIFO without too much trouble, especially w/ the 16-bit word-sized FIFO, but on the Ardunio you'll need (and I really mean NEED) to use the MSPIM mode on the USART to get over 500kbps with any stability. With the MSPIM + USART I could hit the baud-rate limit, so 20+ such chips in a chain at 60fps updates was possible even on one of the AtMega328p's. But any gaps/pauses in the clock-stream longer than 8* the clock rate is what trips things up. Otherwise they're a beautiful chip to work with, absolutely lovely.
 
Last edited:
I'm using APA102 strips for my 800 LED POV staff. I'm updating at 3 ms and getting great image display.

You'll also have to take my word for it, as I've still no passable photos. I need to repair the staff after Burning Man before I get any.

I'm sure this can go faster and give better images. The main constraint on update speed was dumping data to the strips, which is taking over 2 ms. I'm not using the hardware SPI pins and communication to the strip was troublesome if the Teensy was clocked to more than 48 MHz. Solving that should be the main speed up. (I'm using FastLED, by the way, as should we all).

Image data is just coming direct from flash (following the Adafruit POV poi data format). There's some caching going on - the first read of data was taking about five times as long as the rest. This wasn't an issue as getting the image data from flash was far faster than dumping to the strips, about 0.1 ms for the first read, 0.01 for the remainder.
 
Get the most recent version of the FastLED3.1 branch - there were some problems with how I was computing SPI multipliers at higher clock speeds.
 
attached are a couple of APA102 POV poi photos. First attempt at photographing them. This uses a single 3.7v Lipo to run the teensy and the 120 apa102 leds. The images are currently stored in const arrays. (waiting for your flash memory Paul). This was not using hardware SPI, just using the FastLED option as a driver and just calling pins 2 and 3 for data and clock.

These strips update fast using the soft spi, and a bit too fast for 120bmp music (= two revolutions spinning per sec), so adding in a delay or two.

APA102_holly.jpgAPA102_snow.jpg
 
Last edited:
hi guys, I'm wondering if there's a rest most in teensy LC/3/3.1 yet?
since setup at booting delays some time, and might cause delay in planned performance with music.

I've tried to find answers about rest/low power mode and disappointed when i find no appropriate answer
the best project I found seems to consume ~10mA , still a lot greater then ~10uA i expected.
but from what I read, the bootloader chip MINI54 (or MKL02/04,) seems to be a possible to lower the ~10mA current
Is there any customed teensy board without the chip show better rest mode? thanks.
 
Last edited:
A couple of pictures from my glow staff. Teensy 3.1, FastLED, and APA102s.

IMG_7221.jpg

IMG_7350.jpg

A few more at happyinmotion.com.

Sorry for the delay in getting these pics after promising them a month ago. Went to Burning Man, broke everything, learnt lots. Fixed enough for these pics, now working on a newer version with reliability as the main goal.
 
Bumped into some problem I should have thought of before,
There's only a master spi port , and the SD-reader, winbond, ws2812, apa101, TLC59711, and even ADXL sensor, they all uses spi port
Is there any possibility to use two of above, working together?

Should I look for a I2c flash chip or LED driver?,or connect 2 teensy board together?
Is any chip/driver of above could use other pin from spi interface?
Or turning all pictures into byte arrays and store them into teensy flash mem?

thanks
 
at the moment, flash storage seems to be the only way. Onehorse has a flash add-on and Paul was looking at doing further work on multiple SPI and a flash add-on, not sure how far this has progressed. Unfortunately, looking into multiple SPI is far beyond my knowledge.
 
In about 6 weeks, PJRC will start selling a shield meant for these types of projects. The PCBs went into manufacturing this week, so this product has finally moved from the lengthy planning & design phase to the beginning of production. Normally I resist the vaporware urge to mention stuff in development which has no clear delivery date. Since this is now in production, you can be pretty sure we'll be selling these before Chistmas.

This new shield will have 5V buffers (compatible with 24 Mbit SPI to long APA102 strips) and digital logic for proper SPI sharing, and 8 Mbyte fast SPI flash for storage of images & sound clips, and 10DOF fast motion sensing, and a 2 watt audio amp for props & costumes with a sound component. The form factor will be 1.9 by 0.7 inches, where the extra 1/4 inch length on each end allows mounting holes and 4 pins. The end overhanding the USB will have pads for power and the speaker, and the side overhanging Teensy's pushbutton will have 4 pads that mate 1:1 with APA102.

A tremendous amount of work has gone into this shield's design, to (hopefully) avoid some of the very thorny problems. For example, even though the PCB doesn't need complex routing, a 4 layer design is used to allow the rapidly changing LED current to flow through distributed planes, and around a small circular cut-out area, for minimal interference with the magnetometer. The amp uses differential input with connection to Teensy's AGND pin, to minimize ground loop issues, and filtering of ultrasonic harmonics from the DAC. Of course, it's designed for proper SPI sharing and fully compatible with the fast 24 Mbit/sec rate.

I'm working on examples for LED Poi and hula hoops (the motion activated hoop may require 2 boards...) and some sound reactive stuff too, using FastLED and SerialFlash libraries. Farther out than the initial release in 6 weeks, I'm going to work on JPEG and GIF (with animation) libraries and other supporting software that will be extremely useful in these applications. MTP will be added to Teensyduino and a SerialFlash example, so you'll be able to access the SPI flash as a normal folder and simply copy files to it (modern Windows and Linux natively support MTP... Macs require a 3rd party program, but MTP support does exist as an addon). My goal is to make these challenging POV and sound reactive motion sensing projects much, much easier for everyone.

The upcoming shield will sell in 2 flavors. The full version will be approx $25. A low cost version which omits the motion sensors will be $10.
 
Last edited:
Paul, this is really exciting news, and thanks so much for the effort you put into these advances. Question: will the shield play nicely with Lipo charger such as Onehorse's? a lot of poi and hoop kit likes to be usb rechargeable.

MTP also sounds fab, no need to process image files externally and use const arrays?
 
Yes and Yes, but it may be a while until libraries that read native GIF89 and JPEG are working. Until then, you may still need to process images into some other format, but you'll be able to copy those files by just draging them into the folder, thanks to MTP protocol.

A typical arrangement would likely put the shield on the bottom, Teensy 3.2 in the middle, and Onehorse's LIPO board on top.
 
Last edited:
well, for image file format we already have the 24bit bmp accessible with code example, its tried and tested for the light painting staff (albeit from sd), offset, header size, and buffer setup for pixel access is already coded. So converting to bmp and uploading via MTP should work.
 
I went to bed last night having spent the day scratching my head over how to get a Teensy to run the APA102 strips AND the SPI flash memory AND the motion sensor AND the microphone...

So Xmas just came early. Thanks, Paul.

And the All Blacks won as well.

I'm currently designing the next version of the Mitochondrion staff and I've love to have it ready for Kiwiburn, at the end of January. So obviously, these shields will arrive when they arrive, but will it be possible to get design information before then? That way I can get other boards and bits ready in advance. Being in NZ, lead times for boards can be three weeks or more and that's getting tight.

Two minor issues:
1) I've found when using APA strips in parallel, if I powered them at cell Voltage and ran a level shifter to bump up CLOCK & DATA to 5 Volts, I get horrible flashing. In this situation, controlling the strips at 3.3 was absolutely stable.
2) For image data, the palette indexed byte arrays used in the Adafruit POV poi work just fine, fast and efficient storage. Is more advanced approaches going to be as fast and as dense? Naively looking at specs for SPI flash and hardware SPI to strips, I'd hope my next staff can update images every 1 ms or less, hence the emphasis on speed.

Updates every 3 ms don't look too bad though:
IMG_7425 cropped.jpg
 
Good morning, and good evening also,
woke up early this morning, wondering if there's possibility of bit-banging another pin for dataout/clock,
though I know little about how they work.
Would be far more harder than bit-banging PWM on other digital pins (did on arduino),

and then I'm glad to hear the exciting news,wow , a POV shield? and with image software,
thanks paul ! can't wait for Christmas! :rolleyes:

and btw, why not chloroplast staff , is there some story behind? interesting to know,
 
PaulStoffregen said:
This new shield will have 5V buffers (compatible with 24 Mbit SPI to long APA102 strips) and digital logic for proper SPI sharing, and 8 Mbyte fast SPI flash for storage of images & sound clips, and 10DOF fast motion sensing, and a 2 watt audio amp for props & costumes with a sound component.
Click to expand...

Oh i NEED that board :)
Which motion sensors are used ? MPUXXXX?
Time to get rid of the Raspberry (which never was really needed) and old Arduino-clone.. and build a new "Balancing Roberta" https://www.youtube.com/watch?v=n-noFwc23y0
 
Wondering again, Spi slaves seems to be switchable with SS pin, set to low to switch data exchange on, and pull up to off
which means I could possibly use serial flash and motion sensor at a same device, with proper coding.


though LED strips/LED drivers had no slave select pin
I came up with an idea that if I add a PNP transistor to the line from MOSI to the LED driver
and with transistor base connect to another digital pin on teensy
does that make the other pin act just like a ss pin to the LED driver?
with low output means LED DO off (no color switching , but LEDs were still bright with previous line)


Anyone tell me if I am correct, than I'll be very encouraged to work on :confused:
 
Last edited:
Status
Not open for further replies.
Back
Top