I came to the same conclusion. I have given up hope on the PWM. My only choice is to do on/off.
Well another limiting factor that I found is the fact that the LED’s I was looking at (single package) do not support the PWM that the TLC supports: https://www.sparkfun.com/products/11679
So the next option is adj. current for each channel. My next thought is to use a multi-channel DAC with a multichannel OpAmp to drive a MOSFET? However I would need to keep the circuit simple to keep rotation stress due to component weight down. The DAC is so that the commanded voltage level is latched so the commanded current is ready for when the LEDs are strobed at once.
I would assume many DACs, w/a channel per LED. Each DAC controlled by some MCU, which in turn is connected to your “data hose” ? The MCU + DACs being the effective replacement for the TLC driver IC. Certainly you don’t need more than an 8 bit DAC and I’ll opine even a 6 bit is more than good enough. Should run off a single 5V supply. Looking at an AD sheet I don’t see many that aren’t over-qualified and so are more $$ than a cheapie single chan DAC. Still the space saving would be worth it.
Wow, those are expensive!
Yup, TI has some less capable and less $$ parts. Here's an 8 chan, 8 bit, 5V, I2C fed DAC.fkatzenb:
Wow, those are expensive!
http://www.ti.com/lit/ds/sbas496a/sbas496a.pdf
TI says $3 in 1k quantities. Digi has it for $3.56 but you’ve got to buy 2k min. Ones ans twos are $8.
http://www.digikey.com/product-search/e … AC5578SPWR
Still a few hours searching about might find something like the above. 8 channels at $3.50 means about $1.30 per RGB LED. Your full boat globe with a 144 LEDs would be perhaps $500 for the electronics (DACs, MCUs, LEDs, etc). How fast do you wanna go ? :mrgreen:
I think this would work:http://www.ti.com/lit/ds/symlink/dac088s085.pdf
So yes, each DAC is controlled by the MCU. So for 32 RGB LEDs (one side), I would have twelve 8 channel DACs, four DACs for each color. I would program all the DAC’s early enough in the rotation to allow the op-amp mosfet combination to stabilize the desired current. When the rotation reaches the desired turn on point, I will switch them all on. Those LEDs are all common cathode, so I will put the switche(s) (based on the combined current).
That part is like a 12 chan, 8 bit part I found at Mouser ($3, less in quantity)
http://www.mouser.com/ds/2/348/bh2221fv-e-210472.pdf
Both will need some added circuitry to drive the LED as they are current limited. The TI can sink 10 mA max, 30 mA total for the whole DAC.
Some of these have buffers and so (I think) can be used akin to a shift register. That is you upload all the data to them for timeslice N while they are outputting the N-1 voltages. Then all you need is an horizontal pixel clock to swap in the new data, all at once. And then begin to upload the next timeslice’s data.
I concur that the above circuitry would work, although I don't understand the switching concept. In actuality I think you're making it more complicated than it really is. When you started this thread you were asking about the mathematics/requirements underlying one approach to making your POV globe. I think we can agree that the original approach was untenable. :cry:fkatzenb:
I would have twelve 8 channel DACs, four DACs for each color. I would program all the DAC’s early enough in the rotation to allow the op-amp mosfet combination to stabilize the desired current. When the rotation reaches the desired turn on point, I will switch them all on. Those LEDs are all common cathode, so I will put the switche(s) (based on the combined current).
I don’t think I’ve got an assumption free set of requirements for the new approach (above) but it’s close. Give me a day or so, that I can try to put them into some semi-intelligible English form. Right now I’ve worked through a set of numbers to cover what I call the “Holy Grail” of a POV globe; a set of req’s that would make a 36" in circumference (just under 12" in diameter) globe, running at 30 revs/sec and having a 1 deg vertical and horizontal pixel resolution … work. And I believe (until further examination) that it can be done (using present tech), in 8 bit/color depth too ! Obviously reducing these uber-goals (less resolution, less color depth) makes the task easier and less $$s.
To achieve the Holy Grail it might take 180 RGB LEDs, 40 eight channel DACs (and mebbe some added “hi-current” circuitry), 5 MCUs (might even be only ATtiny85’s) and 1 “data hose” MCU … a Teensy perhaps. Add a PC to do the globe layout and generate the data to be displayed and transfer that to the “hose”. That might give you some idea of how much $$ it would cost to do the task … or scale it down to something less “holy”.
What would be kewl … a POV globe, 12" in diameter, displaying the world and all it’s weather as seen from space, in real-time (or nearly so) and in “HD”.
I looked at this from the standpoint of designing a POV sphere with a clean sheet and with the idea that I’d specify the requirements that would dictate the quality of the display first and then the parts count, etc would fall out from those choices.
I think the first requirement is that the moving parts spin fast enough to create the POV. I’m not entirely sure how fast that is but since cinema used 24 FPS for quite some time and TVs were 30 Hz for a full picture, I’d set the time between updates to be 1/24’th of a second or shorter. So if you’re swinging just 1 arc, then 30 revs/sec is a good number. If you complete the hoop (2 arcs, but not using offset LEDs per your OP) then you could halve that.
rev_sec >= 24
The next step isn’t a requirement but a choice that determines other requirements, the vertical pixel spacing (the arc length btw V pixel centers). Obviously this is directly related to the size of the LEDs, ie- using the popular 5050 LEDs means a minimum V pixel spacing of 0.2" as the LED is 5mm x 5mm in extent. So the technology available (in terms of LED sze) may dictate the smallest spacing. The upper limit will depend on how large a V pixel you can tolerate and that’s dependant on viewing distance. Note that most POV globes leave a gap between the V pixels but an interesting idea might be to use a diffuser such that each V pixel appears to be contiguous to it’s neighbors.
The next choice is the size of the globe itself. This and the V pixel spacing will determine the number of LEDs.
#LEDs = 0.5pidiameter/(V_pixel_spacing)
Have deterimined the number of LEDs, the number of DAC channels is thus set. Obviously for an RGB display you’ll need 3 DAC channels per LED. Depending on what you can find for parts, this will tell you how many multichannel DACs. Interestingly the color depth really doesn’t have a practical effect on this. All the multichannel DACs are at least 8 bits and I can’t see any reason for using more then 8 bits/color. Even if you want to use a lesser color depth, you’ll end up using an 8 bit DAC. It seem that such DACS come in either 8 or 12 channel varities. So the number of DACs is then:
#DACs = num_colors_LED*#LEDs/num_chan_per_DAC
One consideration in chosing 8 vs 12 is the data rate needed to push all the (8 or 12) channels of data at perhaps 8 bits/channel in the time allowed. Obviously a 12 channel DAC will need 50% more data than a 8 channel DAC. That either means more time or a higher data transfer rare to the DAC. And that is tied to the next choice, horizontal pixel size/spacing.
The maximum horizontal pixel spacing is another choice, like vertical pixel spacing, that then determines other specs. At some point the technology available and the cost of it will set an limit on the H pixel spacing. The upper limit will depend on how large a H pixel you can tolerate and that’s dependant on viewing distance, no different from V pixel size. Note that H pixels, unlike V pixels, are of differing sizes depending on the latitude. H pixels along the equator are the largest in extent, those near the poles … the smallest. The lower limit on spacing will depend on fast the data can be moved through the system. At some small H spacing, there will be a choke point where you can’t find parts that will handle the data rate. H pixel spacing is independent from V pixel spacing though commonsense tells you that the desire to have a “high resolution” display means they will be close to the same value … technology and cost permitting.
Last choice to be made is the color depth. This could be monochrome to 1 bit/color (RGB) up to 8 bits/color. Obviously the deeper the color depth the more realistic will be the display but at the cost of higher data transfer rates. I would opine that color depth should be the first thing traded off to reduce data transfer rate (DTR) problems in the design.
The H pixel spacing and spin rate and then set the what we’ve called the timeslice. This is the amount of time that any H pixel will be displayed. It also is the maximum amount of time available to move all the data needed to setup all the pixels, including any calculations needed to transform image data into DAC data.
Timeslice = (H_pixel_spacing)/pidiameterrevs_sec
At this point it’s useful to determine the data transfer rates in the system to see if the present technology can support what’s needed. To that end some assumptions on the architecture are needed. First is that there’s a “master” controller that either gets the data for every pixel for a whole rotation or computes that data itself from some user input. The data rate into and out of that controller is set by the number of pixels, the revolution rate, the color depth and the timeslice.
Then every timeslice the master controller must output data that will eventually find it’s way to the DACs. The amount of data is set by the number of LEDs and the color depth. So the min data transfer rate is ;
DTRout, min = #LEDsbits/colornum_colors/timeslice
This may be so high that the DACs can’t be “fed” directly, via some common bus, from the master controller. Instead the MC may have to send multiple data streams, in parallel, to “subcontrollers” and then from them the data goes to the DACs. In this case we’ll make an assumption that there will be 1 subcontroller for every 8 DACs, based on a port being typically 8 bits wide for common MCUs. Since these subcontrollers might be tasked with reformatting of the data as well as receiving the data from 1 timeslice while outputting data for another, some time must be allotted for the processing and so a whole timeslice may not be available for using in sending data to the DACs. Thus a budget of 50% of a timeslice will be allowed for computation and 50% for the outputting of data to the DACs. So the data transfer rate from a subcontroller to any 1 DAC (assuming up to 8 DACs will be done in parallel) is;
DTRdac, min = num_chan_per_DACcolor_depth/(0.5timeslice)
This rate may be useful in determining what DAC (12 vs 8 channel, SPI vs I2C, etc) is applicable.
So here’s block diagram showing a subcontroller and it’s connections to it’s DACs (in this case 8 channel DACs). Depending on how many LEDs you end up having, you’d have some number of the “blocks” shown below, each fed from your “data hose” master controller. Shown are connections for the DACs for some 5 blocks and 100+ LEDs. You may notice that I’ve connected them “oddly”. That instead of connecting the R, G and B pins of LED #N to a single DAC, I’ve instead spread them across 3 DACs but kept them on the same channel across the DACs. That’s because it’s most likely that as soon as the subcontroller MCU writes the data to a channel in a DAC, the output voltage changes. Because of the time it takes to transfer data, obviously channel 2 will lag behind channel 1, 3 behind 2, etc, etc. But in the scheme below every DAC channel #1 is updated at the same time, every channel #2 at the same time (if some usecs later). Spreading the LED pins across DACs means the color isn’t smeared over time and thus over space. It does mean some H pixels lag behind others across the globe but that’s easy to fix in the software that generates the pixel RGB data from whatever image you want to be displayed.
(click on to open)
FWIW I took the equations above and stuffed them into a spreadsheet so I could play with pixel spacing and color depth, etc to see where it would blow up. Except for the cost, I think you could do a ~12" globe, with V (if you can find small LEDs) and H pixel spacing of 0.1" and 8:8:8 color depth. Putting a lot of the tasks and data transfer in parallel eliminates the timing and impossible data rates of the original scheme.
Inputs
0.1 = V pixel spacing (in)
0.1 = H pixel spacing (in)
30 = spin rate (revs/sec)
11.4593 = diameter of globe (in)
3 = colors/LED
8 = color depth, R (bits)
8 = color depth, G (bits)
8 = color depth, B (bits)
8 = channels per DAC
Outputs
180.00 = Number of LEDs
33.33 = rotational period (msec)
92.59 = timeslice (usec)
46.66 = DTRout, from MC (Mb/sec)
5.83 = DTRout (MB/sec)
5.18 = DTRout, clock (MHz) (!! Hmmmm, this might be an issue !!)
46.66 = DTRin, to MC from PC (Mb/sec)
1.38 = DTR to DAC (Mb/sec)
67.50 = # DACs
8.44 = subcontrollers
FWIW a pixel pitch of 0.1" is about 10x coarser (larger) than a typical low end notebook display (15.6", 1366×768). Not bad, certainly for a POV globe, but still a ways to go before it’s HD.
You mentioned 32 LEDs (on 1 side) above. I’ll take that to mean 64 LEDs, on a 360 deg hoop but offset ala your original scheme. What the spreadsheet say ?
Inputs
0.28126 = V pixel spacing (in)
0.28126 = H pixel spacing (in)
30 = spin rate (revs/sec)
11.4593 = diameter of globe (in)
3 = colors/LEDs
8 = color depth, R (bits)
8 = color depth, G (bits)
8 = color depth, B (bits)
8 = channels per DAC
Outputs
64.00 = Number of LEDs
33.33 = rotational period (msec)
260.42 = timeslice (usec)
5.90 = DTRout, from MC (Mb/sec)
0.74 = DTRout (MB/sec)
1.97 = DTRout, clock (MHz)
5.90 = DTRin, to MC from PC (Mb/sec)
0.49 = DTR to DAC (Mb/sec)
24.00 = # DACs
3.00 = subcontrollers
So if you want to update the image displayed on every rotation, you need about 6 Mb/sec going into your master controller/data hose. Easy peasy with any Ethernet connection. Then the MC clock outs 3 serial channels in parallel to 3 other MCU’s (aka the subcontrollers) at a 2 MHz clock. Just do-able. The 3 MCU’s then drive 8 DACs each (8 channels in each DAC) with a clock rate of just under 500 kHz. Again sound do-able when FastSPI on an Arduino can do 4 MHz.
Wow,
I am speechless on the amount of work you have devoted to this. I think I may build it somewhere near what you just posted for 64 LEDs. I was thinking that I want to utilize a Wifi shield anyway because it allows me to isolate the globe such that the north pole is the 5v and the south pole is GND. The gnd would be through the motor’s shaft. Then I can have a UI to control it. In regards to your comment about H lagging due to programming each DAC, this was why I suggested putting a transistor on the common cathodes (one transistor per 24 channels) that would in unison allow the current to flow through the LED in unison. The voltage would be stabilized prior.
Revised:
Thank you for the work on this… greatly appreciated.
I think my plan for now is to do the 64 LED design. My question is in regards to your comment about H lagging due to programming each DAC, this was why I suggested putting a transistor on the common cathodes (one transistor per 24 channels) that would in unison allow the current to flow through the LED in unison. The voltage would be stabilized prior to allow for the variable current. I just need to develop an adequate design for the 0-120mA current of that LED.
I was thinking that I want to utilize a Wi-Fi shield anyway because it allows me to isolate the globe to simplify how it is mounted - the north pole is the 5v and the south pole is GND through the motor’s shaft. The UI for control would be thru the Wi-Fi shield.
I feel that I would not be able to use a standard Arduino as the primary MCU for memory allocation. I know I would just push new images bit by bit during its execution in such a way that it would update in a spiral fashion (top down on the globe). If I want to manipulate the current image, such as rotate it, I would just advance or retard the timing to image index. If I wanted to offset the globe on its axis, I doubt an Arduino could dynamical recompute the indexes for that and meet the timing requirements of everything else. I think a Maple could. In fact, there is enough I/Os ports on the Maple, that I may not need sub-processors. http://leaflabs.com/docs/hardware/maple.html
Thoughts?
V/R
Frank
As for a Maple … honestly I just don’t know. I was thinking Teensy 3.0 myself but that’s only because it was mentioned for it’s DMA capabilities (to pump data out, a port-wide every clock) in a related build. I know you are correct re: an Arduino, if not just for the speed of computations, I know it just doesn’t have enough memory**. For that matter if my estimates (below) are correct, neither a Maple (20k) nor Teensy (16k) have enough SRAM. A Teensy is an M4 core, clocked at ~66% of a Maple’s M3 but it has DSP extensions than might be useful. This is a case where you want to figure out the math of the transform needed and then post in the ARM forum re: speed and I/O capabilities. Perhaps you can add memory of some sort to solve the SRAM issue (if I am correct).
As for no subcontroller MCUs … let’s see what that means for the master controller (Maple?). You have 24 DACs, each needs to be fed w/data at a ~ 250kHz rate (8 bits/chan * 8 chan / 260 usec, no computation by the now gone subcontroller MCU). If the core is 32 bits, can you setup a DMA to do 3 8-bit ports at that rate (or higher = better) ? I know neither Maple nor Teensy advertises that many I2C or SPI ports so it’ll be done via software. A single 8 bit port and a MUX and 3x the rate would also work. Both Maple and Teensy have enough I/O pins (43, 34) for the data paths and I suspect for any clocking, loading, channel addressing, reset, etc lines. I would research the fan-out on the I/O pins, you may have to use multiple pins for 24 devices (DACs). The Maple may be the winner here.
As for your cathode switching scheme … as I understand it, then you’d have to have all the DACs written to and outputting their voltages before turning on the LEDs for the pixel on time. That to me implies some sort of pixel off time btw the next on time and that all the data has to go to the DACs in that off interval. Do-able certainly but it does leave that gap btw pixels and almost certainly bump up the DTR needed to feed the DACs. Think of it this way, if you have 128 H pixels to match the V resolution of 64 pixels (in 180 deg) then you have ~260 usec to display each H pixel. How much of that time do you want to devote to filling the DACs with the LEDs off ? Perhaps 10 % ?? So now each DAC must be filled with it’s 8 channels of data in 26 usec, that’s a DTR of 10x what you might otherwise get away with, 2.5MHz vs 250 kHz. Can the master controller and DAC support that rate ??
If OTOH you accept the skewed pixels and no gap, then it’s a matter of mapping the image to be displayed properly into those skewed pixels. Something the mapping software (not discussed so far) should be able to do handily … no extra hardware needed.
This is an interesting project. Sure it’s been done before but how I can see a roadmap to making the uber-POV globe. Last year I had an inkling to make a POV wand for my friends kids. But I wanted something better than the spinning ones that are common. I wanted a wand that you’d wave at any (fast enough) speed and “sloppily” and still get a readable image/text from it. That meant mapping the LEDs into a space stabilized virtual image area. Never quite figured out how to do it w/o too many errors creeping in. Maybe I should go revisit that now. In any case my brain was pre-primed.
**How much memory (RAM) is needed ? I think a 64 RGB LED globe will need about 25kB (64 LEDs * 3 colors * 1B/color * 128 positions/revolution) just to store all the RGB pixel data (at 8 bits/color depth). Double that since you’ll need the original orientation and the new one. Then add some scratch space to do the calcs and then some more to run the program … the 2K of an Arduino … fuggetaboutit.
FWIW I’ve yet to see a POV globe that does more than 8 colors (RGB either on or off) for the reasons we can understand. You could be the 1’st !!! Here’s a pro-version that is marketed. Pretty slick build but still only 8 colors.
FWIW and because this thread took a turn from your original idea I thought it worth mentioning that if you wanted to stick to 8 colors (7 colors + off) and use a 64 LED WS22811 strip, that it could be done. What I would do is break the 64 LED strip into 8 strips of 8 LEDs. Then I would drive each strip (all 8 in parallel) from a Teensy 3.0 using the previously linked to “OctoWS2811” driver library for the Teensy. This should (just) work even though each LED still needs 24 bits and you’d just be doing R on/off, G on/off, B on/off. Sticking with the 128 horizontal pixels gives you 260.4 usec to spew the data out to each strip from the Teensy. At 24 bits/LED and 8 LEDs, that’s a data rate needed of 737k bits/sec, which is under the 800k the WS2811 does. You will have the skewed pixel issue to deal with and I’m counting on little to no delay in re-clocking the data out from each LED to the next in the strip.
But it should be do-able for little cost compared to the more “elegant” method we’ve been discussing. If you wanted to get your feet wet first this might be a way to go. Also the info for all the pixels for a whole revolution could be stored in about 3kB. So doing the transforms to rotate the display should be easy in the 16 KB available in a Teensy.
So there, it’s come full circle … almost. :mrgreen:
Now I’ve got to consider that space stabilized light wand using a magnetometer as well as an accelerometer … :think:
So now I have to deal with more aspects of this. Since each DAC has to lead to current control of 0-120mA, I need something like: http://www.daycounter.com/Circuits/Curr … ervo.phtml. Is this the simplest method? How do I determine the transient response (right word?) so that I know I can go from 0 to any current in the allotted amount of time.
I am concerned that the rotational inertia of all of the chips is not going to be good on the PCB. With the number of components increasing (128 RGB LEDs, 48 eight channel DACs, 48 eight channel OP AMPs, 48 eight channel MOSFETs, plus resistors and caps) I may need to bring components closer to the center.
That link shows a fancier version of what I thought might be used IF you couldn’t find a DAC that could drive the LED directly. This is an emitter follower w/the LED btw the supply and the collector. Basically the same working principle as the link but w/o the feedback.
(click on to open)
Here are the DAC voltage ramping from 0 to 5v and the current through the LED. Voltage across R1 is tossed in so you see how the circuit works.
(click on to open)
Two things to note, first there a few, 0 to ~0.6v, DAC codes that all produce zero current … meaning you don’t have true 8 bit color depth anymore. Perhaps it’s more like 7.5 bits. I say who cares. More importantly you need a higher than 5v supply to drive the LEDs. This is also true of the linked to circuit. The supply must be > voltage(R1)+Vce,sat+Vled,max. Also note that at 30 mA, R1 is dissipating 1/8 W !! Q1 never does more than about 30 mW (given the 8v supply).
It occurred to me that there was a way to not have a supply > the DAC range. What I did was add Q2 and Q3 in a current mirror configuration. Thus the current through the control resistor (R1) is “mirrored” through the LED. Since there’s only the LED and Q3 in that path, the supply voltage can be less.
Here’s the circuit as simulated in LTSpice and the plot of LED current vs DAC output voltage.
(click on to open)
What are the drawbacks ? Well you lose even more fractional bits in color depth (note the DAC voltage when the current becomes nonzero). Yet I still think that’s no big deal, it’s still > 7 bits, which I’d bet is indistinguishable from 8 bits to most people. Obviously you’re adding more hardware, Q2 and Q3, meaning more $s, board space and soldering. Perhaps more importantly current mirrors are common within all IC’s, where the common processing guarantees the transistor parameters are well matched. How well the mirroring works with discrete transistors is ?? I note you can buy matched transistors in a DIP and sidestep this concern.
So the option is there to avoid another supply voltage.
I note no MaiTais were harmed during the above exercise.
Looks like someone had some brains that were pretty big! http://hackaday.com/2014/04/21/volumen- … splay-yet/
Looks interesting. I wonder why he put a cylindrical display in a hemisphere but …
According to HaD he uses 34 micros, leading me to believe it’s 1 MCU per “arm”, each arm having 32 RGB LEDs and 32 arms for the display. One MCU to drive the motor, etc and one to act as the master data “hose”. Looks to me he uses 6 driver ICs (so no Neopixel type LEDs) per arm, which makes sense as 6 x 16 bits yields 96 channels which is 32 RGB LEDs. But it also appears he’s not using any PWM (to avoid the “subpixel problem”), just the 8 primary colors.
Nicely done. Makes me wonder how I’d “improve” on it (if at all possible). Might be interesting to see one done in the “usual” POV globe way, with the LEDs oriented vertically on vertical arms (instead of his horizontal arms), with arms at different radii and spaced every so many degrees so outer radius arms don’t occlude inner arms.
You may have seen a thread where the OP is doing a POV “wand” type display using the 7kHz PWM driver IC. I’ll have to go back and see what size cylinder display such ICs would allow before the PWM became visible. I think I mused over that earlier in this thread for a globe.
OK this is really necroposting but as technology has advanced, so does what’s possible. In this case the OP wanted to use the then new Neopixels in a POV globe. Alas, if just due to the PWM rate of a NeoPixel, it wasn’t going to work. Spacing in time (PWM) meant tearing/spreading of colors in space.
Now I see Adafruit is selling DotStar LEDs. Akin to WS2801 LEDs but w/a claimed 19.2 kHz PWM rate !!
https://learn.adafruit.com/adafruit-dotstar-leds
https://www.adafruit.com/products/2241
So perhaps this project can be done (mostly) as it was originally thought of. I know other posters who wanted to make other moving POV displays (wands, hoops, etc) that used NeoPixels. Those may now be possible.
So for them and the OP, I’m reviving the dead in hopes they may yet live !! :o
