A person I met asked me how to create an "outdoor" display that could display words, or perhaps even pictures, The problem is that the size desired is /huge/, and no matter how many ideas I came up with, they were prohibitively expensive in LEDs. I now have come up with two ideas that are economically feasible given the non-existent budget they have to work with (it will be out of someone's pocket).

The first is to use a 500mm vertical DotStar strip, using the technique of the person walking by seeing the image. I can find nothing in my searches on this technique.

The second is to use a one-sided SpokePOV, but I want to display not general patterns, but words and images. This means a complex rotational slicing to slice a rectilinear image into an image defined by polar coordinates. And it needs a reference trigger point, which I would do by adding a Hall sensor to the wheel and a magnet on the base on which it is fixed (the trick is to get someone to donate an old bicycle wheel to the project, but that will not be my problem). Due date is sometime around October.

Suggestions for either implementing the first solution or suggestions of how to approach slicing for the second would be appreciated.

I registered to ask a very similar question. I want to build one for a wall at work with the .5m strip to make a clock that can also update to display the weather and have pictures and maybe live updates with news or other stuff. I wanted to use the 144 LED/m dotstar strip as well as one of the new 5$ raspberry pis (or one of my bigger ones until I get the little one).

What I was interested in is whether there was a way to do this without knowing all of the programming, maybe a guide?

As for the rotational position of the the strip I was thinking of a hall sensor as well, or maybe a two cameras that can register black and white strips as off/on staggered in such away that it can count the number of strips for position, or maybe a camera paired with a hall sensor, or maybe even using a gyroscope and accelerometer?

I think your first solution would work out/look a lot better. The dotstar looks amazing in the projects painting with long exposures, I bet it is just as pretty in a "persistence of vision" spinner. What I don't know is how fast it would have to rotate to be perfectly clear, or whether or not it would need two strips arranged in an 'X' shape in order to be sharp and clear.

I also wonder whether knowing the exact rotational position is necessary, or if you could spin it a constant speed and then adjust the refresh frequency of the image until it is correct, or if a motor's speed is too inconsistent for this to work. Another idea is using a wheel speed sensor from a car used in traction control to measure very precisely the RPMs of the display, or maybe power the spinning action with a very large toothed gear and then create a mechanism which counts the number as teeth as they go by, this idea would probably work better due to noise outside, but this idea I kinda like less because it's more stuff to break and it's probably less smooth than if powered directly with a motor on the central axis. You could still add a gear mechanism to it only for counting, not for powering the spin.

The position sensor is critical in that you need to know where "top" is (note that the sensor can be anywhere along a circular path, although positions which are multiples on 90 degrees relative to the viewer's orientation will make the calculations simpler). Otherwise you are guessing, which means that if you guess the rotation rate perfectly, the image would not be vertical, and if you were a snall number of milliseconds off, the image would precess at a rate proportional to the error.

My hope is that once the wheel is up to speed, the Hall sensor will keep the image synced. If we call the Hall-to-Hall time dT, then we can in principle assume that every dt/360 the wheel has rotated 1 degree. If, however, we get to 358 when the Hall sensor says "zero", we need to reset dT to be the actual time. Ditto if 360 happens later than zero. This allows us to compensate for differences in motor speed. Because there is a phenomenon called "gating error", an intrinsic propery of trying to impose quantized states on a continuous function, if we were to reset dT on every rotation it could make the image jitter a bit, but given the frane rate, this just might make it look a bit blurry, which may work in our favor.

My plan is to measure successive dT values once the device is turned on. This means that initially the whell is still spinning up to speed, so only when I get a sequence of dT values that are "close" to each other will I start sending updates. How close is "close". Ideally a succession of values which are within 1/2 degree time of the average time would be ideal, but until I build one and see how well the dTs match, I won't know if the motor can maintain a "constant" speed.

Frame rate: We need on the order of 3m,0 frames per second, which translates to 30 rps, or 1800rpm. This works out to 6mñ ń 48,000 degrees per minute, or 10,800 degrees per second, or about 93uS per degree. DotStars can, if I recall the numbers, sustain 400KHz update, which means that it would take, if this rate can be maintained, about 360uS per update, so picking a value like updating every 5 degrees.. For a 1m strip, the circumference is 2*pi, so in 5 degrees, which means a DotStar rate of 72 updates per second, well below the 2,777 updates per second a 144-LED DotStar is theoretically capable of.

3600rpm small motors are readily available; Getting a 2:1 divider involve a motor gear (or pulley) 1/2 the diameter of the wheel gear (or pulley). While the idea of a bicycle wheel is tempting, a bicycle-chain coupling means a lot of maintenance problems, such as lubricating the chain. Belt drive would be better, but has its own problems. Gear-to-gear drive has the same problems as a chain drivr. Direct drive from an 1800 rpm motor looks like the best option

1800rpm is pretty fast. Having a meter-long stick spinning at this rate makes for a physically dangerous device. So it needs a solid frame around it to protect people from any pieces which may go flying. It needs a cover to keep cutious fingers from becoming that debris. To save money and complexity, I am thinking of a wire mesh on the front, perhaps two inches from the plane of rotation so that little fingers that can reach through the mesh cannot reach the moving parts.

Last edited by flounder on Thu Dec 31, 2015 3:13 am, edited 1 time in total.

If you do a symmetric X you can reduce the rotation by a factor of 4 over a semi-strip size of 1. If you use a 1m strip across the entire X, you reduce the resolution by a factor of 2, but then your whole assembly area shrinks by a factor of 4; instead of a 2m circle, you have a 1m circle, pi*r^2. You could also do two strips, 180 degrees apart, making it easier to make a balanced system. You could consider then making one strip be offset 1/2 pixel from the other, in which case you have increased resolution by using "interlacing". If you keep the same spacing, you could cut the speed in half.

One of the problems I face is getting the system "balanced"; a single arm coming out from the center will be grossly unbalanced. My current idea is to use a bicycle wheel and a 2m mounting, and mount the computer, battery, etc. in a solid box near the center, so a similar box with the same mass, mounted the same way on the opposite side of the axle (I'm thinking of BBs or similar small quantized weights that can be put in the counterweight). If I mount the axle or the motor with a flexible rubber (it doestn't need to very flexible, as long as it has a little bit of give) mount, I can then place a strain gauge between the shaft mount and something bolted to the supporting frame, to check the balance. If the shaft is parallel to the Z axis, then any eccentricity measured along the X or Y plane indicates a balance problem. Note that I only need to measure along one vector, because any imbalance will be detectable; note that eccentric force will always stress it differently across every point around the circle, so if is off-balance at angle theta, it is off-balance at ever other angle != theta, so we only need to examine one vector. Ideally, we make that measurement when the Hall sensor activates, so we know which side weighs too much relative to the other, and can add or remove mass quanta (e.g., BBs) to achieve balance. Sort of like balancing a car tire.

You could reduce the frame time to 27 (old analog tv frame time) or 24 (standard theatre movie projector) or even 18 (the frame speed of old silent films, which is why everyone seems to move fast in them; there are no 18fps projectors available in theaters), but some people can react badly to that flicker rate, which is just a wee bit off from the alpha wave trap of 7-15Hz). But 30 is good for lots of reasons, particularly in the US. For example, the line frquency is 60Hz. You can generate a 60Hz interrupt rather easily. Take a 6.3vac signal. Run one end through a diode. You now have a positive-only semi-sine wave running at 60Hz. Don't use a full-wave bridge or you get 120Hz, which only adds overhead. Now, run that through a resistor that allows only a few ma draw, connect a 5V Zener diode to clip the peak (remember that AC voltage measurements are RMS, and the zero-to-peak voltage is actuall sqrt(2)*rms, and your chips will see that peak)[note: I learned this the hard way when I was 13; I had cascaded in series three 450V electrolytics to get a capacitor with 1/3 the capacitance but 3x the dielectric voltage as one; this meant a capacitor that could handle 1350 volts. I hooked it to a 1200-volt transformer via a rectifier tube (no solid-state rectifier in those days could handle that voltage). I narrowly missed serious, perhaps fatal, injury when one of the metal-can electrolytics punched a hole in the ceiling. The capacitors saw the peak-to-peak of nearly 1700 volts. Oops.] So clamp it with a Zener. A .1uF capacitor would probably reduce line noise. Now feed this into a Schmitt trigger, whose role in life is to convert sloppy slow-rising analog waveforms into clean dgital waveforms. Hook the output pin of the Schmitt trigger to the interrupt pin of the processor. Throw away every second interrupt, and you now have a 30Hz reference signal, that is, an interrupt every frame-start time. In this fashion, you only need the Hall event during startup, if you believe the rotation is actually 1800rpm. Or, as I mentioned earlier, you can use this to see what the rotation speed really is, and adjust accordingly.

Note that the area swept by an LED at the outer edge is much larger than that of an inner LED. This leads to the decision about CAV vs CLV. CAV is Constant Angular Velocity, which means if you slice the image radially you may find that your new image loses resolution at the outside edges, and may even have all-dark "slices" radiating from the center. Or, to get better resolution, you slice the image so the outer edge is one pixel from the previous slice. This may result in an angle so small that the update frequency exceeds either the DotStar's maximum update rate, or perhaps the processor's ability to keep up with the updates. Constant Linear Velocity means that you update the string at a rate based on constant linear displacement, which means you don't have to update the inner LEDs as fast as the outer LEDs. Alas, DotStar, like NeoPixel, is a giant shift register and to update the 144th pixel means you have to write the previous 143, so nominally we still have all the problems of data rate and data size to deal with. But we could do a simple run-length compression by noting, at slicing time, "pattern N+1 is exactly the same as pattern N, except for...". Now we only need to keep one full vector in memory ready to write out, and then modify it by applying deltas to it. At T0, say when the strip is vertical, we start by writing the first vector from the sliced file, then apply deltas to it until we have done all the updates (one key frame, and a set of deltas, like MPEG). The frequency of the updates has to increase, however, so the CLV is maintained for the outermost LED. Which leads to the same problem as before: DotStar and processor bandwidth become the limit. But wait! There's more! Suppose that, instead of a single 144 LED DotStar, we cut the signal lead between two of them and now have two 72-pixel DotStar strips. We run another lead out to the second half. Since under CLV, most of the LEDs in the inner strip will remain unchanged, we don't have to rewrite those. So now, most of our updates will be only half as many LEDs. Lather, rinse, repeat. Using 8 equal partitions means only 18 DotStars in a segment. Faster update, lower processor overhead. But then ask, "Why do they have to be 8 equal segments? Is there a partitioning that gives better behavior by "front-loading" the CLV partitioning, making the most-frequently-changing segments as long as they need to be, but no longer, and the steadier segments long? Would a partitioning of 1/2;1/4;1/8;1/8 work better? Would 80;20;20;12;12 work better? Note that this can be computed statically at the time of slicing, and after slicing some sample images, a partitioning can be chosen that, if not optimal in all cases, is not pessimal for every case.

For a 1m arm, the circumference is 6.28m. This means that at 30fps, the velocity of the outer edge is 188.5m/sec. In one hour, the outermost LED would have traveled 678,584m, or expressed as a velocity, 678km/hr, or 420mi/hr. Hmmm...maybe this idea needs more work...

Maybe two 1/2m strips, interlaced, can do better. Same resolution, smaller space, half the rim linear velocity at 1800rpm. Or a single half-meter strip, 1/4 the rim linear velocity (105mph); run interlaced, it would give 72dpi. So to simplify the coding of the skicer, let your favorite image tool reduce your image to 72x72 pixels, and the slicer only works on 72x72 images, period.

Have to think about this more. Note that if I have 1/2m, that's only 72 DotStars to update two "scan lines" at the same time, one for the even-numbered scan lines and one for the odd-numbered scan lines which are 180 degrees away.

Hahaha, no kidding, reading your responses it's surprising you asked for ideas implementing this :-) Your explanations are super thorough and for someone a layman to such thinking fairly easy to understand. Now, my implementing this I can see may be difficult without a hand holding step by step tutorial and maybe already written GUI software that just needs values studied and adjusted.

Really appreciate your explanations on the physics of what's happening. Since what I was thinking was more of a clock sized device I think sacrificing the diameter for reduced rotational velocity is ideal, heck, even maybe slicing it again and ending up with a 9in diameter and 8 dotstar spokes might even be ideal.

Your profession as an engineer is not surprising after reading the section of you building high voltage capacitors when you were 13 :-) I bet you probably knew an engineering degree was your future from a pretty young age.

