Forewarning: You can do this the easy way, or the hard way. The easy way is to pick an RGB LED that has good stocking at all the major distributors, try it, and be happy.
The hard way is to learn a little bit about photometry, which is the study of measuring light, and then make your decision. No guarantees that the latter will produce better results, though. But, it's probably best to know a little background, so here we go. Warning: Long post.
Basic Criteria
The basic criteria for selecting an LED are, ignoring color for now:
- Intensity/brightness
- Viewing angle
- Lens style (clear/diffuse/external)
From the top:
Intensity/Brightness
This is a measurement of how bright you want your LED to be, and is startlingly complex. For an RGB LED, you'll probably find it easiest to first specify the viewing area, and then select the number of lumens you need. This selection will probably be experimental, especially since you want to do it at Burning Man, which has a really bright environment.
There are two ways to measure intensity: Radiometrically and photometrically. The watt is a radiometric measurement for power, defined by the metric system in terms of electronics as:
$W = A^2 * \Omega $
In words, the power dissipated by one amp of current flowing through a one ohm resistance.
Photometric measurements define how bright a source appears to the eye. The candela (or, for LEDs, the millicandela or mcd) measures the intensity in a direction. The lumen is a measurement of power, and is defined as one candela over one steradian of area (a steradian is a cone about $64^o$ across). Both are weighted with respect to the radiometric units by the luminosity curve, which looks something like this (dotted black line):
Notice that it peaks around 550nm, or the color green. What this means is that your red and blue colors need to have high wattage ratings to get even coloration. If you use the millicandella ratings (for a variety of viewing angles) or the lumen ratings (if you've already selected a set of similar viewing angles), you don't have to worry about this curve.
If you're still paying attention, don't worry, the rest is more straightforward and shorter.
Viewing angle
The viewing angle is the maximum inclination that you can have with respect to the LED and still see the color emitted. This is a function of the lens, and isn't always uniformly distributed. For a diffused (cloudy) lens, if you can see the lens, you can see the color, if only a little bit. The viewing angle is not necessarily this number; they're usually more realistic and only define the area which the lens is designed to illuminate. For a clear lens, optical properties of the lens will define the viewing angle more rigidly. Hint: It's not 180 degrees for the T 1 3/4 package (the standard 5mm LED you showed in most of your links - that's usually no more than $30^0$).
For a POV globe, you probably want a fairly wide viewing angle.
Lens Style
Lenses can be tinted or colorless. For an RGB LED, you probably want colorless. They can also be water-clear or diffused (cloudy). Your choice in this selection will depend on the viewing angle of the LEDs. A diffused lens will help to eliminate bright spots, but will also reduce the effectiveness of any focusing the lens is designed to do. If you get an LED with a spherical lens, it needs to be diffused, or you'll blind your users as it spins, and it will be hard to see in others.
You also need to decide whether you want an integrated or external lens. Some superbright LEDs will have an external lens which allows higher quality optics but costs more and requires more components. For this project, you almost certainly want an integrated lens.
Electrical Properties
Next, you need to consider the electrical properties:
- Current, both nominal/test and maximum (Will be different for each color of an RGB LED)
- Forward voltage $V_F$ (will be different for each color of an RGB LED)
Current
An LED creates light by dissipating power across a semiconductor junction. Below a certain current, the electrons aren't boosted to the next shell, and you get no light. Above a certain current, you destroy your device. By modulating the (average) current between these two values, you can get varying degrees of intensity. This is a non-linear function with respect to light intensity, but you can get a more linear function by using a constant current and rapidly pulsing the LED on and off. This technique is known as pulse-width modulation, or PWM. If your PWM never exceeds a given duty cycle, and is sufficiently fast, you can set the constant current at which would, at steady-state, exceed the maximum power rating of your LED. This doesn't usually get you a brighter average, though.
You need to select LEDs whose current requirements are within the limits of your drive circuit and whose power requirements are sustainable using your chosen power source.
Forward voltage
The forward voltage will be different for each color in the LED. This just complicates the calculation of the current a bit. If you're using a resistor to set the current, and the LEDs are common-anode, you should probably select LEDs with similar forward voltages to minimize power losses in the resistors. Be aware that the forward voltage is a function of the forward current!
Standard stuff
Then, there are the generic properties that you need to select for any electronic device:
- Package
- Soldering temperature
- Manufacturer/Supplier
Package
You may be tempted to use a standard T 1 3/4 5mm dome package. Don't accept this unless you're sure that it's what you want. To get 4 leads under this package, you need small, tight holes (soldering and PCB manufacturing will be hard), and the optical properties are less than optimal.
There are a plethora of surface mount packages which are lower profile and lower weight (which is desirable if you want to spin your project) and which have high viewing angles without using diffused lenses.
Soldering temperature
LEDs are some of the most sensitive components to heat when soldering because of the optical requirements of their lenses and because of the unique semiconductors used to generate the light. Be careful if you're using anything but a temperature regulated soldering iron or oven for this.
Manufacturer and distributor
For a one-off project or prototype, Adafruit or Sparkfun products are fine, but (1) you'll pay a premium for their selection and endorsement and (2) you're out of luck if they drop the product. The hobbyist sites are fine if you're making a one-off product, but if you want to distribute plans, make sure a compatible LED is widely available. Otherwise, contact Cree, Avago, or Lite-On (or your favorite manufacturer) directly, or use a major distributor like Digikey or Mouser. You'll have better luck and get better prices by buying in bulk and skipping the middleman.
Color
One of the most important factors to consider is color, but RGB LEDs basically define that for you. You do need to consider the relationships between each color in your selection, but this can usually be accounted for in software. For instance, the human eye detects green much better than it detects blue, and red LEDs are usually more efficient than blue.
In addition to the relative power between the colors, you need to consider the spectral information. Many manufacturers have different definitions of each color - Red might be any light with a wavelength between 629nm (an orangey red) and 660nm, green could be from 515nm to 565nm, and blue could be anywhere from 430nm to 470nm (a greenish blue). And that's just the nominal peak! This isn't a laser, so not every ray of light coming from it has the same wavelength -there is an irregular distribution of the wavelength for each color. A red LED will emit a tiny amount of blue light, and vice versa.
Best Answer
1. A bunch of 74HC595 chips will work great. Other chips that would also work just as well and perhaps slightly better are listed at: Which SIPO chip is better, 74HC4094 or 74HC595 or something else?
2. The Arduino is an excellent choice for prototyping, especially if you are comfortable using gcc. Perhaps it would be quicker to use one for now. Alas, I suspect you will soon write code for this POV display that needs more RAM than the Arduino has available -- at that time, either (a) use one or more of tricks to reduce the RAM needed, or (b) add some external RAM, or (c) port the code to some other microcontroller with more RAM (perhaps the ATMEGA1284 ?).
The Parallax Propeller is an excellent choice for a high resolution POV display -- it has an order of magnitude more internal RAM (32 KB RAM) than the ATmega238 in the Arduino. (Is there anything I can do to support porting gcc to the Propeller?)
Some people prefer "square pixels". I'm sure you already know that the distance around the equator of a sphere is twice as long as the distance from pole to pole (Earth's equator is a little more than twice as long). Since you have 64 pixels from the south pole to the north pole, you might choose to reload a new vertical "line" of pixels 2*64 = 128 times per revolution in order to get 128 "square pixels" at the equator. The simplest way to do that is to store the full frame uncompressed in RAM. That requires 64*128 pixels * 3 bits/pixel = 24 576 bits = 3 072 bytes, plus a few bytes of RAM for other program variables. Alas, the Atmel ATmega328 in the Arduino only has 2 048 bytes of RAM.
Earlier POV displays used microcontrollers with an order of magnitude (!) less RAM than this. So people have developed a variety of tricks you can use to work around this. One trick: Only lighting up the "front" half of the globe turing the time you can see the LEDs, then turning off all the LEDs (or leaving them on some constant color) during the "back" half that you can't directly see the LEDs. That halves the amount of RAM you need, so then it fits in the Arduino. If you don't like that trick, there are other tricks you can use that are less obvious. Another trick: Store the image in the flash program memory. The Arduino has enough flash program memory to store several 3 072 byte frames. Yet another trick: use ASCII text to store the text you want to display, then use flash program memory to store the "character generator ROM" data. I'm pretty sure there are other POV tricks ...
3. If I were building it, I would power the Arduino and the 74HC595 chips from one big power supply, and power the motor that spins the POV from a separate power supply.
Only after I got all that working would I even consider a more complicated separated power supply system. (In principle, if you have a separate "red" switching power supply whose +V is only connected to 74HC595 chips which in turn are only connected to red LEDs, you could independently tune its output voltage to minimize the total power and heat production of the system. But it seems unnecessarily complicated.)
4. and 5. Perhaps the simplest way for the Arduino to drive the POV display is to daisy chain all 24 74HC595 chips in one long single string, and then use the Arduino SPI library. That requires 192 clock pulses to clock in the new column of data, and then a pulse on the RCLK (aka framing pulse, SS, etc.) to start displaying that new data. According to one Arduino to SPI interface tutorial, the fastest SPI clock rate is system speed / 4. So the 16 MHz Arduino can put out a SPI CLK of 4 MHz. If you upgrade it with a 20 MHz crystal, you can get a SPI CLK of 5 MHz. If you can get your program fast enough to keep up with the SPI hardware, you can put out a new column, at best, in 5 MHz / 193 pulses, so the maximum theoretically possible speed is 25 907 columns/second.
At the standard cartoon film refresh rate of 24 frames/second (which flickers noticeably -- you would like something better), and at 128 columns/frame to get "square" pixels at the equator (you might want more to get better resolution), that gives 24 frames/second * 128 columns/frame = 3072 columns/second.
There's nearly an order of magnitude of breathing room between "the speed you want": 3072 columns/second, and "the speed that is completely impossible on Arduino hardware": 25 908 columns/second. Hopefully that gives you enough room.
Some people think you can get a faster column refresh rate by re-arranging the 74HC595 chips into 2 or more chains and loading all chains in parallel. Some people are like that -- they see unused pins on the Arduino, and they are itching to use them for something. But it may be counter-productive -- the SPI hardware is only connected to one set of pins on the Arduino, and so chains hooked to any other pins must be loading with emulated "bit-banging" software, which will invariably be slower and use more CPU time than the built-in SPI hardware.