HOLY CRAP! That is the most amazing LED strip in history! That 1 meter LED strip of 144 LEDs would be perfect for a globe. I could use just one of those as the full circumference of the globe! If I use an Arduino with a Yun shield…
Wow.
Yup, they look real good for probably most POV projects. Not only is the PWM rate high, the data transfer rate is also (reportedly) sky high. Confirmed at 10+ MHz and 24 MHz has been claimed (Adafruit mentions 32 MHz !). So in 1 PWM period (1/19.2k) of ~ 52 usec, you could easily update 20+ pixels. Which in turn makes me think, if you divided the whole strip up into sections, that you could have a horizontal “pixel” (lying along some line of latitude) that is only 1 full PWM period (the best you could hope for) long. Let’s revisit some of the basic math from before …
So with just 1 “half-hoop” with LEDs spanning from just 72 deg N latitude to 71 deg S latitude, using a single 144 LED strip cut into 8 sections of 18 LEDs … you could have 1 LED (= 1 pixel) per degree of latitude on a globe of about 12.5" in radius. That’s over 2 ft in diameter ! The LEDs are 5050s so they are 5 mm on a side and Adafruit spaces their 144/m strips at 7 mm between LED centers. So there’s a 2 mm gap (plus some dead space in the 5050 itself) between “longitudinal pixels” (a pixel that lies along a line of longitude). Another half-hoop (per your OP), spaced opposite from the first (so as to make almost a circle of LEDs) could have it’s LEDs shifted 0.5 deg up or down so as to fill in that gap. That would give you an effective resolution of 0.5 deg of latitude/pixel. The 2’nd half-hoop will be needed for balance anyway, might as well put LEDs on it !
If you could update each LED every 52 usec and spinning the above hoops at 30 revs/sec (1800 RPM), you’d have a horizontal pixel at the equator that spans ~0.56 deg (= 52u * 30 / 360), very nearly matching the above resolution. With a ~ 12.5" radius that equatorial pixel would be ~ 0.122" in arc length … so small that from any reasonable viewing distance you’ll never see any color tearing. Of course as you go north or south from the equator, and sticking with the same 52 usec update period, the latitudinal pixel size decreases (because each circle of latitude is a smaller circle as you approach the poles). At some point, no matter how close you look, you won’t even see individual “pixels”, let alone any PWM side-effects.
Of course you could use the 2’nd half-hoop to, in effect, increase the “RPMs” (by actually decreasing the time between updates for any given pixel) instead of increasing the pixels/deg of latitude if it turns out that a mere 30 rev/sec is too flickery (it might be). A smaller globe using 1/2 the number of LEDs should also work, though at a lower number of pixel/deg of latitude. A ~6" radius sphere using 2 half-hoops of 72 LEDS/half-hoop, w/one half-hoop offset by 1/2 LED from the other … should give you 1 deg/pixel of latitude while still retaining the ~0.56 deg/pixel in longitude, with an even smaller pixel length (0.06") at the equator.
BTW why did I say 72 deg of N latitude to 71 deg of S latitude ? Just because it’s 144 LEDs per strip, and at 1 LED/deg of latitude, you can go from 72N to 71S. And I figure the globe needs a base to sit on so you won’t be able to see some portion of the “south pole” as a result. Given Adafruit sells the same strips in 0.5m lengths and given you can cut them at 1 LED increments, there’s no reason you can’t continue with more LEDs, at the same 7 mm spacing, toward both the N and S poles if you want to. For that matter I see that Adafruit sells packs of 10 individual DotStar LEDs (not on a strip) if you care to make custom PCBs. And if you wanted to you could use 4 half-hoops, 2 circles of LEDs, to both increase the LEDs/deg and (effectively) increase the RPMs.
About the only “bad” thing I can see re: these LEDs is that they are reported to use the data as soon as it gets to the LED. So in a strip of 144 LEDs, the 1’st LED gets it’s data first and starts it’s PWM cycle while all the other LEDs are still getting their data. That means the latitudinal/horizontal pixels are skewed as you go from N to S poles. Your program to create the image will have to account for this and it may be impossible to get a perfectly straight line of longitude, it’ll have the jaggies due to skewing but hey … a small price to pay. And that’s one more reason to divide up a single 144 LED strip into sections and update each section in parallel (to reduce skew). Because you’ll have to feed power and ground into a strip every 30 or so LEDs anyway. People have said that just powering a 60 LED/m strip from both ends is barely sufficient to keep a good supply voltage in the middle of that strip if the LEDs are on full white and bright. I don’t expect the DotStar strips to be any better in that regard.
I could see a (or mebbe 2) Teensy 3.1 driving the LEDs. Supposedly the FastLED library already supports them (APA102 protocol). I’ll have to see if they can be driven in parallel (8 strips at a time) as was done for the WS2812 LEDs. I’m not sure if you can bit-bang the SPI at those speeds.