SparkFun Forums

[fkatzenb]

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

[Mee_n_Mac]

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.

[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.

[Mee_n_Mac]

See my added math above.

So it doesn't look possible at that resolution ... and yet people do RGB POV globes.


How ?

[fkatzenb]

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.

[fkatzenb]

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

[Mee_n_Mac]

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

[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.

[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.

[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.

[fkatzenb]

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.

[Mee_n_Mac]

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 :

Code: Select all

__________,                    ,__________,                   ,__________

(_ = 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 :

Code: Select all

- - - - - - - - ,                    ,- - - - - - - - ,                   , - - - - - - - - 

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.

[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 ???

[fkatzenb]

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.

[Mee_n_Mac]

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.