I was always fascinated by science. I just didn't know what kind of science. I was the first person in my family to attend college, and, like most things I try, I overdid it. Majored in math, would have had a minor in physics if they hadn't stopped awarding minor degrees the year I graduated. Then went on to get a PhD in Computer Science from Carnegie Mellon University. I have been a software developer for over 50 years, an educator, both as university faculty and as an independent teacher, and finally an independent software developer/teacher for the last 25 years of my career. I still have interests in physics, astronomy, cosmology and geology.

In retirement, I do volunteer tutoring in (third grade) math, teaching tween-to-teen courses in electricity and electronics, and my other main hobby seems to be making LadyAda rich. I joined TechShophttp://www.techshop.ws and have learned to run several CNC machines, from little 3D printers, to a CNC 3D router made by ShopBothttp://www.shopbottools.com/mproducts/prsalpha.htm that lets me cut designs in any "soft" material (up through oak and maple, but not metals) up to 4' wide and 8' long. [it is also the first router I used which was not manufactured by Cisco; that's computer geek humor], and for metals, a 2D waterjet cutter that directs a blast of 60,000psi water and abrasive and can cut precision shapes in any metal, up to 6" thick steel, on a 10'x10' work surface. And an 80W laser cutter http://www.troteclaser.com/en-US/Laser-Machines/Pages/laser-engraving-machines-speedy.aspx that can cut a widely-varied set of materials, or etch them. It is the kind of toyshop I always dreamed of. My next target is the Trotech 3-axis CNC vertical mill. Retirement is fun.

But I'm doing so much I can't keep up with it all. Yes, I could write the program, but it would suck down many days of my time, days that could be better spent building something else, or teaching someone else, or designing something utterly cool. joe