HUD thoughts part 2

So, I've revisited the original thoughts on the HUD. I've been learning rotating machinery vibration analysis lately and it put the idea of a piezo driver in my head. This is probably similar to what drove the original Virtualboy 50hz vibrating mirror.

Vertical update is no problem, but the high kilohertz horizontal update requires some alternate ideas. There is a MEMs 2D galvometer mirror that's used in both military prototypes and in a civilian mechanic HUD design from Microvision. Interesting idea, but I fear the drive complexity and cost! Optics always need high accuracy positioning, which makes this project a bit more difficult. I've been considering attaching a first surface mirror to a standard piezo buzzer to attempt a more cost effective solution, but I need to get that hardware first. If it works, I'll be limited by the buzzer rate and how much annoyance I can stand (although placing it in an evacuated chamber might help with this issue, or getting an ultrasonic transducer). Another option is a multi-faceted edged mirror that can provide a rotary multi-Khz rate. This would probably be easier to sync with, but again it'd take accurate machining (16+ facets) and a high speed motor (12K+ rpm) depending onconfiguration, placing a small gyroscope near someone's face if head mounted. If a faceted tube can be designed, this might work well with a very small high speed motor, however.

Other ideas from the scratchpad: Direct AC coupled magnetic field driven vibrating mirror, using a 2nd hand DLP array from a projector,

I'm thinking of experimenting with either a high output laser or a small bank of collminating LEDs (say 8?) to provide a picture. I think the LED's will be a parrallel array, as setting up a line would only give each LED an extended off time, switching and light output per pixel will remain the same, requiring high end hardware. This arrangement will hopefully be a good tradeoff between a single galvo laser and the bulky LED bar.

For the semi-technical curious, a little bit of the basic design idea behind this:

I'm attacking this project as two separate optical components, one provides the "screen refresh", low frequency signal, the other provides the "line refresh" high frequency driver.

The screen refresh will hopefully provide a 30 fps update. Progressive scanning is the current objective. However, via flexible software design, we can cheat. Since a vibrating mirror has to go through the same arc twice in one cycle, a mirror vibrating at 15 hz can provide a 30fps update rate. My current goal is a 60fps update rate for active updates.

The line refresh is a LOT more annoying. I'm hoping to use an SPI or similar buffered serial interface to provide the pixel information to the imaging device (if it's a single laser). These top out at 10 Mbps.

The characteristics above relate together like this:

bps = h-pixel x v-pixel x bpp x fps
screen refresh = fps
horizontal line rate = v-pixel x fps

Example calculations:
800 pixels x 600 pixels x 1bpp (monochrome) x 20fps = 9.6Mbit/s
600 pixels x 20fps = 12Khz horizontal line rate

Note, 12Khz = 720K cycles per minute, FAR faster than even small gas turbines and anything spinning this fast is highly dangerous!

This is possible safely with a small piezo driver or with a high accuracy multifaceted mirror on a small electric motor. The greater the number of faces the lower the RPM, but also the mirror complexity skyrockets. The piezo driver would prove simpler, but garaunteeing its dynamics is a far more complex problem than timing a rotating element.

For standard screen types, the horizontal width of the screen is usually the larger value. This is an advantage as it keeps the line refresh rate lower. Another useful function is that, for a fixed bit rate feed, you can trade off vertical resolution for higher framerates. It'll usually be easier to vary the slow frame update mirror than the high speed (and probably resonant) line mirror. If you turn this on it's side, though, a variable width system is possible, which might be more desireable than a variable height design.

Of course, the above information does not include areas where the mirrors may be out of position or highly distorted. These will in effect reduce the maximum possible video bitrate of the system and necessitate both a synchronization method for the data flow and possible padding of the bitstream with dummy values during periods of distortion.

I'm currently planning to attempt a 1 bit 248x160 display at 10hz update rate as a proof of concept. This is approximately one thirtieth the maximum data rate of the dsPIC SPI architecture and will allow much fine tuning. This requires only a 5hz window update mirror and a 1600hz line update mirror, which can be built from a motor running at 8000rpm with a 12 sided mirror. This will not be head mounted initially. Due to the need for 4.9kbytes of RAM for a video buffer, I plan to use a larger dsPIC (8Kbytes, 20 MIPS) as the video driver. I also hope to use it's DSP functions to both ease code development and update control calculations, and possibly drive a simple vector video engine to greatly reduce the bitrate and calculations required by a master processor. But that's for later.