WS2812 Demo - OBEX - Pulsing & POV
JBWolf
Posts: 405
This is specifically regarding OBEX 703 Johnny Mac's awesome WS2812 LED driver.
I am using batteries for my led's and need as much running time as possible.
The LED strips are very bright, even at 1/2 brightness using strip.set, ColorX, WheelX and modifying the Chakras RGB hex values to 1/2.
Pulsing the LED's through the main 'driver' at a sepcific hz/ms to create an appearance of continuous power while saving on battery time would be a great help.
I would love to use this for POV purposes at a later time as well. Something such as a method I could call to set a frames per sec value at any time so as to keep up with any moving object.
I am using batteries for my led's and need as much running time as possible.
The LED strips are very bright, even at 1/2 brightness using strip.set, ColorX, WheelX and modifying the Chakras RGB hex values to 1/2.
Pulsing the LED's through the main 'driver' at a sepcific hz/ms to create an appearance of continuous power while saving on battery time would be a great help.
I would love to use this for POV purposes at a later time as well. Something such as a method I could call to set a frames per sec value at any time so as to keep up with any moving object.
Comments
I suggest you create a secondary output in the cog that will control a FET to switch the LED string on and off. Turn on the string, update everything, then finish your "on" period. Turn the string off, wait to create the desired duty cycle. Repeat.
BTW... there is no H in my awesome [first] name.
Does your driver just send a single signal to turn them on, and now the each chip on the led strip holds this data until changed? or does your driver constantly update?
I thought about trying a TTL circuit similar to how I've done for controlling pulsing on a "DDL" style laser driver with the prop... I have used transistors for this purpose and was greatly successful. But using a transistor wouldnt work if your driver doesnt constantly update.
Wouldnt using an FET just reduce the signal strength unless utilized like a transistor? (full on/off)
Yes. The reason for the refresh rate of my driver is that I tend to run very dynamic color animations, and I want the refresh rate to be faster than my animation rate.
The WS2811/12 is a single-wire protocol; the WS2801 uses clock and data lines (not timing finicky). Luckily, the Propeller makes dealing with WS2811/12 timing pretty easy.
For a minimal 8 led pov, you have 192 bits of data (8 leds * 24 bits) = 240 uSec, + 50 uSec latch time, 290uS altogether. That's a refresh rate of 3448 Hz, and the Prop can sustain that nicely.
Is the PWM frequency actually driving the leds unusually slow or something? They'd get flicker on tv cameras if they did that. I doubt it but don't know for sure.
Need to solder up a ws2811 IC by itself and look at the actual waveforms. There's a frustrating lack of detail on these ws2812s
I think the 400Hz figure is the WS2811's PWM frequency. If this is the case then, sending data to the chip at a higher frequency than 400 Hz doesn't do you any good.
For creating a refresh delay, could I add a short pause right before "jmp #rgbmain" ?
The label frameloop is where the program jumps back to in order to read the next rgb value to transmit. The actual program loop begins at rgbmain with the required delay between data bursts.
BTW... if you're creating your own driver I insist that you take my name off of anything you produce -- at the most you may use the phrase, "based on code by Jon McPhalen." I can only be responsible for my own programming; I will not be held responsible for what you do.
Duane you're exactly right. Dug the propscope out tonight and measured it at 424 Hz PWM frequency, which is lower than I expected.
I guess having such a low pwm frequnecy spares them most EMC issues
Just to clarify, was that the frequency during PWM where the LEDs were not a 100% duty cycle? I think that is what you mean, but I have seen some other people (not on these forms) use PWM frequency very loosely. Based on what I see here, and the data sheet. It looks like the WS2811 operates at 4 to 8 kHz and supports a PWM frequency of at least 4 Hz. The WS2812 operates at 8 kHz, but I'm not sure the PWM frequency is any better.
I think for me 400 Hz is fine. I am not interested in POV. I just want to ensure that any species I work with perceives PWM as a change in intensity, not a change in flicker rate. I do not know any species that has a flicker fusion threshold of ~400 Hz. It may be 300 Hz for honey bees, so I suppose it is possible. But much lower flicker fusion thresholds appear more common. I think these will work fine. The "neopixel" packages adafruit makes are just so super convenient for me.
You can think of the WS2811's as having a latch that is "dual ported" - the incoming data stream getting written to the internal latch, and the outgoing pwm read from the latch that drives the leds.
The WS2811 data stream "operates" at 400 to 800 kHz and beyond (not the 4 to 8 kHz you mention) - this is the rate at which bits are clocked into the internal latch on each IC, 24 bits per LED means you can work out the time required to load up a string of leds, and how many times you can load per second. Note its possible to load the latches many times faster than the pwm displays the results, especially for short strings.
Going from the internal latch to the led itself, happens approx 424 times a second and seems independent of the input data clock (400 to 800 kHz). I would think this could be a minor issue recording on a 50 Hz camera as some leds would be on for 8 and some 9 cycles per 50 Hz frame.
There's some good timing investigation and results worth checking out at Josh.com