I am looking for your feedback on a POV Globe I want to build. This is me vocalizing the possibility of doing this and publicly working out the math.
I want to build a plastic ring that would run from north to south at 0 and 180 degrees. I wanted to use the new Adafruit NeoPixel Digital RGB LED Strip at 144 LEDs and is 39.37" long and secure it to the plastic ring which is roughly 12.5" in diameter. That means there is an LED for every 2.5 degrees, however I plan to shift the ring so that the the first LED is at 0.625 degrees on the 0 degree strip so that second LED in POV will be at 1.875 on the 180 degree strip. By incorporating an offset in the display of the second strip, I can create a matrix instead of interlaced so that the 180 degree strip is 1.25 degrees after the 0 degree strip.
I am automatically assuming that I am going to need to split the strip in half. If I am spinning the globe at 30 rev/s that means each strip needs to program 72 LED in 38.6 micro seconds, hold them for the same amount, and then turn them off in the same amount of time to have some resemblance of a steady picture. With a 800kbps data rate for the neopixel, I will be 2160micro seconds to just program them.
It isn’t even close to being able to work. I really wanted to use the Neopixel strips for ease of construction. Is my math even right?
Thanks,
Frank
fkatzenb:
I am automatically assuming that I am going to need to split the strip in half. If I am spinning the globe at 30 rev/s that means each strip needs to program 72 LED in 38.6 micro seconds, hold them for the same amount, and then turn them off in the same amount of time to have some resemblance of a steady picture. With a 800kbps data rate for the neopixel, I will be 2160micro seconds to just program them.
Where did the above numbers come from ?
My first notion would be to make the horizontal resolution equal the vertical, 1.25 deg. At 30 rev/sec, that’s a 33.33 msec period. A 1.25 deg resolution means the LED has a time slice of (1.25/360)*33.33msec = 115.7 usec. This may or may not even be close to being do-able.
Are the NeoPixels programmable such that they hold the prior data and display while the next data is being uploaded ? That is the all the data can be uploaded while the display remains unchanged and then with a single command, voila, the new display happens w/only a few usecs of switching time. This way you can use the whole timeslice(N) to be uploading the data for timeslice (N+1). Even then that’s 1.6 usec/pixel to load each 72 LED strip. At a 800 kbs data rate that’s about 1 bit per pixel … not very RGB-ish.
So something has to give … I think. :?:
Mee_n_Mac:
fkatzenb:
I am automatically assuming that I am going to need to split the strip in half. If I am spinning the globe at 30 rev/s that means each strip needs to program 72 LED in 38.6 micro seconds, hold them for the same amount, and then turn them off in the same amount of time to have some resemblance of a steady picture. With a 800kbps data rate for the neopixel, I will be 2160micro seconds to just program them.
Where did the above numbers come from ?
My first notion would be to make the horizontal resolution equal the vertical, 1.25 deg. At 30 rev/sec, that’s a 33.33 msec period. A 1.25 deg resolution means the LED has a time slice of (1.25/360)*33.33msec = 115.7 usec. This may or may not even be close to being do-able.
The 38.6usec is 115.7usec divided by 3. So if you came up with the same number, then yes, it is not doable.
That is a shame because of how easy those strips are to use and mount.
See my added math above.
So it doesn’t look possible at that resolution … and yet people do RGB POV globes.
How ?
Well the RGB POV globe people do are segmented up and people use the TI chips to drive the RGB in banks and they are typically single color at a time. I was looking to break the mold but the strips just take too long to program.
This guy had the right idea but I haven’t seen much more than this… http://www.youtube.com/watch?v=_hprsvsPpEI
I thought about leveraging this concept and using these to straddle the end of the PCB…https://www.sparkfun.com/products/11679
fkatzenb:
This guy had the right idea but I haven’t seen much more than this… http://www.youtube.com/watch?v=_hprsvsPpEI
And even he was limited to just on/off control of each RGB led. With only 1/3'rd of the number of pixels and who knows what for a horizontal resolution and a data rate in the 10's of MHz ... doing 3 bits/RGB pixel is do-able.
Makes you wonder how this was done.
http://www.youtube.com/watch?v=uTtCkGuGmzQ
I think I would almost have to use a TLC PWM driver with common anode. I program the driver during the revolution and then cycle the anode on during the timeslice. I can use one Arduino to handle the 0 degree veritical strip with another Arduino to handle the 180 degree strip. Then use a third Arduino to act as the hose with a WiFi board.
So in the case I want a large globe, each vertical strip would be three sections with TLC drivers talking to that sides Arduino.
fkatzenb:
I think I would almost have to use a TLC PWM driver with common anode. I program the driver during the revolution and then cycle the anode on during the timeslice. I can use one Arduino to handle the 0 degree veritical strip with another Arduino to handle the 180 degree strip. Then use a third Arduino to act as the hose with a WiFi board.
So in the case I want a large globe, each vertical strip would be three sections with TLC drivers talking to that sides Arduino.
This chip may work: http://www.ti.com/product/tlc5947
8 RGB LEDs per chip. If I used that guy’s same design construction but bigger, I would do 24 LEDs per half for a total of 48 LEDs for the 0 strip. I can spend 33ms to program them and flash the anode on and off at the commanded time slice.
So now the question is can the Arduino program 6 of these chips in 33ms even though the chips can handle 30MHz.
I can spend 33ms to program them and flash the anode on and off at the commanded time slice.
Yes but you're still then limited to one color per revolution for each horizontal band, it's on or off. My guess you'd have a better looking display with even just the 3 bit color depth (on/off for R, G, B).
If you go back in time, early 'puter color displays were only 3 bpp for R and G, and 2 bpp for B, or 8 bits/RGB pixel. So if each RGB pixel had some local memory that could be preloaded before spinup, then at each timeslice the controller would only need to fill working memory from the stored data, every pixel would be working in parallel, just sync’ed in time by a master controller/clock. At a byte per timeslice, that’s not much memory for each RGB pixel. Makes me wonder that instead of having a W2801/2811/2812, etc, etc for each pixel, what if you had a cheap MCU, like a ATTiny or PIC ?? Even at 1 deg H resolution, that’s 360 bytes at the meager color depth above. The MCU would then use 3 pins to PWM the R, G and B sub-pixels, implying something like 100 kHz PWM clock (to get 10 PWM cycles/timeslice @ 30 revs/sec). That might just be do-able. Or at least amenable to scaling if you reduce the H resolution. At 48 pixels for the vertical arc, that’s 7.5 deg V resolution. Set the H resolution to even 2x that and that’s only 100 bytes to store the data and a PWM frequency that easily done now.
So what’s a cheap MCU cost when bought in bulk (ie - 48 of them, 1 per RGB pixel) ? What’s the cost per pixel for the NeoPixels ? How badly do you want this to look good ?!?
There’s an old saying in racing … Speed costs money kid. How fast do you want to go ? Same applies here.
Mee_n_Mac:
I can spend 33ms to program them and flash the anode on and off at the commanded time slice.
Yes but you're still then limited to one color per revolution for each horizontal band, it's on or off. My guess you'd have a better looking display with even just the 3 bit color depth (on/off for R, G, B).
If you go back in time, early 'puter color displays were only 3 bpp for R and G, and 2 bpp for B, or 8 bits/RGB pixel. So if each RGB pixel had some local memory that could be preloaded before spinup, then at each timeslice the controller would only need to fill working memory from the stored data, every pixel would be working in parallel, just sync’ed in time by a master controller/clock. At a byte per timeslice, that’s not much memory for each RGB pixel. Makes me wonder that instead of having a W2801/2811/2812, etc, etc for each pixel, what if you had a cheap MCU, like a ATTiny or PIC ?? Even at 1 deg H resolution, that’s 360 bytes at the meager color depth above. The MCU would then use 3 pins to PWM the R, G and B sub-pixels, implying something like 100 kHz PWM clock (to get 10 PWM cycles/timeslice @ 30 revs/sec). That might just be do-able. Or at least amenable to scaling if you reduce the H resolution. At 48 pixels for the vertical arc, that’s 7.5 deg V resolution. Set the H resolution to even 2x that and that’s only 100 bytes to store the data and a PWM frequency that easily done now.
So what’s a cheap MCU cost when bought in bulk (ie - 48 of them, 1 per RGB pixel) ? What’s the cost per pixel for the NeoPixels ? How badly do you want this to look good ?!?
There’s an old saying in racing … Speed costs money kid. How fast do you want to go ? Same applies here.
I am wonding if I can do this with a Maple Arduinio. The TLC5947 has 24 channels that will allow you to do 8 RGB LEDs. Not accounting for any overhead, I can program 8 of them in 288bits up 15Mbps (TLC and the Maple’s ST processor can support that, but don’t know if the Arduino IDE allows the Maple to support that). Which means that if I am doing 48 RGB LEDs per side (1728 bits), I can do it in 0.1ms which is less than the 33ms. Technically one Maple could do the two 48 RGB LED vertical stripes.
EDIT : At 30 revs/sec, a 1 deg H resolution is a 92.6 usec timeslice so yup, you can certainly hit your original target (1.25 deg, 116 usec) that way, let a reduced H resolution. I just worry about signal integrity at the 15 MHz DTR. Realistically are you going to need line drivers/rcvrs of some sort, given the line lengths ?
Can you do the 6 TLCs in parallel ? That is load a port and clock 6 bits out with a single clock. You could slow the clock down quite a bit that way.
Now I’m rethinking what the PWM depth and rate have to be to get a color mix and not just a finer H resolution. If an on/off at the timeslice period got you a display that was a crisp :
__________, ,__________, ,__________
``` (_ = LED on: , , = the timeslice with LED off)
How fast must you turn the LEDs on/off (PWM) to get a color and not something like :
-
-
-
-
-
-
-
- , ,- - - - - - - - , , - - - - - - - -
If you get my drift. Maybe the final output really needs to be an analog stage ?
I'd think with a PWM depth of 12 bits, you could map that linear resolution into the log scale that our eyes perceive and still get a good perceived color/brightness curve.
The rain gods decided that I would not get a beat ride in today on the PWC so I had to clear my brain with MaiTais at the local Chinese food place. So after careful consideration (stupid 3 MaiTai limit !) I think I can say that using PWM to mix the levels of R, G and B into a color is gonna have some problems. Let me explain and see if you agree.
In order for the PWM not to be discerned as a “subpixel”, the physical arclength of the “subpixel” should be small enough such that any one “subpixel” blurs into it’s neighbors. Just as a 720 HDTV can’t be seen as any different from a 1080 version at a far enough distance, because the pixels are below our human ability to separate. What might that limit be when talking about your globe ?
Well if your globe had an about 12" diameter, then that’s about a 36" circumference. IOW every 10deg of angular resolution equals about 1" of arclength at the equator (the most demanding region). Your desired 1 deg of resolution would be 0.1" in length. If I were to look at a tape measure I could certainly see the differences in 0.1" marks. But if those were 0.01" marks … they just might blur together. So let’s use the idea that any 0.01" line segment blurs into it’s neighbor (a best case approximation IMO) and so is indistinguishable at a reasonable viewing distance. If you want to put your nose really close to the whirling arc of death … that’s your prerogative.
So at 30 revs/sec how long does it take the arc to travel 0.01" at its equator ? Well if 1 deg is 0.1" then 0.1 deg is 0.01" and given the 33.33 msec period for 360 deg … that’s about 93 usec to go 0.01". So ideally a whole PWM cycle would complete in that 93 usec. If you had 3 bits depth at any 1 color, that’s 8 levels to run though, or 1/(93usec/8) = 864 kHz for the PWM clock. Seems a tad high IMO. Going to a deeper color depth per sub-pixel (color) means an even faster clock so that an entire PWM cycle can be completed before the arc swings too far a distance. I’m thinking the min color depth mentioned (3/3/2) is already breaking the bank.
IOW a “slow” (by the above analysis) PWM clock won’t result in a H pixel of some color but a bunch of “subpixels”, smaller in size and of differing colors from the one intended. I don’t know what this, if true, says about the architecture of the “kewl” RGB globe. Perhaps it says more resources (and $$s) should be expended on those regions near the equator with the tradeoff of less resources near the polar regions. IOW perhaps an MCU or 3 for the equator and only 1 for both polar regions and 2 for the inbetween regions. More parallelism where it’s needed and less where it isn’t ???
Mee_n_Mac:
The rain gods decided that I would not get a beat ride in today on the PWC so I had to clear my brain with MaiTais at the local Chinese food place. So after careful consideration (stupid 3 MaiTai limit !) I think I can say that using PWM to mix the levels of R, G and B into a color is gonna have some problems. Let me explain and see if you agree.
In order for the PWM not to be discerned as a “subpixel”, the physical arclength of the “subpixel” should be small enough such that any one “subpixel” blurs into it’s neighbors. Just as a 720 HDTV can’t be seen as any different from a 1080 version at a far enough distance, because the pixels are below our human ability to separate. What might that limit be when talking about your globe ?
Well if your globe had an about 12" diameter, then that’s about a 36" circumference. IOW every 10deg of angular resolution equals about 1" of arclength at the equator (the most demanding region). Your desired 1 deg of resolution would be 0.1" in length. If I were to look at a tape measure I could certainly see the differences in 0.1" marks. But if those were 0.01" marks … they just might blur together. So let’s use the idea that any 0.01" line segment blurs into it’s neighbor (a best case approximation IMO) and so is indistinguishable at a reasonable viewing distance. If you want to put your nose really close to the whirling arc of death … that’s your prerogative.
So at 30 revs/sec how long does it take the arc to travel 0.01" at its equator ? Well if 1 deg is 0.1" then 0.1 deg is 0.01" and given the 33.33 msec period for 360 deg … that’s about 93 usec to go 0.01". So ideally a whole PWM cycle would complete in that 93 usec. If you had 3 bits depth at any 1 color, that’s 8 levels to run though, or 1/(93usec/8) = 864 kHz for the PWM clock. Seems a tad high IMO. Going to a deeper color depth per sub-pixel (color) means an even faster clock so that an entire PWM cycle can be completed before the arc swings too far a distance. I’m thinking the min color depth mentioned (3/3/2) is already breaking the bank.
IOW a “slow” (by the above analysis) PWM clock won’t result in a H pixel of some color but a bunch of “subpixels”, smaller in size and of differing colors from the one intended. I don’t know what this, if true, says about the architecture of the “kewl” RGB globe. Perhaps it says more resources (and $$s) should be expended on those regions near the equator with the tradeoff of less resources near the polar regions. IOW perhaps an MCU or 3 for the equator and only 1 for both polar regions and 2 for the inbetween regions. More parallelism where it’s needed and less where it isn’t ???
Wow, I should have self medicated with MaiTais prior to reading this! I think I understand what you are saying. It isn’t so much that data rate as it is the PWM of the TLC board if I try to command a brightness level. This means I am forced to about 9 colors because of it.
I think the math needs to be updated to deal with the change in construction. If I went with 48 RGB LEDs utilizing the TLC chips, that is one LED every 3.75 degrees. I thought this would lesson the burden quite a bit. If the other side of the globe is offset, I would have a nice dot matrix globe.
Well think about it some more when you have the chance. I think I’m onto something but I won’t guarantee the above analysis is spot on. While reducing the number of vertical LEDs helps the computational cost (at the expense of V resolution), that has no bearing on trying to use PWM to achieve color as normally done. That’s because PWM is timing and timing is spatial resolution in the H dimension.
Perhaps a takeoff on your original idea of using 2 vertical arcs of 180 deg, but with the LEDS offset to get better V resolution, is an idea to twist about and explore. Imagine adding more arcs, of smaller length, but spanning only the “equatorial regions”, say 60 to 120 deg vs 0 - 180, with LEDs can help. Then these arcs can overlap and prevent the “subpixels” mentioned above ???
Damn … I need another MaiTai or 5 to think this through !
Again the big idea trying to be thought through here is the full RGB color and spatial coverage I think you had originally envisioned. Think big early and concede defeat for $$ reasons only later.
Some more semi-random thoughts …
First the below is a (?too?) simplistic illustration of what I think the problem is going to be when using PWM to get color from an RGB LED. Imagine it shows 1 timeslice, 1 horizontal pixel. In this case I show 3 PWM periods across the timeslice (just to illustrate) using 3 bit depth for each R, G and B color (doing 3:3:2 was to much of a PITA to draw). So each R, G or B LED has 8 possible states; off for the whole period, on for the whole period and 6 other in-between times. Of course the motion of the LEDs makes time on/off into space on/off. So if the H pixel is “wide” or the PWM frequency “low” (= PWM period is “long”) then the individual PWM on/off timing may be seen as individual sib-pixels instead of the color or brightness level that was desired. Example 1 shows all colors on for some portion of the PWM period, aka a white brightness level less than 100% is what was desired. The composite output band is the mix of the R, G and B LEDs, it’s what I think you’d see. Alas it’ll just look like a shorter pixel vs being a brightness level. Example 2 only further shows the problem, when some mix of on times (for R/G/B) would be used to get some color. Instead what happens is you get a melange of sub-pixels of varying colors. Again if you could make the timing faster, the sub-pixels smaller … I’d think they’d blend in together to be what you want.
You could potentially help that process along if you had really fine control of the PWM timing. That is dictate the on/off cycling withing a PWM period so that any of the 7 sub-periods (in this example with the 3:3:3 color depth) could be individually controlled on/off. The 1A and 2A examples show 1 possible illustration of this concept. None of the PWM chips or MCU functions allow this level of control … that I’m aware of.
(click on to open and enlarge)
Another idea is to use the kind of control in the 1A and 2A examples and use a different pattern for each rotation of the arc, dithering them so over a few passes all the sub-pixels vary in their make up such that the eye averages them over time to be what you want. In effect you’re now PWM’ing them at the rotation rate, 30 Hz. If you use the other arc, not to increase the V resolution, but to further vary the pattern, then it’s PWM at 60 Hz. Perhaps this along with the idea above would work ???
The last thing I can imagine is to have some analog circuitry for each R, G and B LED. Then the PWM becomes a 1 bit D/A converter, except that the circuitry would be a variable current driver. This approach could also account for the log nature of the eye but would be … well … parts count intensive and more $$s. How fast do you want to go ? :?
Are any of the options above good ones ? Got me.
Wow, great work. You are absolutely correct. It just doesn’t mathematically work. Even with the TLC5947’s internal oscillator at 4MHz, if I am at a 50% PWM duty cycle, that is 512us of on time and 512us of off time. With each degree/pixel being 93us, I am screwed. Not even slowing the globe down works. The only advantage of the chip right now is mixing my primary colors so that I have 9 combinations. I could do that with some other chip.
Yup, it seems there’s no getting around it. Trying to get the full range of colors you’d normally get with a strip via PWM just isn’t possible w/o a lot of effort and $$s. The (really) last idea I have now is to use more LEDs in a “fan” pattern. That is instead of a vertical row/arc of LEDs, expand the number of LEDs near the equator of the globe from one to N. You’d end up with a “fan” that is shaped like a section of the surface of the globe. Below is a simple 2D representation of the basic concept. Imagine it having more vertical LEDs than is shown and it spans from 0 deg to 90 deg, from the North pole to the equator, from top of fan to the wide bottom. You’d use 2 of them at a minimum to get the POV effect.
(click on to open)
The idea is that multiple pixels near the equator can do a limited form of PWM. Imagine each RGB LED rotating through a line of longitude … the R G and B LEDs can be either on or off for 1 timeslice as they pass that line. In the above there are 9 RGB LEDs at the equator (just my SWAG). If the displayed pixel at that longitude is supposed to be white, 100% bright … then each of the 9 LEDs are fully on (for 1 timeslice) as they rotate to that longitude. If the pixel is supposed to be off, then all 9 are off. If the brightness was to be 50%, then 4 of the 9 are on as they pass and 5 are off (as close to 50% as possible w/9 LEDS). Because the “fan” is rotating at 30 revs/sec the 9 LEDs rotate through that region quickly and so you have PWM again, because you timed each LED to be on/off at the same displayed place. Colors are made by varying which of the 9 LEDs have their R, G or B components on as they rotate into place.
With 9 LEDs you only have 10 possible levels so it’s not the 8 bit PWM you normally get with any MCU, let alone the 12 bits you’d get with the TLC ICs. But it’s more the the 3:3:2 color depth of the early displays and better than sticking with the 7 colors and off you get with the simple option. IIRC that’s 10^3 possibilities, 999 colors and off.
Is 9 LEDs at the equator the right number ? Got me. How quickly should that number decrease as the fan goes to the North pole ? Got me. But it seems certain that at some point the timeslice for a pixel results in such a short segment that normal PWM control would become effective as the “subpixels” would be too small and so be invisible … just as you don’t see the pixels on your TV.
I ran across a couple of pieces of info I’d thought I’d pass on. At one point I think it was mentioned about splitting the data transfer task in more parallel pipes. Specifically I wondered if you could move 8 bits of data to 8 strips by moving memory to a whole port at a time. Well it’s been done for the WS2811 and using a Teensy.
http://www.pjrc.com/teensy/td_libs_OctoWS2811.html
Of course even if you can update all the LEDs desired quickly enough to get a “good” H resolution, that’s not the whole story. The strips use PWM to get their myriad of colors and if the PWM is done too slowly, the PWM on/off timing will be visible as “sub-pixels”. Heck even that assumes you can run an entire PWM cycle, all 255 intervals for 8 bit, before the next update cycle. I found this table of controllers and their various specs.
http://code.google.com/p/fastspi/wiki/ChipsetOverview
Seems the WS2811 is only 400 Hz. Gack !! I’m not sure whether that chart means the PWM clock or the rate at which a whole PWM period is completed. The latter is the best case and so let’s assume for the moment that all 255 intervals are done in the 1/400 = 2.5 msec. That means updating the display sooner than every 2.5 msec won’t allow the PWM to complete. In a static display this would result in the wrong color/brightness. How far would your globe rotate in 2.5 msec ? At 30 revs/sec, it’s 2.5/33.33 360 deg = 27 deg. That seems a tad large for a good H resolution (aka H pixel size). And that’s the best case. What if the table means the PWM clock runs at 400 Hz and it really takes 1/400255 = 637.5 msec.
It would seem the fastest controller in the chart runs a PWM at 7kHz, 17.5x faster. In the best case that would yeild a H pixel size of about 1.5 deg … pretty close to what you had wanted. The TM1829 even updates 2x faster than the WS2811 and also does 8 bit/channel color. 1.5 deg equates to about 0.17" of arc length at the equator for your 1m in circumference globe. Visible at close viewing distances, not so much at 10’. Would the “subpixel” problem be visible ? Depends on the viewing distance. But this is the best case … what if the PWM clock is 7kHz and it really takes 255x longer to work through a whole PWM cycle ? Then everything is 255x longer and I think you’re screwed again, at least as far as getting it done “easily”.
After looking at the table linked to above, I noticed it did not specify the PWM rate for the TLC5947. Thankfully it’s made by TI and they put out datasheets in English and are well written, chock full of details. IIRC I think I spit-balled that a 1MHz (outrageous !) PWM cycle rate would be needed to eliminate the “subpixel” problem, even at close to your nose viewing distances. Alas that was at a lesser than 12 bit PWM depth.
Well if I understand the datasheet correctly that’s exactly (close enough) what the TLC5947 does. But at 12 bit/channel depth (damn). You can see the PWM timing in Fig 18 and you could imagine from that the “subpixel” problem I tried to illustrate earlier. So it takes 4096 clocks of some internal oscillator to run a whole PWM cycle. The functional block diagram on pg 5 says that oscillator runs at 4MHz … so that’s a whole PWM cycle every 1.024 msec. For your globe at 30 revs/sec, that’s a potential H resolution of 1.024/33.33* 360 = 11 deg or about 1.2" of arc length at the equator of your globe. Even fractions of a pixel this size would be easily discernible at many feet.
http://www.ti.com/lit/ds/symlink/tlc5947.pdf
Crap !
For me at least, I don’t see any hope in using PWM to get multicolors on a globe that size spinning that fast. At least using the common LED driver ICs (though I have one sneaky idea using the TM1829 … mebbe).