scroll down 👇

Worked with Manusha on getting GSYNC to work; see the Near Eye Display page for this.

Over the past several days, I have created / revised the following boards for the next instantiation of the Mixer-Amplifier circuit. These are all modularized sections of the Mixer-Amplifier board. They are made to be either stand-alone with SMA connectors on the end or soldered together to form a larger board.

They were submitted to CircuitBoard.com up in Salt Lake City for fabrication on Thu 1 Dec 2016.

The boards sent were the following:

I also had Windows 10 installed on the computer Cameron used to work on in order for Manusha and I to investigate using GSync for the Near-Eye Display.

(this entry not yet finished)

Taught Jesse how to reflow circuit boards while making two more HELA-10 boards. Made a video of the process to teach others.

made/revised the following boards:

• Preamplifier
• HELA-10 (revised)
• Mixer w/o decoupling
• Mixer w/ decoupling
• Calibration boards
• DVI Breakout with impedance matcher (revised)

New panel-sharing service discovered: link

The new HELA-10 module boards came in today. I assembled one using the reflow oven and made a mount of how I'm envisioning them being combined in parallel in the HoloMonitor. I tested the output and found that the gain is 9-11 dB as advertised at about +25 dBm output. I didn't take it up to full power and was putting in only about +18 dBm. I swept the signal generator manually and recorded the output with a spectrum analyzer. In the four minutes I had it on, it did not become warm.

I'm very happy with the result. The flatness of the gain suggests no design issues (particularly, impedance matching or ground issues). This means we can make our own HELA-10 modules now, which will be cheaper than ordering individual modules (even thought the HELA-10 chip itself is expensive).

The board was reflowed in the EE Shop's reflow oven using the “wave3” temperature setting.

The drop at the high end of the frequency response is the limit of tested signals, not a limit of the hardware. The HELA-10 doesn't amplify DC, hence the drop near DC.

These boards can be either stand-alone or parallel, as shown below. There is solder in the vias and thermal pads underneath, per page 34-35 of this HELA-10 application note. The gaps between the channels is meant to help increase isolation. If needed, nylon washers can be used to electrically isolate the modules from each other.

Click on picture for high-resolution:

I also coached Dallin as he assembled a power supply.

Things done over the past couple of days:

• helped Jesse with debugging new Scanner Shield
• threw away / stored old parts
• cleaned up back tables for use with Scanner Shield debugging, modulator cartridge building, Near-Eye display development
• helped Scott with Near-Eye display
• worked on software to help characterize new RF hardware faster using OpenFrameworks and GPIB commands
• talked with Scott about several RF schemas we could use in the HoloMonitor
• went over HoloMonitor timing calculations with Kamran
• went over HoloMonitor point-cloud holographic algorithm with Kamran

I was pretty busy earlier this week with some big class projects.

I'm revising the Mixer-Amplifier board, but in stages this time, using everything I've learned about RF board layout since the 27 Jan 2015 revision. Improvements include: not using thermals, using soldermask only to contain solder during reflow and not anywhere else, not being so crazy with vias, alternate sides for components that connect to ground, using thermal pads, power isolation, ground isolation, being more careful with impedance matching calculations.

This board was made to be either standalone (a module) or integrated side-by-side with other boards. The two half holes on the top and bottom are machine screw holes.

The below board is 2.33“x0.91” on standard 63mil FR4.

The boards were ordered from OSHPark on Wed 9 Nov 2016 23:58 PST and cost $10.60 for 3 copies. USPS Priority Mail (2-3 days) was chosen to expedite shipping at $5.00. They ship from Lake Oswego, OR.

The boards were received by OSHPark (not delivered to BYU) from the fab on Fri 18 Nov 2016.

The boards were delivered to my personal residence on Mon 21 Nov 2016.

This board is based off of MiniCircuit's TB-17 evaluation module for the HELA-10B:

We also got more parts for the monitor (C14+switch+fuse integrated power inlet and +12V to +9V regulator). This integrated power inlet will help reduce monitor assembly time. The +9V regulator is needed for the PHA-101 amplifiers.

The EE Shop takes either .SVG or .DXF (need comment on outermost dimensions) files for their laser cutter. They use Inscape.

The integrated power inlet used needs a 66.3mm x 27.11mm hole. The diameter of the laser beam needs to be taken into account to not expand these dimensions.

I also created a general wiki page for our 8020 parts while clearing out 500 old emails.

I've been working on the Mark V Inventory & Assembly with Jesse.

Also, this is what the thick modulator looks like up close. I should spend some more time to make sure this is correct.

I spent some time characterizing MiniCircuit's PHA-101+ amplifier. I'm excited about it because it has a P1dB compression point of 26dBm, operates between 50 MHz - 1.5 GHz, and has a gain of 15.2dB. This is great because it can serve as an intermediary amplifier stage between the GVA-84+ and HELA-10+.

Normally, we've tried to drive the GVA-84+ to maximum power output (+20 dBm) for the HELA-10+ to hopefully boost up to +30 dBm, but the signals always compress and create harmonics. These harmonics are bad because they cut down on the maximum power the HELA-10+ can produce. Although signals add linearly, meaning their powers and frequencies will stay the same when you combine and separate them, the combined signal's maximum amplitude increases for every signal added, meaning compression will occur at lower power levels the more equal-power bandwidth is used.

* subject to change depending on application

In testing with a single signal with weak harmonics, the PHA-101 only consumed 170mA. The amplifier was on a small PCB with little thermal mass and surface area and almost became too hot to hold. It is not known if it'll need a heatsink on a larger board with through-holes.

The PHA-101+ was tested and it exhibited much weaker harmonics than the GVA-84+ while delivering output signals in the +20 dBm range. In the below graph, a power input of about +5 dBm (near left end of data sets) was sufficient to deliver the target HELA-10+ input power. The harmonics at this point remained below -25 dBm – a 45 dB difference at +20 dBm output! With the GVA-84+ being forced to deliver around +20 dBm, the harmonics were around +5 to +10 dBm (although I should measure this to prove it).

The performance of the PHA-101+ could qualify it as a potential replacement for the HELA-10+ if the needed power levels are below +25 dBm.

Pictures of the 1st Acrylic Monitor

ZACH and I finished aligning the optics between the laser deck, the polygon/galvo assembly, and the parabolic mirror. We also worked on the setup video below. I also worked on the demo programs so that they could be stand-alone.

Note that the laser used in the below video overheats in a matter of minutes, hence, the switch on the side. When it overheats, the image becomes progressively dimmer. You have to turn the laser off and wait for it to cool down.

Worked with Jesse on auto-locking code. I developed code that measures clock cycles between divided HSync (DSYNC) events, polygon tachometer (PTACH) events, and the phase difference of the two using interrupts (INT2, INT4, INT5), and uC counters (Timer3, Timer4, Timer5).

We also discovered that setting the PLL_ATTEN potentiometer to near no attenuation would provide great locking results. The potentiometer may still be useful for working with the PC2 output, if we ever use that. If we never use the PC2 output, we can just eliminate the PLL_ATTEN potentiometer and connect the PP output directly to C1.

