The flat surface would be easier to manage, however I doubt whether you could get anything to loop as quickly as this needs to. We are talking about several hundred revolutions per second. I like the cylinder idea more from the point of view of spinning it a little slower and only using say 45 degrees or maybe even 30 degrees representing the display field. I have a wee refinement on this, using some simpler(?) versions of kit. It is reasonably easy to cut a prism from plastic, if you have the right gear, and I like plastics for weight and robustness. Take 3 small but otherwise ordinary LEDs and point them at a prism. The prism the prism is cut to combine the beam through refraction, and then to spread the beams over a uniform rectangular field. When the prism spins, you vary the brightness of the LEDs to the appropriate colour for the position of the cylinder. As the cylinder has a single hole in it, you get a trace across the screen. What you then do is make say 10 of the prism systems, placing them side by side, inside the cylinder. You the cut the cylinder so that each LED / prism combination serves multiple scanlines. This is where limiting the field of view to 30 degrees of the prism helps. For a single rotation of the cylinder, it is then possible to get 12 scanlines per LED / prism combination, per revolution. So now you have 10 devices, and you wish to generate a 120, by 120 pixel representation. So each pixel will take 3 LEDs set with an 8 bit encoding of the brightness of the three colours (24 bits per pixel), you have 10 LED / Prism devices, each of which handles 12 scanlines, and wish 120 pixels per scanline, therefore 24*10*12*120 = 345600 bits per frame. Multiply by your refresh rate, and you have the input data rate. (13,824,000 bits per second at 40 refreshes per second). As you are effectively working in 240 bit parallel (24 bits per LED /Prism, 10 of) this would represent a data bus rate of about 57,600. As for getting it working, I would suggest a separate 8 bit latch per LED, a DAC per LED, and use a simple sequencer. How I have achieved this in the past, with needing to key data to the relative position of a rotation object is to notch both ends of the cylinder. One end is notched so as to trigger the input to the latches (which thus set up the pixels colouring). These notches are placed so as to compensate for the curve of the cylinder. At the other end is a single notch, which is used to time the start of the frame. It should be a simple matter of timing the input to the basic data bus, using the frame start signal, using the latching signal from one cylinder end to get the data into the latches at the appropriate time and also proving timing back to the data provider. Rather crude, and the processing within the data provider must be a pixel representation of anything you wish to display. Might just have to try this one.... Anyone see any flaws? Chris Hardaker -----Original Message----- From: Johannes Spielmann [mailto:] Sent: Monday, August 09, 1999 10:46 AM To: Charles J Knight Cc:
;
Wear-Hard Mailing List Archive (searchable): http://wearables.blu.org -- Subcription/unsubscription/info requests: send e-mail with subject of "subscribe", "unsubscribe", or "info" to
From Wear-Hard Mailing list Archive (WH)
Maintained by R. Paul McCarty
Archive created with babymail