In measuring DSYNC and PTACH events, some measurement error occurs. In the below graph, the blue dots indicate the time between DSYNC events in clock cycles. The orange dots indicate the 4-sample running average. (Note that previous samples aren't stored in any array, the “N” factor just describes how slowly the average adjusts.) The transient spikes possibly occur from other interrupts occurring. There are 1,650 samples in the below graph.

One note about the 4-sample running average: the algorithm multiplies the samples by N in its computations, and we have 16 bits to work with (not using 32-bit long numbers, which are available in Arduinos). We'd like to use powers of 2 for N to use bit-shifting for easy divisions (we have to divide by N in the algorithm). N was set to 4 since 65,536/4 = 16,384 would be the maximum number of clock cycles in between DSYNC or PTACH events without overflowing a 16-bit intermediate computation used to calculate the running average. This would allow a minimum PTACH frequency of 16MHz / 16,384 clock cycles = 976.5 Hz, which is great because that is approximately the lower limit of the polygon motor. If we used 8 samples, then the maximum period would be 65,536/8 = 8,192 clock cycles ⇒ minimum 1.95kHz, which the polygon motor can't provide.

In this next graph, the system is in lock. The left vertical axis indicates the phase difference (gray series) in clock cycles, and the right vertical axis indicates the elapsed clock cycles in between DSYNC and PTACH events. 105 samples were taken at about 1Hz. Phase error, when the system is in lock, is either -80, 0, or 43 clock cycles, which probably occurs from the atomic interrupts (which take roughly two-dozen clock cycles) being triggered almost simultaneously. When locked, PTACH and DSYNC events occur roughly within +/-200ns, which is +/-3 clock cycles of each other. No averaging was used here.

Final assembly steps of acrylic monitor!

SCOTT finished aligning the optics for the laser deck. I'll have to align that output with the polygon mirror/galvo now.

Video of sweeps - skip to 1:15:

Had problems with interrupts based on the POLY_TACH line not being reliable. Discovered that the signal was high for less than a clock cycle. After patching the POLY_TACH line so the trigger was longer, the interrupt worked perfectly. The regular, parallel lines below evidence this. Documentation written in the errata of the Scanner Shield page.

Finished power supply for acrylic monitor, made various adjustments and parts, started setting components into place.

Worked for 6 hours on the Near Eye Display, mainly VCO breakout, power connections and some RF Chain assembly. Still have to finish RF Chain, Scanner Board, and software.

Trained Jesse & Dallin for 4 hours after the meeting on writing an Arduino program that will take care of locking.

Comtinued working on Near Eye Display. Finished the fuse box.

Important skinny mirror improvements:

• double backing eliminates waviness
• need to adjust a potentiometer on galvo driver to fix whining and heating

ZACH came up with the idea of gluing two long, identical mirrors to each other to stiffen them. The mirrors had previously been glued together at an angle, so I soaked the mirrors and galvo connection (excluding the galvo) in acetone overnight to dissolve the old superglue. This was able to separate the two mirrors from each other. I remounted the mirrors using our 3D-printed mirror aligner tool and got an Arduino board to flutter it similar to normal operation. When I used the mirror aligner I inserted only one mirror and made sure the reflective part was on the same side as the cable port of the galvo. After carefully sticking on half a drop of superglue, making sure I didn't get any glue in the axle or the aligner, I waited for it to dry before carefully removing the glued galvo-mirror from the aligner. Afterwards, I used a little superglue to glue the back mirror on. This back mirror is not there for its reflectivity, but to stiffen the actual mirror. I glued the non-aluminium-coated sides of both mirrors together.

I shone a laser from the top and bottom of the long skinny mirror while it was fluttering. It seems that the waviness is gone, as far as I can tell: (purple circle indicates roughly where the laser was reflecting)

Individual points could be seen, but I don't think these are the points I want to see. There were about 100 points, but the code was stepping through about 256 positions. The points looked like this:

When I was initially testing the mirror, it would whine at 11.50kHz (I analyzed an audio recording later), and the galvo motor would heat excessively, close to the point of being painful to hold. I decided to try to adjust some potentiometers on the driver board to fix this. I found a potentiometer setting that would eliminate the whine and drastically reduce the heating:

The eBay listing for this galvo indicates the following potentiometer adjustments are available, but doesn't specify which function goes to what potentiometer:

I desoldered a potentiometer to see if there were any identifying markings. There are no labels for any components anywhere, so it's a guessing game what these do.

Also, I discovered the oscilloscope's icon memory got corrupted somehow. This might have been because it was plugged into an old, faulty power strip that had very intermittent outlet connections and would cause the oscope to power-cycle in rapid succession.

I'm making some basic calibration RF boards to analyze with a network analyzer to study losses, impedance (mis)matching, calibration (short, open, 50-ohm), via wall spacing, combining boards together by soldering them, and attempting filters again with some new insight (inline and no thermal reliefs).

Made the backs and spacers for the C-bracket modulator holders. Backer taps are 1/4-20, spaced about 6cm apart.

Drilled + tapped the C-brackets used to hold R&D modulators:

I was able to get locking to occur more easily by removing AC_AMP (shorting the output of IC10C to it's negative input), and by setting PLL_ATTEN to x4 attenuation (75kOhm from PCP output to tap, 25kOhm from tap to GND).

Motor values ranged from 3391 to 3414 for this setting of PLL_ATTEN. It seemed that when PLL_ATTEN was x2 attenuation (50k-50k), it was more difficult to lock.

I'm not sure if C9 and R6 are necessary anymore with AC_AMP gone. I'll have to remove them to see if they are…

I've been able to get locking to work on the Scanner Shield, but I'm still trying to find an optimum combination of potentiometer settings so it locks more easily.

Jitter:

Also, the Precision Machine Lab is able to make well-balanced polygon disks. I spun one up with compressed air to high RPMs and felt very little vibration:

In testing the lock capabilities of the Scanner Shield, I discovered that there are similar characteristics (behavior, sound) of the polygon motor to that of normal operation (which is good, because that means we're getting close to making this work and that there aren't significant design flaws yet).

However, the current thermal dissipation is insufficient: while nearing locking, the transistor will become increasingly hot to the point of untouchable while the motor's RPMs decrease. I'm going to remove the power transistor and stick it directly onto a bigger, external heatsink. If that solves the problem of runaway heating, I'll cut a mounting hole and put the bigger heatsink on the Scanner Shield board.

Solved a problem with transmission line ringing with a long trace (POLY_TACH).

Solution (and nice infographic) documented in the board's errata.

Will commence testing with locking tomorrow.

Having problems with thermal management for the polygon motor transistor. Not sure if it's because of an insufficient heatsink or there's a problem with the circuit…

Scanner Shield testing continues:

• Good News:
  • Polygon motor control works! I had the DAC generate a very-low frequency triangle wave (.1Hz) and the polygon motor RPM would follow by ramping up / ramping down in RPMs.
  • Polygon motor enable pin works (it's actually active-low).
  • Transistor stays comfortably warm during steady state RPMs.
  • Tachometer output works.
  • Tachometer divider flip-flop works.
  • Polygon motor driver ramps between 8.8-17.2V, close to design (9-17V).
• Needs Attention:
  • Transistor becomes too hot to touch if RPMs continuously ramping up/down significantly.
  • R14/R30 silkscreen labels are swapped.
  • Tachometer signal at opposite end of board (measured from JP3 pin 3) has significant ringing. (This ringing is not present at Arduino Pin 3.)
  • USB +5V and ATX +5V are conflicting, need to build a supply separator.
  • Still need to figure out galvo clipping problem.
• Untested:
  • PLL loop/IC

The Precision Machine Lab reported on their attempts to create a mirrored finish without diamond tools. It wasn't impressive at all. They only made 1-2 passes on their test aluminum. I did several (~5) passes of decreasing cutting depth, with a polishing compound, to get the results I got in my Thu 12 May 2016 report. I'll call my contact about diamond tools and get some quotes.

The PML said they would proceed to attempt to create a balanced polygon for high-RPM testing.

Continued debugging the Scanner Shield CCA / DVI Breakout:

• Good News:
  • Arduino powered with both computer USB and external ATX supply; no problems so far
  • fixed cold-solder joints
  • HSYNC, VSYNC, I2C work
  • ribbon cable works
  • EEPROM works; it wasn't burned out
  • correct frequencies generated on RF outputs
  • SPI works
  • both DAC outputs work as expected, ranging between 0-4V approx.
  • 40103 HW divider works
  • flip-flop /2 dividers work
• Needs Attention:
  • copper mask short found in a DVI breakout board
  • unexpected clipping in galvo output voltages
  • scaling or offset wrong for 0-5V to 9-17V circuit (currently 8.8-12V)
• Untested:
  • correct laser scanner interface pinout
    • tachometer works?
    • polygon driver works? (will need to set ENABLE pin)
  • pulse stretching? (not currently needed)
  • PWM / ESC operation? (not currently needed)
  • PLL locks?
  • various control modes?

The 1st Scanner Shield board has been fully assembled and is undergoing testing. There have been a few cold solder joints causing problems but I'm not too concerned about that. The new DVI breakoutboards connect to the computer when the Arduino raises the HotPlug pin, but doesn't disconnect when it's lowered. The correct resolutions and HSYNC/VSYNC settings are produced. No voltage bus shorts or reverse polarity installations have been detected yet.

A significant mistake was found with the -5V regulator, in that two of the pads were layed out in reverse. A simple patch was made and installed, as shown below, and it worked. This -5V regulator patch will have to be installed in the other 5 Scanner Shield boards later on.

Not all of these components will have to be installed in the future as we experiment with this board.

Finished fully assembling a Scanner Shield board over Monday & Tuesday, I performed initial tests today and will upload findings when I can.

Fleshed-out a new page on Graphics Cards, with contributions from Boyd.

Cleaned up the Monitor Project top page.

Stuff for me to do:

• Boyd
  • new graphics cards for desired framerate
• Cameron
  • practice with GitHub
  • go over EDID 1.3 structure
  • check DigiKey order
• Drew
  • write OF project for hi-res images
  • check CircuitBoard.com order
    • called; they're going to try to have it done Friday
  • check up on PML's progress on polygon mirrors
    • called; they'll be working on it soon

Major documentation efforts on the 1 Aug 2016 revision of the Scanner Shield board have been completed. Documentation available here. (Accessible through Monitor top page.)

The Helium-Cadmium laser's boxes (for the laser, power supply, and wood palette) were moved to the catacombs:

The Scanner Shield is done and sent off to the fab (CircuitBoard.com). I've been in contact with their sales rep, “Chris” (801-974-5164, sales@circuitboard.com) and hopefully it'll be done in time for local pickup by Friday.

PCB layout:

Top Physical Appearance:

Schematic:

scanner_shield_prototype_1aug2016_sch.pdf

1. get more 8020
2. write a page of everything I know about RF board design

I have measured the approximate tau constants describing the ramp-up/ramp-down behavior of the 6-sided polygon mirror.

• Shutdown - the polygon mirror is stopped, no power applied
• High Freq - 1.651kHz
• Low Freq - 1.058kHz

This was performed by temporarily replacing the PLL loop filter output with either a 0 or 5V source (a GPIO pin on an Analog Discovery) that then went to the bias/scale op-amps that drive the BJT transistor of the polygon mirror.

A potentiometer was added to scale the output tachometer signal down to 200mVpp before being fed to my computer's audio card's Line In port. Audacity was used to record the signal (44.1kHz sampling rate).

With Audacity recording, the breadboard/polygon driver were powered and driven to a high, constant frequency (asserting 5V to the bias/scale op-amps), then to a low frequency (0V to the bias/scale op-amps), then again high, low, and high before being turned off. The circuit was turned on one more time and turned off to get redundant measurements of the power on/off tau constants. The recording then was stopped.

With the recording in Audacity (and saved to disk), a spectrogram of the frequencies was plotted with the following configuration:

The offset and scale of the axes (kHz/pixel, seconds/pixel) was recorded, the e^-1 & 1-e^-1 levels were calculated, and the time constants were measured based upon a snapshot of this spectrogram:

In this image, green lines represent asymptotic values, yellow lines represent tau values (e^-1 or 1-e^-1), and black lines demark time regions. If you zoom in on the image, the yellow-dotted line indicates the 11th harmonic, and the red dots indicate the tau-level crossover points.

Tau's were measured based upon the 11th harmonic (12 * f_poly) since measuring harmonics increases the measuring resolution of the fundamental tone. The 11th harmonic was the highest measurable harmonic.

The spectrogram was flipped upside down so that pixel coordinates (measured in MS Paint, 0 = top row, height-1 = bottom row) would be proportional to the frequencies.

Document containing calculations:

tau_up_tau_down_startup_shutdown_analysis.rtf

Signal Recording (MP3 compressed from original WAV file):

• trained a bunch of people on how to use Eagle
• got the GUI code to start loading images, now using ofFbo's, figured out some weird bugs

• finished assembling & electrically verifying the DVI breakout board

I finished the GUI code that saves to / loads from a JSON file that describes the configuration of the stereogram program. This took about 6 hours.

I also finished designing a new DVI breakout board that breaks-out the HOT_DETECT pin. I'm excited to test if we can get the Arduino to tell a computer when the monitor is 'attached' or 'detached'. This took about 5 hours.

Progress on the Stereogram app:

Currently working on file reading/writing, JSON parsing, then will work on making it functional with Andy's stereogram app as first demo.

Gave Andy, Boyd, Keith, & Zach thorough training (2.5 hour discussion) on AOMs in general, the MixAmp board, and RF circuit challenges.

I used the green 4-jawed lathe in the MeEn shop on the 1st floor of the Clyde to part a 3.5“ aluminum rod. The TAs taught me how to use it and auto-feed the parting tool. The surface results varied based upon the number of times I readjusted the parting tool.

I worked more on software today. One thing I wanted to develop was a function that would give me the red, green, and blue frequencies and amplitude weights so I could just input a relative angle and get these parameters out for a uniform, white output.

After several SPECULATIVE (ie, “eyeballing it”) measurements, I ended up with these graphs:

They show that, thankfully, the input frequencies/output angles are about linearly correlated. This is great for making a function (shown in the graph).

However, the weighting for the red, green, and blue amplitudes changes a lot based upon angle, resulting in non-white-balanced images at different angles. Reasons for this include:

• uneven diffraction efficiency of red/green/blue light across angles
• uneven AOM frequency response / inconsistent AOM impedance matching
• uneven amplifier/filter/mixer frequency responses
• uneven RF cable frequency responses
• uneven graphics card frequency response
• misalignment of incoming laser light
• misalignment of outgoing laser light
• segments of AOM output sweep clipped from mirror misalignment

To measure the angle, I foam-taped the angle ruler to the holomonitor's Lazy Susan, and foam-taped a laser pointer on the other end. I set up a mirror to reflect the laser light back to the pointer when aligned correctly, and zeroed out the angle measurement. When the monitor is rotated, the angle ruler's laser-pointer end needs to be rotated to keep the laser light reflect back to the pointer to get an accurate measurement. I actually tilted the ruler up a little bit so the reflecting light would be hitting the ruler, and not going back into the laser.

In the below picture, you can see the reflected green laser light bouncing off of the ruler, the mirror in the top-right corner, and the measured angle in the bottom-left corner.

I talked to Nick Hawkins, the supervisor of the 1st floor Clyde Building machine shop (CB 150), the manager of the Precision Machine Lab, the TAs of the Crabtree machine shop about making the polygon mirror, and even Nick's supervisor briefly by accident. All of them agree that machining a near-perfectly balanced polygon mirror, spinning at ~15,000 RPM, with mirror finishing on the sides, is going to be a tough machining project. We talked about tooling, sources of jitter, crystalline structure deformations from metal extrusion, etc… not to mention avoiding the vibrations from the construction going on. Nick and I settled upon a plan that addressed several of these issues. I still think it's possible, with this plan and the tools available, to get something better than what I've been able to come up with so far by hand / the lapping wheel.

I'll write up a description of our discussions and the planned procedure after making models of the milling parts.

VERY useful material discovered over the past couple days:

Kugler Flycutter F3000-2X
POLYGONAL MIRROR FABRICATION TECHNIQUES - page 253
Single Crystal Diamond Tool Cutting on CNC precision Lathe - rotation, feed rates
Diamond flycutting of plane mirror surface

Things needed to make this work:

• monocrystalline flycutter tool/insert, this costs about +$160
• air-bearing CNC mill… nope, make do with what we have

Screen-peaking is now impossible:

NOTE that we can't publish anything with Mario Kart because of copyrights.

Live N64 Mario Kart gameplay (only one view enabled):

0:43 - Mario Raceway
1:14 - (brief whites test)
1:34 - Bowser's Castle
2:17 - Rainbow Road
3:24 - DK's Jungle Parkway
3:24 - (blue removal tests; the level is mainly greens and browns)

A problem that's going to come up in general soon is the fact that, for the Mario Kart demo, we are averaging 12 different sine functions (3 colors (RGB) for 4 players), so each will only have 1/12th the maximum amplitude, thus making all of the images dim. One possible fix to this is to show the players' windows in different parts of the output so that they don't overlap.

I also tried out various materials for polishing the polygon mirror with the T-Brace.

Standard 8.5”x11“ paper, picnic napkins, the thin 'napkins' at the surface mount stations in the EE Shop, and cleanroom paper towels remove the mill bit gouges, but leave their own gouges. Perhaps I'm pressing too hard?

Styrofoam makes no scratches, but leaves the surface dull:

I want to try out cork, various cloths, some of the cleanroom polishing sheets (not disk mounted), and the Sierra Gems diamond lapping disks (1200 & 3000 grit) next with varying degrees of pressure.

Completed the “T-Brace”. This setup will hopefully make each of the facets perfectly coplanar with a flat surface. It prevents the disk from rotating side-to-side as it's being polished on a flat surface.

The double-long, spliced tan cable has a signal loss of 0.67 dB @ 300 MHz.

Having success with the N64 Mario Kart software… a few more tweaks are needed.

Learned more precisely about the code we're using; the new GUI code made possible by ANDY has come in handy in this development.

TODO: what did you learn about the software?

NOTE: Based upon the output I've seen so far, I'm worried that 12 signals being averaged into one (3 colors x 4 viewports into one signal generator) will make all the signals dim and unviewable. Perhaps I could adjust the software to add a virtual gain + clipping?

ALSO made more progress on determining manufacturing steps for our custom 12-sided polygon mirror. After some advice/guidance from the EE Shop, I decided to (end) mill a new face on each of the facets. The mill bit was a 9/16” x 1/2“ bit, and the speed was 2600 RPM. The finished surfaces were flat and consistent with each other, and the bit's grooves were removable with MOTHER's Mag & Aluminum Polish. Still need to find a way to polish it consistently without making more grove patterns.

MOAR TODO: what did you learn about making polygon mirrors?

I was able to get a reflective surface on the custom 12-sided polygon mirror! This is great, because, with the 12-sided polygon mirror, we can double our vertical resolution to 104 lines, halve the amount of data we waste, and halve the width of the horizontal blanking lines.

This is probably one of the weirdest pictures I've taken here.

I flattened the facet with the 1200-grit pad/wheel. Unfortunately, this is a severely-worn pad and has several nicks that jut up and create deep gouges (see top-right image below). For the blue 9um? pad, it took a ridiculously long time to grind most of those nicks out; we'll be ordering a new 1200-grit wheel soon from www.sierragems.net. The blue pad ended up grinding on a different plane for some reason, although it did make a completely flat surface (on the left of the facet in the bottom-right image).

I also made an anti-sprinkle skirt for the polisher out of scrap 3D printed parts and duct tape (bottom left); it works great!

I was tired and didn't give the pink pad much of a chance to prove itself, so, frustrated, I just got a cleanroom towel and MOTHER'S Mag & Aluminum Polish and rubbed the polisher firmly into the facet for a couple of minutes, and, what da ya know?, it was shiny and I could see the reflection of the ceiling lights clearly! It didn't work for the right side since the deep gouges were still there. I took the marmot picture above after doing this.

Chris and I discussed at length different ways to drive a high-count ultrasonic phased transducer array. We went over tradeoffs between parallel vs serial driving, software vs hardware complexity, phase delay circuits vs direct signal driving, etc… We explored parts and costs on DigiKey. Chris will perform further investigation.

Scott needed a demo image of the holomonitor output for a paper. Here is a showcase of 52-pixel tall images and their respective display. The pictures down to the 1st “Image Savant” picture were taken with an exposure duration of 1/10 second. The 2nd “Image Savant” picture and following were taken with an exposure duration of 1/6 second. ISO setting at maximum (6400?) for all pictures. Click on an output image for higher resolution.

NES Super Mario Bros 2 (TM) Nintendo

Banjo Kazooie (R) Rare

Chinese embroidery

Chinese embroidery

Christmas scene

imagesavant.com

imagesavant.com

The Great Wave off Kanagawa

Mandelbrot Set

Mandelbrot Set

Mandelbrot Set

Pokémon (TM) The Pokémon Company

Pokémon (TM) The Pokémon Company

sunset

sunset

Wikipedia - Terraforming

#1: Worked on the GUI, added arrow key and modifier key functionality for slider adjustment, communicated with developers on GitHub.

#2: Fixed the compressed air line running to the femtosecond laser table. It floats again now.

#3: ANDY D. gave a copy of his Mario Kart Nintendo64 emulator. He owns an actual Mario Kart N64 cartridge, so his copy of the cartridge ROM is legal. As long as he's a member of the research group we should be ok borrowing his ROM.

#4: Also was able to find code to do high-framerate, low-latency screen video grabbing in OpenFrameworks, the code framework we use for driving the HoloMonitor. This is a key development in showing N64 Mario Kart / [whatever you want to show from the desktop] on the HoloMonitor output.

The video-screen-grab code was improved from https://forum.openframeworks.cc/t/solved-recursive-screen-recording-solution-for-desktop-feedback-loop/22491/14. Posted findings to forum.

High-resolution high-framerate GIF conversion following http://imgur.com/gallery/r5qmc. (MP4 converted to JPGs using http://image.online-convert.com/convert-to-jpg)
Low-resolution high-framerate GIF conversion at https://convertio.co/mp4-gif/.

TODO:

• add AUTO SWEEP to gui, hide widgets when not used
• test variable binding
• investigate giving disabled widgets a disabled look
• add output control mode to gui
• edit 'BYU MultipleModulatedDiffractionGratingFullColor' for Mario Kart video input
• polish polygon mirror
• moar stuff

projects I had up at end of day if I need to reopen them:

• recursive desktop recording
• BYU TriDiffractionGrating
• ofxDatGUI doodling
• BYU HoloMonitor Sweeper Suite
• eventsExample (for keyboard modifiers)

I modified the code to add green and blue to the previous hologram algorithm. Image below shows depth map, homomonitor output, and color map:

Skip to 2:23 to see parallax example:

ANDY D. and I worked on adding code to his gui project. Following image is a snapshot of it using a GUI, multiple windows, and graphics card code:

Andy D. and I also talked about making a cellphone app (webpage, actually) that will let you take pictures to eventually be displayed live on the monitor.

KEITH and I talked about how to take 3D models (from 123D Catch) and format the mesh data to be displayed on the holomonitor; backface culling is going to be computationally intense.

ANDY D. was able to get a GUI interface to work! Besides doing this (and perhaps more importantly), he also got multiple windows to work! GUI's will make the hologram software more user friendly, which will facilitate developers, and multiple windows will give us the possibility of controlling more than 3 DACs for high channel count (>3) AOMs.

Upon reviewing Andy's code, I'm seeing that there are several improvements that can be made in the current code…

The Holomonitor hasn't been worked on for a while and there's been a lot of movement around it since then. Demonstrations over the past month have become increasingly less impressive, and I was wondering if something had been knocked out of alignment or if temperature changes had caused this.

After carefully evaluating the alignment and making a few adjustments, I've been able to bring back full color:

However, this is only available in a narrow region, and blue is very dim, necessitating that red and green, which the modulator interacts well with, are turned down to just as dim levels. I'm worried that the coverage of each of the channels will too patchy to constitute a full-color hologram; we'll see what we'll be able to do.

This monitor is not mechanically or thermally stable; tiny perturbations can easily knock it out of alignment. I look forward to when we can get the laser-cut / 3D printed monitor working.

ERICH and I discussed at length how to interface to the new super big & expensive “Golden Plates” galvos. We opened it up and discovered there was a digital interface board. After going over the datasheets of the chips on that board, we discovered that it was a digital RS-485 interface. More discussion is on the following page: golden_plates

SCOTT and I tested the new polygon adapter yesterday on the cleanroom polisher without the polishing compound. We're going to have to get some new grinding paper. The polisher has a wobble, but it worked for initial tests.

I also presented in the IEEE-HKN poster competition and made this poster on holographic video. It's meant to give a broad overview and only go over critical concepts / details.

holovideo_on_the_cheap.pdf

The poster was printed in the EE shop.

I finished carefully milling the polygon mirror polisher adapter so that there is little jitter in the parts. There was lots of blind nibbling done with the manual mill to close in on the desired tolerances. Also, removing burrs and filing surfaces/edges made a big difference in removing friction.

The center bar can be flipped upside down if a larger mirror is used. The adapter should be pushed up while it's being clamped to the grinder arm so that it is 'level'. The bolt is used to hold everything in place while grinding.

Finished modeling the mount that will mount the polygon mirror onto the grayroom grinder. I'll probably just mill it by hand since there aren't too many features that are critical, plus I'm too impatient for the CNC mill for this.

Still need to figure out how to polish aluminium without ruining the polishing plate.

SCOTT and I have investigated a few ways of making our own polygon mirrors; including aluminium-casting 3D prints, water-jet cutting, and CNC milling. CNC milling is the only technique that can deliver the precision we need for a high revolutionary speed polygon mirror.

I also have measured the dimensions we need to build a mount to polish the CNC-milled polygon mirrors to the cleanroom polisher.

I've developed an algorithm in Matlab and C++ for GPUs to generate holographic fringe patterns based upon depth maps. The algorithm still needs improvements, but some success has already been achieved:

I also found a strange artifact in some data I gathered:

The histogram profile came while looking at the distribution of pixels value that were the sum of several sine waves added together from the chirps in the hologram. The x-axis is the value of the sum, and the y-axis is the count of pixels with that sum. Pixels of zero value were omitted. Other holograms had the same basic histogram profile. I made this profile to help me understand the range of values I could clip to make the averaged image brighter.

Routed ethernet cabling from the original ethernet port of the monitor's computer to where the computer currently is in the following manner:

The 50 foot cable cost $5: $0.08/ft cable, $0.50 per ethernet plug head.

The shipping boxes for the femto-second laser equipment was moved to our space in the Fletcher.

When we had the microwave, refrigerator, Ben's computer, and the femto-second laser on all at the same time, this tripped the circuit breaker. That wasn't good for the expensive laser. No damage, but we shouldn't keep doing that.

Joe Bussio and I believe that the built-in wall outlet next the laser is on a separate circuit, apart from the outlets that have external conduit on the West and North walls, and the Northern-most conduit-powered East wall outlet. I moved the laser power splitters to the built-in East wall outlet hoping it's not on the same line as the fridge and microwave.

We're trying to make our own 12-sided polygon mirrors so we can double the screen resolution to 104 lines and improve the aspect ratio to be more square-like and not sliver-like. A couple different variants are shown below, along with an experimental UV curer (reference1 reference2 reference3). We're going to have to find somebody to teach us aluminium casting (Ben, Scott, and Joel have connections).

Dr. Smalley and I talked about how we would make the perfect mirror-like finishes we would need. We're thinking about using the grinder in the cleanroom. A special mount would have to be made to make all of the facets parallel to the disc. I incorporated planetary holes in the discs to slide onto such a mount for this purpose. Perhaps we could make it spring-loaded?

The new optics table was finally brought in! It weighs literally a ton (or more).

We're super happy to get it and made bubble-wrap popping sounds with it.

For the air needed to keep the optics table level, I ran a tube from the EE shop into our lab. I kinda wonder if it would've been easier to run it into CB 495, but then we would have had to split the line in there somehow. It took about half a day scrounging around in the Cleanroom and a visit to the hardware shop in the Brewster building to find parts that would fit together. This experience makes me hate how we have BOTH the English and Metric system.

In the ceiling of 420, showing the pipe that leads into 420A:

The tubing held (initially) and was able to elevate the table. The tubing later tore at the adapter where it plugs into the regulator under the table. I shut off the air and softened the tubing with a lighter flame and slid it back onto the port again. Hopefully it doesn't tear again.

Move complete. All directly-related monitor setups and equipment have been moved out of CB 495 into 496. Temporary wall material had been bought earlier in the week. The old table and surrounding shelves have been wiped clean.

3 things that happened today:

1. Laser cut and test-assembled new monitor chassis.
2. Tested long galvo.
3. Characterized frequency mixers, VGA breakout board.

Using dimensions provided by BEN and SCOTT, I used the Epilog laser cutter in the PRL (Project Realization Lab) to create the optics box for the new monitor. I forgot a couple of details, so I'll have to take it back and cut a few more holes in the near future. It looks nice and sleek!

It took several passes at high power and low speed with the fires of Mt. Doom to cut through the acrylic, perhaps the laser cutter needs to be cleaned? (ps, the laser cutter caught fire a month later and was destroyed when a student left it cutting)

CAMERON and I also tested the long galvo mirror to see if it would shatter. IT DIDN'T SHATTER! It flutters like normal and the motor doesn't heat up. We did, however, notice a strange, curvy artifact we can't explain, as pictured below.

Why is the line curvy?

While revising the modularized MixAmp board for the new, 3D printed monitor, I discovered that signals coming from the VGA breakout board (rev. 19 Nov 2015) were destructively interfering with each other. It is unknown if this interference occurs in the graphics card, DVI adapter, VGA cable, or VGA breakout board.

In the graph below, the solid, brightly colored lines represent when we are measuring from channel X and the other two channels are turned off and terminated. The dashed, brightly colored lines represent when all three channels are on, at the same frequency.

The worst interference occurs when we're measuring from channel X and the other two channels are ON and UNterminated, as indicated by the faded, long-dashed blue lines.

Scott and I talked at length about improvements to be made to the Mixer-Amplifier board; some of these are recorded on the Mixer-Amplifier board's wiki page.

We also assembled and tested various amplifier modules to study different combinations of amplifiers. The results are on my cellphone; I should post them here.

TODO

Zoltán Vörös from the University of Innsbruck, Austria, emailed me back and said the 8-sided polygon mirror came from a Lexmark C752 laser printer. The motor PCB (labeled “KS-46 1”) was assembled by Sankyo and uses a “BD6792FM” brushless driver.

Scott also characterized Dr. Smalley's mixer board.

It's been difficult to find a supplier of >6-sided polygon mirrors. The only luck I've been able to have so far is with Copal Electronics.

14-sided polygon mirror.
7-sided polygon mirror, or here.
5-sided polygon mirror.

I sent in a quote request to Nidec Copal and emailed the University of Innsbruck, Austria about 8-sided polygon mirrors.

The fire marshal also met with us and asked us to work with BYU facilities.

We'll also be making an acrylic box for the body of the new HoloMonitor.

SCOTT retrieved his beautifully-modeled 3D-printed mount from the printer and installed the mirror, lens, laser, galvo, polygon mirror, and vibration dampeners:

The laser tachometer setup works and we got it to lock in a working holomonitor. We haven't tried it yet with one of the large 5cm parabolic mirrors, as that requires chopping off part of the bottom of the current mirror base to align it with the galvo mirror (see sagittal plane of optics simulation below).

I should also do a shout-out to BEN, as he's also made a very intricate model of the original scanning mount.

Scott finished modeling the awesome new mount for the polygon mirror, galvo, and laser tachometer using the parameters determined from my optical path simulation below. This was made for the 5cm parabolic mirror, but after reviewing how much the galvo would have to traverse in order to fill a moderate portion of the screen, Dr. Smalley decided we should move to a parabolic mirror of a longer focal length. The focal length of the current toy mirrors is 2.91” (7.39cm), with a diameter of exactly 9“. Changing the focal length in the simulation and mount models should be easy.

The next parabolic mirror should have a larger diameter than this.

The 3D print job will be done at about 2:35am, Wed 3 Feb 2016.

Cameron and I also finished and sent off the .PDF documentation for Charley to change the resolution to the new 3872 x 3293 resolution.

A 1cm margin (each side) was given to the galvo mirror to allow for more deflection near the borders of the holomonitor output. The galvo mirror will be 5.2cm long and 0.354cm wide.

For shipping, the long, fragile galvo mirror should be kept in the mounting assembly used to mate the mirror to the galvo.

The optical path simulation has been updated and uses the large 5cm focal-length parabolic mirror. We'll be focusing the parabolic mirror on the polygon mirror instead of the galvo, as the galvo sweeps across a narrower field (producing less overall visible distortion). A general idea of the possible ranges can be obtained from these .GIFs. Note that the outgoing beam is columnated and has a wider deflection range than the incoming (AOM) beam. These .GIFs are high-resolution.

Transverse plane:

Sweeping AOM; polygon at 0 degrees.	Sweeping polygon; AOM deflection centered.
Sweeping AOM; polygon at 15 degrees.	Sweeping polygon; AOM at half left deflection.
Sweeping AOM; polygon at 30 degrees.	Sweeping polygon; AOM at full left deflection.

Sagittal plane:

Even with the galvo not at the focal point of the parabolic mirror, over medium-sized regions, the rays are still roughly columnated.

First of all, we have FULL COLOR VIDEOS (still flat, in one direction):

The original attempt at this video had a large source file (1280×278 pixels) that stuttered a lot. The stuttering (intermittent framerate drop) was solved by scaling the source file down to 240×52. The first attempt is located HERE.

Scott and I also had a good conversation about sources of distortion in the monitor. Since we're going to be 3D printing a lot of new mounts, we're freed from a lot of past constraints and distortions of the original hardware. I drafted up some profile sketches in Autodesk Inventor and found some issues, such as the current architecture having a different focus horizontally as opposed to vertically. Will discuss my findings later with Scott, Ben, and Cameron.

Also, it was miserable cropping and resizing videos using freeware. I ended up using VLC to resize videos exactly how I want and Video Toolbox to crop videos exactly how I want. Either can convert formats. I used Online Convert to convert videos to GIFs.

After finding a few more quirks in the math and EDID programming, I tried optimized settings for a Holomonitor with 52 lines at abt 30fps: (note the vertical horizontal blanking bars are just barely perceptible now)

I counted about 49-ish lines (count up along the green bar, then along the top-left blue bar), so if there are no duplicates (I should try out different patterns to be sure), then the settings worked!

The settings, mathematics, degrees of freedom, and constraints identified will be posted tomorrow.

There's still a lot of green/blue background noise, but that wasn't the focus of today.

If you look closely, it looks like red is shifted a little bit to the right, and blue is shifted a little bit to the left. Not sure if the fault lies in the AOM, post-AOM optics, or OpenFrameworks software.

Settings documentation updated.

Cameron and I came up with optimized display resolution settings and identified constraints and degrees of freedom. The developments have been logged in the Custom Resolutions page.

I continued to readjust the optics to try to get as good as images as we got before. I might achieve greater gains by trying to reduce background noise.

Our correspondent requested documentation on a procedure to change resolutions to reduce blanking. The sections Custom Resolutions: Changes and Custom Resolutions: EDID Resolution Reprogramming are the results.

I continued to analyze maximizing resolution; this will necessitate adjustments to the EDID data, Synchronization CCA (either knob settings or/and circuitry), and our OpenFrameworks software. I've completed a draft whitepaper going over the constraints and degrees of freedom of the HoloMonitor timings. It concluded with new, preliminary settings that maximizes resolution and minimizes blanking, and I will review this with Cameron tomorrow.

Scott was able to get the blue laser working again without us having to uninstall it. The blue laser diode itself still worked, and we replaced the driver with one of the dozens of 'general Chinese laser driver' boards we had laying around for our blue lasers. The laser leads were backwards from the port on the driver; we figured that out by testing continuity ('Short/Diode Mode') with a multimeter.

In the hassle of unplugging and replugging the cables… the lasers got misaligned. I spent several hours today trying to realign the lasers. Red and blue are back to normal. Green is being difficult to couple in; I had to use a glass slide to very slightly translate the beam, but this may have made it worse because the green part of the images is now shifted up. Background noise has also increased. Will continue working on it.

I should say here that Scott and Ben did a great job aligning the tricolor modulator. The image came out perfectly after the downstream optics got aligned.

Cameron and I talked more about revising the Sync board and trying to get more resolution out of the system.

Cameron was able to get interrupts on the Arduino to work, and the Arduino now detects the HSync and VSync pulses accurately and generates nice sawtooth ramps.

A little bit more optics alignment (periscope, parabolic mirror) and adjustment to code, and WE HAVE FULL COLOR IMAGES!!!

[need to explain frequency-division color-multiplexing code here]

The frequencies used were the following:

I also made the same adjustments to the holographic video program and tried a couple of clips, but the vertical resolution is too poor to recognize well-known videos (ie, The Simpsons, which has bright, separated colors and is well known). The framerate appeared good, as far as I could tell.

Toward the day's end of work, the power supply (“Lambda” brand, triple adjustable output, looks like it's from the 80s) running to the blue laser decided to FREAK OUT and put 20V on the control line, which accepts 0-5V. It wouldn't turn back on again.

For “Align #2” info, see Wed 20 Jan 2016 post.

General things accomplished this past week: office rearrangement and cleaning, desks cleaned, holography-related materials and tools concentrated into one area.

Monitor things accomplished: got blue sweeping (weakly) over polygon aperature, got RGB lasers hooked up to individual power supplies, found and installed a working Arduino galvo shield, tested the 24V galvo with +/-12V plugged into its +/-15V input (it flutters, but need to install mirror and test again), swapped out polygon scanner assembly for one that was better shaved.

Need to write interrupt-driven code for Arduino galvo driver to not miss H/V sync pulses.

Need to install a mirror on the galvo and test.

Need to see if we can get more gain on Arduino galvo output.

Need to install lens for telescope (have), align periscope optics, test with parabolic mirror.

Need to write tri-color computer driver code.

Missed VSync pulses in Arduino galvo output:

Red, green, blue being swept across approximate polygon aperature:

For our first color monitor (really, red and green; no blue), I worked on making a modularized replacement of the MixAmp board for better performance. (The Hela-10, red channel on board 'D' might have burned out, and upconversion is terrible.)

I made another VGA-EDID breakout board for this. I programmed it with the minimum blanking settings, which means that the Arduino code will have to be rewritten to interrupt on edges, rather than polling on levels (which sporadically misses H/V Sync Pulses with the minimized blanking settings).

The modularized upconverter and amplifiers were assembled the day before; I had to include attenuators in various locations to prevent the signal from reaching the compression point of the amplifiers, which dumps energy from the desired signal into unwanted harmonics.

For the ADE-1 upconverter, I discovered that it is best to have the following connections: - carrier signal going into LO - graphics card signal into RF - upconverted output from IF

This results in the desired upconverted signal being +3dB > LO signal, and +14dB > intermodulation products.
With RF and IF switched, upconverted signal drops 7dB, LO increases by 5dB from other configuration, and intermodulation products. I should post detailed pictures of this.

I removed the LO signal from the output by putting in a DC block on the graphics card output, with the series capacitor on the front and parallel inductor on the end.

Dr. Smalley determined which transducer worked best, and I plugged the amplifiers' output into this one.

The modularized MixAmp setup:

The optics arrangement at the end of the day:

The galvo stopped working in the W1 monitor that Charley drove back down to Sponsor #1 (in Los Angeles). I was flown down on Thu 3 Dec 2015 and flew back up Sat 5 Dec 2015. The monitor was repaired and the trip down to LA was a success. The summary email I sent out is after the pictures:

(The picture is a Mission Impossible: Ghost Protocol reference; Tom Cruise is yelling “mission accomplished!” as he deactivates an in-flight armed nuclear warhead seconds before it hits San Francisco)

The parts I took to Sponsor #1.

The tiny “closet” Charley has to work in. The right computer controls the monitor; the left computer is used for generating 200MHz bandwidth signals for Charley to develop RF boards.

TL;DR version:

Mark IV saved the day.
Our red galvos might not work as needed.
Windows 10 can support our monitor.
Don't get booked into “The Standard” hotel.
Additional research funding lightly discussed.

Normal version:

Issue #1:

I fixed the galvo that wasn't working on the W1 modulator at Sponsor #1. I don't know what caused the original one to stop working. My guess was that it was being driven to the rotational limits because of bumped galvanometer scale/offset knobs on the Arduino shield, and that the controller board just kept dumping current through the galvo until the driver failed. (The driver board shorted out the -24V bus.) We should maybe change these knobs so they don't get bumped so easily.

I tried using another galvo that was compatible with the red +/-15V galvo's we've been buying lately, but the motor generated a ton of heat and was squeaking. It may have been that that motor was a bad one that we tried using before (it didn't have a mirror, which is why I chose it). I didn't try a brand-new galvo because that would've entailed removing the old, smaller mirror and chipping away at the epoxy at the mirror-axle joint. Somebody should test to see if a brand-new “red” galvo can swing the larger mirrors we use.

I replaced the galvo with the one that was still on the Mark IV. It worked just fine and didn't overheat. The thought of salvaging that one came to me after I had arrived in LA (prayer works). This illustrated the importance of having redundant components at remote locations to me.

Issue #2:

The funky 3552×2476 resolution also works now with Windows 10. It took me a while to figure out how to make it work because the settings panel I typically use to make changes had been replaced. Normally I access the Windows screen resolutions settings by right-clicking on the desktop and selecting “Screen resolution,” but this window had been replaced by a heavily over-simplified version that didn't give me what I needed (typical of Windows 10). The normal settings panel was found under Control Panel > Display > Screen Resolutions, and I made the necessary change to make it work (extending the desktop onto the newly-connected monitor).

Issue #3:

I also discovered that the optics assembly, even with a 1/4” metal plate, is susceptible enough to heat to unalign the optics. Even lifting the plate by one corner changed the alignment. We should seriously look into changing the topology (perhaps to a 3D-printed one, which Cameron, Scott, Ben, I, or others could design) so that components aren't so structurally distant (ie, optics-pole-plate-pole-optics vs. optics-plastic-optics).

Issue #4:

“The Standard,” the hotel that I was booked into is a honeymoon hotel. If you go there by yourself or with a peer you're not married to, you may feel uncomfortable. There is no opaque shielding between the shower and bedroom. The gymnasium has pornographic material in it. The handouts in the bedroom encourage nudity and sex. If you're uncomfortable, ask our correspondents to change the hotel you're booked into.

Issue #5:

Our correspondent and I also briefly talked about funding. Sponsor #1 expects a full-color monitor.

Work continues on prototyping a new Sync CCA. The breadboard setup currently includes the following:

A number of things have been discovered over the past few days in developing a new Sync board prototype. One of which has been the characteristics of the polygon mirror driver. In the below data, the Motor Voltage is what's controlled, and there's one tachometer pulse for each facet pass. (RPM = f_Tachometer * 10)

The motor's rotational speed doesn't increase beyond 1.71kHz / 16.3V.

The motor begins to draw excessive amount of current (between 400mA & 1000mA) below 960Hz / 9.1V.

Since the PLL output is between 0-5V, the following circuit was made to scale the PLL's 0-5V output to the 9.1-16.3V range of the polygon mirror, with positive correlation / no signal inversion. (simulated in Falstad's Circuit Simulator) When there was only a non-inverting amplifier going from 0-5V to 0-24V, the PLL output would sometimes cause the polygon motor to be driven below 9.1V, which would trip the current limiter in the power supply and heat up the MOSFET. The purpose of this circuit was to add a minimum voltage to prevent that from happening.

Currently, the system is able to track the signal when it's between about 1.3-1.6kHz, which is not wide enough. Also, the tracking oscillates at about 2.8Hz. Sometimes this oscillation dies down to almost unnoticeable amplitudes. Some discussion has been made about increasing the gain of the current system, or investigating a PID op-amp implementation to address the steady-state error and oscillation.

An Analog Discovery is being used as an oscilloscope and reference signal generator for this project. The blue trace below is the tachometer output after the inverters; the orange trace is the output voltage of the low-pass filter after the PLL.

The Divide-by-N chip was also verified to work as advertised.

Our current serendipitously-working production Sync CCA (Rev. 10 Mar 2015) will be further studied to determine how we're able to get precise locking. Perhaps a dynamically-balanced hybrid between the new and old version could be made to achieve both a wide locking range and tight responsiveness.

Gathered all hardware and datasheets necessary for Sync CCA redesign; got polygon scanner assembly breakout board designed, milled and assembled. Design revisions are being considered at this time.

The breakout board didn't work until I adjusted the potentiometer to midway.

The slit that was made later on was to separate the ground plane of the motor from the ground plane of the tachometer.

I've conducted an investigation as to what the minimum blanking timings can be for any given monitor. I modified the current holomonitor resolution settings to use the blanking intervals of the 640×480 60fps standard resolution. From there, I varied, one by one, the front porch, sync width, and back porch values for both the horizontal and vertical dimensions.

After more than 12 tests, I determined that the timings that are most likely the lower limit for blanking minimization were the following:

For comparison, these are the timings for the 640×480 60fps standard:

and these are the “incumbent” HoloMonitor timings:

I was able to zero-out the horizontal back porch and reduce the vertical offset & sync width to 1. I couldn't get the vertical back porch to be less than 33. It's interesting to note that, in the 640×480 60fps timings, the horizontal front porch, pulse width, and back porch are all multiples of 16.

The newly-discovered minimal blanking timings result in the following HSync/VSync dimensions:

Most importantly, horizontal blanking now occupies 3.1% of a given row, and vertical blanking now occupies 1.4% of the screen. For comparison, the incumbent horizontal blanking occupied 30.7% of a given row (hence the black vertical bars in the monitor output) and the incumbent vertical blanking occupied 4.8% of the screen.

The Phoenix EDID file contents for this are:

EDID BYTES:
0x   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
    ------------------------------------------------
00 | 00 FF FF FF FF FF FF 00 20 C6 35 54 0F 79 BF 07
10 | 2F 19 01 03 68 3C 32 78 08 8F 30 A3 55 49 98 27
20 | 14 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
30 | 01 01 01 01 01 01 40 9C E0 70 D0 AC 23 90 10 60
40 | 11 00 63 F7 10 00 00 1E 00 00 00 FC 00 53 45 52
50 | 54 47 48 42 0A 0A 0A 0A 0A 0A 00 00 00 10 00 0A
60 | 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 00 00 00 10
70 | 00 41 52 42 5F 54 45 53 54 0A 0A 0A 0A 0A 00 2D

I made 6 SOIC16N-DIP breakout boards for prototyping for the upcoming Sync CCA revision. SOIC-N (narrow) is a good layout because the spaced-out leads make soldering easier. It's also a relatively small package. The next Sync CCA will be using SOIC-N chips.

I also made 4 VGA breakout boards with an EEPROM chip to facilitate graphics card testing. This basically is the first section of the Mixer-Amplifier board, without the filters, mixers, and amplifiers that follow afterwards. Red, Green, and Blue channels are taped out to SMA connectors. Green channel has a 75-ohm resistor that can be used to trigger the graphics card's monitor detection routines; but this is irrelevant, as the DVI-VGA adapters we use fulfill this purpose by connecting HOT_PLUG to +5V internally (see top of pg. 17 of the DVI Specifications, and the internal wiring of DVI-VGA connectors.) The breakout board also includes H/V-Sync taps and an EEPROM for EDID data. In theory (hasn't been tried yet), both the computer and an Arduino could be connected to this EEPROM chip at the same time. The two Schottky diodes are meant to prevent the slightly different +5V power supplies of the computer and Arduino from conflicting with each other while powering the EEPROM. As well, the I2C bus is an open-drain system; cross-driving will only result in data corruption and no electrical over-current failures. The I2C bus masters (the computer and Arduino) interact with the EEPROM at different times; the computer on a HOT_PLUG event, and the Arduino with user interaction. Because they are masters (driving commands and sensing responses), the commands of one master won't affect the other master because they don't poll each other (unless it's during a time when both issued a command at the same time).

The boards were single-sided to make soldering easy, as it's very difficult to solder underneath components in milled 2-layer designs. Both boards had 24mil spacing between signal paths and spare copper. Signal paths were 16mil wide. The ECEn shop milled those and had them done a few hours after submitting the gerber files. Sand paper was used to remove loose strands of copper left over from milling:

The above images are unscaled crops from high-resolution scans (click to see full 4800 dpi glory) of the circuit boards using the EPSON scanners in the CAEDM lab. Here are some more high resolution scans of other circuit boards (18GHz DirecTV satellite receivers).

I also polished and folded the top optics plate for the upcoming tricolor monitor.

video? packing

video? library version corruption

i3 = x3 + 3552*y3
i2 = i3
x2 = i2%355200
y2 = i2/355200
x1 = x2/355200*w1
y1 = y2/26*h1

w1/355200 typically « 1, so interpolation is only between two points:

color = (xH-x1)colorxL + (x1-xL)colorxH

h1/26 typically > 1, so take the average across multiple points:

color = avg(color(y1+1/2*h1/26) to color(y1-1/2*h1/26))

We were able to reduce the background noise today of the W1 monitor by tinkering around with the optics alignment and inserting a polarizer betweeen the AOM output and polygon mirror input (location J below). The exact location where the light couples into the waveguides strongly influences the amount of background noise and magnitude of deflected light. These two variables can roughly be controlled by varying the depth of screws C.a & C.b, as shown below. The optics determining precisely where the light enters the AOM (locations A, B, C, F) are the most sensitive to movement and can easily degrade/destroy image quality if bumped.

A - laser source
B - static mirror
C - adjustable mirror
C.a - vertical alignment; 'targets' waveguide channel
C.b - horizontal alignment; 'targets' coupling region
D - lens (purpose?)
E - polarizer
F - LiNbO3 AOM
G - 20cm lens (later mounted before images were created)
H - prism to redirect AOM output
I - lower periscope mirror (covered)
J - location of 2nd polarizer
K - upper periscope mirror (not pictured)
L - polygon mirror
M - galvanometer mirror (not pictured)
N - parabolic mirror (not pictured)

The remaining background noise was attenuated below sensitivity (by decreasing the laser's brightness and camera's ISO), as shown in the below video and image from today.

The parabolic mirror was also adjusted so that the entire width of the parabolic mirror was almost uniformly illuminated, like in the Wed 28 Oct 2015 'demonstration of mirror fitness' picture. This was necessary before evaluating the frequency range. The output's slight tilt to the left (counterclockwise) is most likely from the polygon mirror not being horizontally aligned with the AOM (see Wed 28 Oct 2015 remarks on this), over/under correction of the prism, and the mirror holders of the periscope not being on the same plane (they're slightly rotated along the vertical shaft from each other).

An example of wide, near-uniform illumination as seen from the output looking into the parabolic mirror:

A - the end tapering down to a point is an indication that the output is being limited by physical apertures (mirror/lens width, structural blocking, etc…)
B - the abrupt, straight end is an indication of the end of the addressable region by the current frequency / AOM deflection angle.

A very rough sketch of the deflection range and effective holographic aperture was also surveyed. The direction of the frequencies or visibility may be reversed in the picture below, and the “2/3rds” approximation is purely speculative, but this gives us an idea of the viable frequencies/angles we have to work with.

Charley and I worked on generating different test patterns and setting up OpenFrameworks on his desktop computer. There's a problem with OF v0.8.4, so use v0.8.3 instead.

[need to remember all the things we did]

We installed and carefully aligned AOM sample W1 into a monitor chassis, along with doing some structural work on the monitor it was installed in. The AOM output was usually between 410-490MHz for green light at the angle the modulator was installed, and produced a narrow, vertical bar. I assumed that the vertically-short aperture of the polygon mirror might be enough to spatially filter down the AOM output to that of a dot small enough to create crisp images. I'm probably wrong on this, as the polygon mirror facet is located at the focal point of the telescope lens-mirror system. Anyways, another hurdle we faced in using one of our own AOMs is that the current (as of today) Mixer-Amplifier boards only produced between +25-+22dBm in upconversion mode (between 400-600MHz). Charlie and I tried to add another HELA-10 amplifier (with a 3dB attenuator in place to prevent damage to the 2nd HELA), but for some reason, this only attenuated the 1st HELA's output signal! We verified with a signal generator and spectrum analyzer that the 2nd HELA worked normally (about +9dB amplification) at the same frequency, so we're puzzled for the moment why this happens. Charley wanted to see if W1 would work anyway with only +22dBm of power, so we hooked a good channel of W1 up to the MixAmp CCA output. I loaded the simple logo of Sponsor #1 and was able to find it in the monitor's output with some difficulty. The lens might be the wrong focal lenght, and/or the parabolic mirror needs more adjusting.

Nonetheless, W1 was able to produce an image! This is the first time we have used one of our own fab'd-in-house AOMs to create a HoloMonitor image! And the image is pretty sharp! The letters are dim because we were running off of +22dBm because of the poor performance of the upconversion mode of the MixerAmplifier boards.

Video of W1 output sweeping on the lower periscope mirror:

Video of W1 output sweep filling polygon mirror facet:

Charley & I evaluated the frequency response of the new graphics cards - the GeForce GT740, NVS 315, and Quadro K620. The response of these cards were found to be, in general, more level than the GeForce FX 5800 cards we're currently using. The Quadro K620 appears to have the best response.

We tried installing the GeForce Fx 5800 in the 'supercomputer', but it now BSoD's ever time we boot it… recovery options will be explored in the future, and Charley's desktop will be use in-situ for now.

[log what else we did]

Edit to the legends: ignore the 'DVI 3/4' test, and the black color signifies that all three channels were being controlled the same simultaneously.

Videos of test patterns! (watch in 1080p)

Our Sony HDR-CX900 camcorder was configured to record at 1080i when we recorded video of the holographic stereogram videos. Youtube's video converter for interlaced .MTS files causes a black bar to appear in the holomonitor ouput, rolling slowly downwards and looping back up. I used a program (WinX HD Video Converter Delux) to convert from the camcorder's .MTS format to .mp4, and the Youtube uploads no longer have this black bar artifact with this conversion. I converted with the highest quality settings (same aspect ratio, frame rate, resolution). Interestingly, the “Deinterlace” option brings that black bar back, so I left that option unused.

Also, add ?rel=0 to the end of addresses in embedded videos to remove “related”/“recommended” videos.

I started today modifying the upper plate of the optics sled so that the polygon assembly would be laterally aligned with the laser path below (no side-to-side adjustment). I did this to try to correct the tilt of illumination seen in previous images.

I also went through some of our other available mirrors and found one without distortion, and swapped that in. After moving the mirror forward/backward, side-to-side, and rotating it left/right, I was able to get a pretty uniform bar pattern on the output, as shown below. Unfortunately it doesn't illuminate completely uniformly, which might be correctable with more alignment attempts.

I also tried improving the filters for the zero-order and background noise. The zero-order can be cancelled out easily, but background noise is hard. Here are the filters installed after today:

After the mirror and filter adjustment, I took another look at grayscale correction and made videos that recorded the apparent brightness relative to the input amplitude percentage. I thought this wasn't good enough, so I got one of our power meters and started writing down measurements, but for some reason the power readings fluctuated around. Eventually, at about 11:30pm, I got tired and decided to work more on this tomorrow.

Before today's attempted grayscale analysis, I made a video demonstrating stereography with Sponsor #1's logo, but this still lacks the amplitude correction that Dr. Smalley had mentioned before. I'll work on this tomorrow, but here's today's recording:

Stereography (bad settings on HD camcorder, will have to re-record): <this video was replaced; see the stereography videos above>

Frequency Sweep (with DSLR):

I spent some time aggregating data to the previous study to come up with this graph:

Perhaps the added data (gamma = 2.33,2.67,3.00) is errornous, as there seems to be a distinct discontinuity between the sets.

Nonetheless, it seemed interesting that the central column (value = 0.5) had a nice grayscale gradient. So I tried mapping the correction to this column to come up with the following:

It seems that the correction formula y(x) = 0.5^(3-2x) gave the best correction.

Here's a table of input values vs gamma correction values from today's efforts. These pictures were taken with Dr. Smalley's DSLR with ISO on max (25600) and exposure time set to 1/30th second. The remote control was used, and the images were batch-cropped in Photoshop following this tutorial.

Cameron apparently found a function that does irrational exponents: pow(x,y). This works great, and he also added contrast/brightness options. We still haven't been able to produce good grayscale images yet. I was kinda bummed out that I didn't get to use my Taylor Series algorithm.

Here's the Matlab code I've whipped up so far for the Taylor series approximation of x^y, where x,y are irrational numbers:

taylor_series_x_pow_y.m

function sum=taylor_series_x_pow_y(x,y,N)
% Taylor Series Approximation of irrational ^ irrational
% Andrew Henrie
% Fri 23 Oct 2015

if x == 0 || x == 1 || y == 0 || y == 1
    if y == 0
        sum = 1; % 0^0 is undefined, but we're trying to model Matlab's approach
    else
        if y == 1
            sum = x;
        else
            if x == 1
                sum = 1;
            else
                if x == 0
                    sum = 0;
                end
            end
        end
    end
else
    td = 1;
    tf = 1;
    tp = 1;
    sum = 0;
    i_last = 0;
    x_minus_a = x-1;

    for i = 1:N
        sum = sum + td/tf*tp;

        td = td * (y-i_last);
        tf = tf * (i);
        tp = tp * (x_minus_a);

        i_last = i;
    end
end

gamma_correction_study.m
(Using a 20th-order Taylor Series)

% Gamma Correction Study
% Andrew Henrie
% Fri 23 Oct 2015

clear;
close all;

N = 50; % number of samples
b = 2; % max x,y values
order = 20; % number of taylor series terms

I = 1:N;
X = zeros(N);
Y = zeros(N);
Z_Taylor = zeros(N);
Z_Matlab = zeros(N);
for xi = I
    for yi = I
        x = (xi-1)/(N-1)*b;
        y = (yi-1)/(N-1)*b;
        X(yi,xi) = x;
        Y(yi,xi) = y;
        Z_Taylor(yi,xi) = taylor_series_x_pow_y(x, y, order);
        Z_Matlab(yi,xi) = x^y;
    end
end

figure
surf(X, Y, Z_Taylor);
title(sprintf('Taylor Calculations (order=%i)',order));
xlabel('x');
ylabel('y');

figure
surf(X, Y, Z_Matlab);
title('Matlab Calculations');
xlabel('x');
ylabel('y');

max_error = max(max(Z_Taylor-Z_Matlab))

figure
surf(X, Y, Z_Taylor-Z_Matlab);
title(sprintf('Difference (order=%i, max=%0.1e)',order, max_error));
xlabel('x');
ylabel('y');

The largest error occurs mostly at low values of x and y (lim x→0, y<1):

Maximum error is atteunated with higher-order Taylor series:

It was discovered that a significant amount of background noise in the Modulator originates from the AOM itself. The monitor was adjusted to have the laser run off of 5V instead of 12V so the output wasn't blinding and that we didn't have to use as many attenuators. The shell of the commercial AOM was reinstalled at a slight offset to only pass both sides of the deflected light and the zero-order beam. This helped to attenuate the background noise. Outer leads on the main PLL potentiometer were switched for convenience.

Code for Multiple Modulated Diffraction Patterns was cleaned up and updated so that the average would be taken over the number of active images as opposed to the total number of images, enabled or not. This will allow for maximum image brightness.

With the changes made to attenuate background noise, and decreased laser power, 'black' is now much more black.

What is the formula for gamma correction? Generically, (per StackOverflow) it's

x'(x) = x_max * ((x - x_min) / (x_max - x_min))^gamma + x_min

where

x is the input value (0-255)\\
x' is the output value (0-255)\\
gamma is the correction value (a scalar usually between 1 and 0)\\

in our 8-bit case, this simplifies to

x'(x) = 255 * ( x / 255 )^gamma

or, for our OpenGL float values ranging between [0,1],

x'(x) = x^gamma

The Wikipedia - Gamma Correction article can be helpful in getting an idea of what gamma to use.

Fortunately, the power function '^' is implemented natively inOpenGL (see also the CORDIC algorithms), which means we won't have to make a Taylor-series implementation.

Unfortunately, the power function requires the operands to be integers (both? y only?), so we're going to have to implement a Taylor Series equivalent… so how many orders should we use?