ElectroHolography Laboratory

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Research Log - Erich Nygaard ======

[[leia|Main Leia page]] \\
[[erich|Erich's profile]]

----


===== Summer 2017 =====
14 Aug

{{:erich:s:output_phase_circular.png?direct&400|}}

{{:erich:s:output_phase_bad.png?direct&400|}}

{{:erich:s:particle_detection_crop.png?direct&400|}}

26 Jun

I've been improving the blender script to be able to adequately convert the ridiculous earth model that we have. Here is what the current converted output looks like, previewed in matlab.

{{:erich:s:earth_conversion_progress.png?direct&200|}}
----


===== January 2017 =====
18 Jan

I noticed that the arduino code to control the stage was not working reliably. Sometimes the wave table did not load. I have made it so every command sent to the controller has at least 10ms of delay after it (a smaller delay may be okay, but there does need to be some delay). That helped. I also put 4 second delays after reference moves or autozero commands, which also seems to be helping.

I tested with a wavetable of 2 points - 0 and 1mm, to see how fast it could do a triangle wave of 1mm amplitude. The limit is about 13.5Hz for this amplitude.

With arbitrary waveforms, it seems that the inertia of the motor distorts the shape a while before you reach aliasing effects from the trigger sampling (probably happens at 5kHz).

----
13 Jan

I changed the servo cycle time on the linear stage controller to the minimum time of 100us (it was previously 200us). This should allow it to output positions at 10kHz. I followed the instructions on p175 of the manual. It shouldn't cause problems, but the processor utilization is probably about 85%, which is higher than they recommend (70%).

I plan to investigate using interrupts on the arduino to base timing off of the output of servo cycles from the stage, because the stage only samples at the same frequency as its servo cycles, meaning that if we trigger it externally, we only get half the possible points per second from it.

----

===== 12 November 2016 =====

Here is a page for info on the [[v-528.1ab|linear stage]] we got recently.

----

===== 19 August 2016 =====

I have decided that the images are almost as good as they can get without fixing the green laser. It only is able to use 30 brightness levels right now because it is so much brighter than the other 2 lasers. I plan to try a different driver, and if that doesn't work, I will try a less-powerful diode. I also had the idea that by adjusting the focus on the lens near the green diode, the beam could be more spread out near the particle, resulting in more consistency between different particles as well as less light in general.

----
===== 18 August 2016 =====

I have tried a few things to improve the images even more:

  * Adding a positional offset to every other column to correct the zig-zag effect. This has to be calibrated depending on the time between pixel positions. The nice thing about this is I can get rid of the extra galvo movement delay in the code, and instead add that positional error into the offset. This allows me to draw images more than 2x as fast. There is a side effect to this approach (at least with my current implementation), which is that at the top and bottom of the image there are tooth-looking features. The middle of the images look much better.
  * Doubling each column to fill in the black spaces. This makes the color look more saturated. My previous approach was halving the image size, but that has the unwanted effect of causing the pixel positions to be less accurate, as particle movement and galvo hysteresis are larger with respect to the image.
  * I have concluded that the images look better (smoother) if you just leave the laser on between pixels and don't stop at the pixels.

Before, with light off between pixel positions (offset not fully corrected): \\
{{:erich:t:colorbars_on_pixels_crop.jpg?direct&400|}}

After positional offset for even columns (also light on between pixels): \\
{{:erich:t:colorbars_corrected_offset_crop.jpg?direct&400|}}

After column doubling: \\
{{:erich:t:colorbars_column_doubling_crop.jpg?direct&400|}}

Some other images I've gotten: \\
{{:erich:t:dejarik_crop.jpg?direct&200|}} {{:erich:t:earth_good_color.jpg?direct&200|}} {{:erich:t:img0004_crop.jpg?direct&200|}}

Mark and I tried making the persistent butterfly vector image larger, and we were able to scale it up by a factor of 8. It didn't hold very consistently at that scaling, but 7 works pretty well. We are not yet interpolating between vertices, just jumping, so that is why it falls out.

7x scale: \\
{{:erich:t:butterfly_pov_7x_finger.jpg?direct&300|}}

----

===== 16 August 2016 =====

Here are some of the best images I have gotten since applying the color correction curves based on the lasers' brightness data: \\
{{:erich:u:bbb_cc_between_px.jpg?direct&200|}} {{:erich:u:bbb_cc2_cropped.jpg?direct&200|}} \\
{{:erich:u:earth1_crop.jpg?direct&200|}} {{:erich:u:earth2_crop.jpg?direct&200|}} {{:erich:u:leia_color_adjusted_levels.jpg?direct&200|}} *

* I adjusted the levels to brighten the image in GIMP for the leia picture, because it was really dark. A higher camera ISO would do basically the same thing though.

Brian Wilcox from University Communications came in and took some video. One of the things we did was persistence of vision with a small vector image. The next day I tried speeding it up a bit and I got this video with our camera: \\
{{:erich:u:finger.mp4|}}

Yes, it's upside down. I plan to try making it big enough that you can see it without magnification. Right now it is maybe a millimeter tall. An interesting thing I noticed is that it can hold the particle for a good while while moving over small distances continuously like this. I'd like to revisit this as a method for holding a particle for longer, or picking up more reliably.

I'm now focusing on improving images for the paper.

Here are some possible demonstrations of the color and grayscale capability: \\
{{:erich:u:rgb_circle.png?direct&200|}} {{:erich:u:smpte_color_bars.png?direct&200|}} {{:erich:u:zone_plate.png?direct&200|}}

{{:erich:u:colorwheel_crop.jpg?direct&200|}} {{:erich:u:colorbars_crop.jpg?direct&200|}} {{:erich:u:zoneplate_cropped.jpg?direct&200|}}

----

===== 3 August 2016 =====

I wrote a program to automate taking images. It connects to the Arduino and camera, and picks up until it gets a particle, then takes a picture. It is working pretty well. I also am making it log trapping data.

----

===== 2 August 2016 =====

I collected data on the 3 lasers separately and compared to the data taken with all 3 at once. It is clear that the spilling from green into the other channels is too much to ignore. 

I wrote a MATLAB script to take the csv file from the data collection program and generate a brightness to PWM lookup table for use in the arduino code. Here are the results from today's data set (lasers diffused on paper, no particle):

{{:erich:v:correction_curve_1.png?direct&1000|}}

I implemented this color correction function into the arduino code and tried getting some images with it. I'm not sure whether the color correction is good yet, because there is so much variability between images with different particles. Some will be mostly red, others green and blue, for instance. I can tell that the shading is better, however. I believe the inconsistency of the color is due to particles being trapped in different locations. This could potentially be mitigated if the rgb lasers were aligned to be more collinear. 

Since the green laser seems to be highly nonlinear, due to the driver and possibly due to operating near threshold, I am going to try a different driver based on Scott's pulsed driver design. [[http://www.falstad.com/circuit/circuitjs.html?cct=$+1+0.000005+0.023262365791729273+50+5+43%0A162+704+240+704+304+1+2.1024259+1+0+0%0Aw+560+160+704+160+0%0Aw+704+240+704+160+0%0AR+384+160+352+160+0+0+40+5+0+0+0.5%0Af+624+368+704+368+0+1.5+0.02%0Aw+704+304+704+352+0%0Aw+704+384+704+432+0%0Ag+704+432+704+464+0%0Af+464+352+528+352+0+1.5+0.02%0Ar+528+240+528+336+0+100%0Aw+560+160+528+160+0%0Aw+528+240+528+160+0%0Aw+528+160+384+160+0%0A174+544+384+544+448+0+10000+0.7277+Resistance%0Aw+544+384+544+368+0%0Aw+544+368+624+368+0%0Aw+544+368+528+368+0%0Aw+560+416+624+416+0%0Aw+624+416+624+432+0%0Aw+624+432+704+432+0%0Aw+464+352+368+352+0%0Ax+732+280+766+283+0+16+laser%0AR+320+304+368+304+0+2+24999.999999999996+5+0+0+0.5%0Aw+368+352+320+352+0%0Aw+320+352+320+304+0%0Ax+196+302+307+305+0+16+TTL+modulation%0Ax+502+474+605+477+0+12+current+adjustment%0A|mosfet current driver]]

----

===== 1 August 2016 =====

Mark Lindsey has been helping out with improving the vector drawing. He has written a new vector path generating program, written in C++ with OpenCV. It finds edges on any source image and outputs a continuous sequence of vertices with color information based on the source image. It can connect discontinuous lines with black vertices (lasers off) so we can now draw much more interesting vector images. Here are our first 3 samples (that turned out):

BYU logo: \\
{{:erich:v:vector-byu.jpg?direct&300|}}

MIR space station: \\
{{:erich:v:vector-mir.jpg?direct&300|}}

Wireframe plane: \\
{{:erich:v:vector-plane.jpg?direct&300|}}

For the last 3 weeks or so, I have been focusing on writing a program to collect brightness data for color correction. It is written in C++, controls the Arduino through serial, and gathers image data from the Canon 6D using gphoto2 for Linux. It can detect particles (using OpenCV) and automates the process of gathering this data. I have so far gotten one set of complete data, though it has a problem with the green channel. The particle has to be held for 5-6 minutes to get all the data, due to the time it takes for each picture. Here is the first data set: \\
{{:erich:v:brightness-graph1.png?direct&300|}}

I am going to put more info on color correction on this page: [[pwm_intensity_curve_linearization]].

----

===== 13-17 June 2016 =====

I have had better success trapping with a metal spoon, instead of a plastic one. See [[trapping]].

I spent some time working on a circuit that can be added to any laser driver to add faster modulation ability. I got it working, but I haven't tested to confirm that it improves the switching performance.\\
{{:erich:w:img_20160614_181703073.jpg?direct&200|}}

In order to try to avoid having the galvos make the high pitched whistle, I took measures to avoid undesired control signals being sent during the reset of the Arduino (including during program uploads). I was using an inverter (LS7404), and I noticed that IO pin voltages were sometimes in the undefined range. I switched it out for an RS422 driver (AM2631) which is compatible with RS485 signals (in this configuration) and is actually designed for what I'm doing. The TTL voltages are now better. In addition, the 2631 has an enable pin, which I wired to a physical switch. This way I can manually disable the outputs going to the galvo (put them in high-Z) before I reset the arduino or upload a new program. Before, I noticed that a common time for the galvos to start whistling was right after an upload. This seems to be helping quite a bit, but I did notice that sometimes the galvos jump when I flip the switch to enable the galvos; this is probably because of switch bounce.\\
{{:erich:w:img_20160617_182636452.jpg?direct&200|}}

I also have an interrupt switch that allows me to stop the program and return the galvos to a home position. The program starts at this position as well, so it is possible to avoid having the galvos make large jumps at the beginning of the program. 

I found out the reason for the vertical offset on every other line of the raster. It is because the galvos take some time to get to the position after the new position is sent. I found 1000ms for a 32px step to be reasonable. You can give them more time and they will get closer, but they seem to slow down as they approach the target position. The remaining offset could be corrected for in 3 ways: offsetting the commanded positions, turning on lasers in between pixels to basically blur the zigzag line to a flat line, or returning to the same side to begin each raster line (slows down the drawing speed).

I was experimenting with turning off the lasers in between pixels also. It seems to produce sharper images.

{{:erich:w:img_9958.jpg?direct&100|}} {{:erich:w:img_9964.jpg?direct&100|}} 

{{:erich:w:img_9968.jpg?direct&100|}} {{:erich:w:img_9971.jpg?direct&100|}}

Here are some side by side comparisons of different delay times for galvo movement. The number shown is the number of microseconds of delay after galvo positions are sent before the light is turned on. Light is off between pixels here:\\
{{:erich:w:galvo_movement_speed_tests.jpg?direct&300|}}


----

===== 10 June 2016 =====

I decided to try using the macro lens to get sharper pictures. I have it basically looking straight toward the galvos but off to the side so as not to look into the laser. The images are being drawn off to the side and down a bit from the center position. The focus is rather shallow, so it's hard to get the whole image in focus.
 
{{:erich:erich:w:red-drawing-area.jpg?direct&200|}} {{:erich:erich:w:green-drawing-area.jpg?direct&200|}} {{:erich:erich:w:blue-drawing-area.jpg?direct&200|}}

{{:erich:erich:w:dejarik-macro-interlace.jpg?direct&300|}} {{:erich:erich:w:dejarik-macro.jpg?direct&300|}}

{{:erich:erich:w:img_0229.jpg?direct&300|}}

----

===== 7 June 2016 =====

I've been looking into a few methods for modulating the green laser faster.
  - Use a green diode laser instead of DPSS, and run it with a driver capable of modulation at the current required.
  - Use a green diode laser with any driver, but with a modification to sink current away from the diode in a switchable way. This would have the advantage of MHz modulation rates, as opposed to most drivers that can do ~30kHz.
  - Use any green laser (DPSS or diode) and modulate it optically with, for example, an AOM.

For (1), I found a power supply with TTL modulation that was for a high power DPSS laser. It was putting out about 3A to the laser diode. I was able to adjust its current down to about what a green diode would need for the power I want. This looks like a good (and safe) option for modulating up to the 30kHz range.

For (2), I have designed a circuit that I think should work. I have not yet tested it.

For (3), I tried a bulk wave AOM in front of both a green DPSS and a red laser. The best efficiency I saw was about 33% in one deflected order. So this could possibly be feasible if I started with 500mW, but I think I'd prefer an electrical solution for now. There are probably better, more efficient options for optical modulation that could be investigated.

The 3A DPSS laser driver:\\
{{:erich:x:dpss_driver_adjust_pot.jpg?300|}} \\
There is an arrow indicating which pot adjusts the output current when the laser is on. I measured the output current with 3 0.7V diodes in series (to simulate an IR laser diode) so we can set it back to where it was originally.

ON: 3.69A \\
OFF: 200-210mA

----

===== 3 June 2016 =====

I tried getting some images that don't have much green, since that isn't working the best right now.

Square-root correction curve for green (done on arduino) to improve gradient: \\
{{:erich:x:gradients_green_square_root_correction.jpg?200|}}

Leia with a precorrected image (left) (bumped up the green with gamma curve). Square-root correction (middle), no square-root correction (right): \\
{{:erich:x:leia_blue_corrected.png?200|}} {{:erich:x:first_leia_rgb_-_square_root_precorrected.jpg?200|}} {{:erich:x:leia_rgb_-_no_square_root_precorrected.jpg?200|}}

With the non-precorrected image. Source image, then drawn image with square-root correction: \\
{{:erich:y:leia_blue.png?200|}} {{:erich:x:leia_rgb_-_square_root_and_not_precorrected.jpg?200|}} 

This is the same configuration as the previous image, but the particle is probably trapped in a less-ideal position. Toward the right side of the image, the particle shifts into a different spot. This demonstrates that the position of the particle is affecting how well the colors are scattering off of it. \\
{{:erich:x:leia_-_particle_shifts.jpg?200|}}

Solid block of green, to see if certain spots are just dimmer than others, which they are. This could possibly be corrected with achromatic lenses to expand and focus all 4 lasers, or by choosing a drawing area that has even coloring in all 3 colors. \\
{{:erich:x:solid_green_test_bottom_left_corner_.jpg?200|}}
----

===== 2 June 2016 =====

  * I tested the response time of the RGB lasers. The red and blue are less than 1 ms, but green is about 100 to 150 ms. This is a problem because it means that a 200x200 raster takes about 3 hours.
  * I determined that the RGB lasers seem to like lower frequency pwm - 500Hz works better than 4kHz and 33kHz. Green is affected the most but the other 2 are affected slightly.
  * Red and blue channels actually look pretty good if you just limit them to about 0-50. Green's curve is not steep enough at the low intensities so I'm going to try a square root correction.
  * The 220VAC power supply did not completely fix the galvo sound problem, it happened again today, both times it was when the arduino reset for an upload.

These images were drawn on an OD filter, not with a particle. \\
Gradients at 500Hz, 4KHz and 33KHz: \\
{{:x:500hz_gradients.jpg?200|}}{{:x:4khz_gradients.jpg?200|}}{{:x:33khz_gradients.jpg?200|}}

Demonstration of response time of red, green, and blue lasers. They are turned off at the top, moved slowly, then turned on while moving quickly to the bottom. Based on the drawing speed here, the green response is about 120ms. Note that turning off is always instantaneous. Left to right: 4KHz, 33KHz, 500Hz. \\
{{:erich:erich:x:rgb_response_time_test_4k_33k_500.jpg?300|}}

----

===== 27 May 2016 =====

  * Set up Canon EOS Utility on a computer to help focus the camera more precisely.
  * Found out that vertical lines are wavy, for some reason. Some possible causes are: a problem with the y axis galvo, using the 220VAC power converter instead of 120VAC, construction vibration, drawing speed. \\
{{:x:horizontal_line_example.jpg?300|}}{{:x:vertical_line_example.jpg?100|}}


  * I learned that laser diodes have an astigmatic focus. It might help to correct for this for trapping.
  * I've been thinking more about the response time of the lasers. It is probably limited by the drive circuits on the lasers. This website has some info on modulation techniques: [[http://www.repairfaq.org/sam/laserdio.htm#diodelp|Sam's Laser FAQ]].

----

===== 26 May 2016 =====

  * Jacob made a 220VAC plug so I could use the 4A power supply that came with the galvos, instead of the 1A power supply I have been using until now. I am hoping this will cause the high pitched noise to go away. I was able to run them for at least 30 min at a time with no problem (just the regular hissing sound), but I'm not yet sure if the problem has been solved.
  * I replaced the RGB lasers with a new set, with Jacob's help. The new one has blue last, which means it only goes through 1 filter instead of 3. It is also brighter and the PWM ramps the brightness smoothly for all 3 lasers. 
  * We realigned the lasers (RGBV), and then tried getting some pictures. It is trapping better than it has been the last few days. When aligning violet to the center laser (green right now), if the green is centered in the focusing lens, it may be necessary to adjust the position of violet on the violet dichro, not just the angle of the dichro, to avoid the violet getting off-center. (I now have the violet on a kinematic mount for that reason.)

Current setup:\\
{{:erich:y:img_20160526_160413852.jpg?400|}}

Before changing the RGB:\\
{{:erich:y:img_9939.jpg?200|}}
{{:erich:y:img_9940.jpg?200|}}

After changing RGB/aligning:\\
{{:erich:y:20160526152325_img_9955.jpg?200|}}
{{:erich:y:20160526153033_img_9959.jpg?200|}}
{{:erich:y:20160526153339_img_9961.jpg?200|}}

No color, just a particle. You can see that the camera is not picking up any violet, at least where the image is drawn:\\
{{:erich:y:20160526153826_img_9964.jpg?200|}}

Green only (same raster image as before):\\
{{:erich:y:20160526155003_img_9968.jpg?200|}}

----

===== 25 May 2016 =====

I took some more pictures, using a box around the camera and trapping area. I was again having a lot of difficulty trapping well. I tried a few things including adjusting the violet laser to go through the last lens more centered. This helped a bit, but threw off the rgb alignment on the particle. Hence, some of these images don't show a lot of green and/or blue.

{{:erich:y:img_9895.jpg?200|}}
{{:erich:y:img_9896.jpg?200|}}

Full raster with red and blue:\\
{{:erich:y:img_9899.jpg?200|}}

Source image for raster:\\
{{:erich:y:dejarik_small.png?200|}}

----

===== 24 May 2016 =====

Yesterday I ran into a different memory-related issue with the arduino. It turns out the compiler doesn't properly handle sketches over 64KB, so although my program (104KB) compiled and uploaded without error, it would not run. I found a solution online, which involves forcing the global variables to go in an area of flash after the program (by default the PROGMEM global variables go first in flash, then the program), and then using a "far address" instead of a "near address" to retrieve them. ([[http://forum.arduino.cc/index.php?topic=146211.15|solution found here]])

After resolving that issue, I got some images, finally!

Gradient test:\\
{{:erich:y:img_9847.jpg?200|}}

Circle (pointed at camera at one point), you can see the pixelation (lines are multiples of 256 pixels long)
{{:erich:y:img_9848.jpg?200|}}

Partial raster - this picture shows the definition of the drawn image although it is overexposed:
{{:erich:y:img_9864.jpg?200|}}

It wasn't holding very well for some reason after I added the paper to mask out the background light. One issue you can see in these images is that the green laser doesn't ramp up its brightness very smoothly.

----

===== 23 May 2016 =====

I found out that you can't have an array of more than 32767 elements on our platform because it is indexed by an int type, which means you can have a square of up to 181x181 pixels for rastering. I could work around this limitation, but there's not much more I could do before filling up the 256KB of flash anyway. So we can continue to use the arduino for simple demos like what we have been doing, but at some point we will need to change it to a beefier microcontroller or a PC. That would also have the advantage of being limited only by the speed of the galvos.

----

===== 20 May 2016 =====

Yesterday and today I started improving the arduino program for better automation of image capturing. It can now take pictures using bulb mode on the DSLR, making it so you don't need to worry about setting the shutter speed, just the aperture, ISO, and focus. I also added a function that will get a particle trapped, either automatically or allowing you to manually feed one. It detects a particle relying on the python script and a webcam, which we wrote last year.

I did some testing to find out what the new galvos can handle as far as speed. Here are the results so far:
  * they can do at least 25000 pixels per second - moving 1 pixel at a time, with 40us delays between pixels. This is the current overhead of my code, so the galvos may actually be faster than that.
  * The highest pixel step size with a 40us delay is 52 pixels, meaning it can move 52 pixels in 40us. If you try to make it go farther in 40us intervals, it will not work properly

I found a very interesting open source project today: [[https://marcan.st/projects/openlase/|OpenLase]]. It is software for controlling laser scanners, which are driven by soundcards. Especially interesting to me is the ability to display video in realtime (converting on the fly to vector images using edge detection). It appears to be all vector graphics (i.e. not raster).

----

===== 19 May 2016 =====

This week I started putting everything together, combining one of the optical configurations I tried last week with the galvos and rgb. I was having a hard time getting it to trap well, but it is finally trapping well again since last night. The high power violet laser on the TEC died after running at the highest current I was allowing for about 5 minutes. I replaced it with a 200mW laser Dr. Smalley gave me a while ago, which is of a different style.

I mounted the focusing lens on a rotational mount so it can be twisted more easily, and the angle can be easily recorded:\\
{{:erich:z:img_20160519_101242720.jpg?200|}}

I got a nice video where I was tapping the galvo mirror with my finger while a particle was held. The particle was able to move over the whole range of the mirror's motion and with sudden jerks.

Here is a new page where I will put things I know about trapping, and things I'm not sure about: [[trapping|trapping]].

----
===== 12 May 2016 =====

More hold testing:
  * 72mm at larger angle than last time (bad)
  * 100mm straight (focusing at 230mm)
  * 100mm at a small angle (focusing at 230mm)
The last 2 didn't work as well as the 125mm, maybe because the NA is much lower.

  * 100mm placed farther from laser to produce focus 115mm from the lens - works much better (2 different tilt angles tested)

I have noticed that increased power makes a big difference in the hold time, possibly because of the increased ability to burn particles off the sample. Lower powers often are incapable of getting anything off a solidified sample (as in all my recent tests), but can still pick up quite well if you use a thin layer of loose black liquor dust (even a sprinkling of it will work fine). It may well be worth investigating the possibility of picking up with high power, then dropping down to very low power once particles are trapped.

I set up a microscope webcam to look at the particles being trapped. With secure mounting, it should work well for detecting whether a particle is there. To measure the size of the particles I will need more magnification.\\
{{:erich:z:img_20160512_180753303.jpg?200|}}

----

===== 11 May 2016 =====

I did further focal point and hold testing on a few configurations:
  * 125mm tilted 3 deg., beam slightly off-center in lens
  * 125mm tilted 3 deg., beam centered in lens
  * 125mm at 0, 1.6, and 4.9 degrees
  * 72mm at 4.1 degrees

The best tilt for the 125mm lens seems to be 1.6, or maybe 3 degrees. Small changes in the tilt can change the pattern significantly.

next:
  * 50mm 
  * spherical aberration (filling small portion of lens)
  * effect of larger beam diameters through lens
  * 100mm lens, maybe

----

===== 10 May 2016 =====

I tried another lens setup:
  * no lens on laser module
  * laser placed 1 focal distance from 1st 330mm lens to collimate
  * iris in front of laser to limit the beam diameter (how much of the lens is filled up)
  * 2nd 330mm lens focuses down
  * two less lenses than the last test - less chance of alignment problems
Results:
Focal point looks like a grid of dots, which simply shrink as you approach the focus, that is, there are no emerging or disappearing dots as with the big intimidator. I don't know why that is, but the grid may be a result of the beam going through the two lenses off-center, but on a different axis for each. This pattern creates long tube-like cavities in the beam, which makes sense with the trapping results. It can trap fairly well, but particles are likely to slip upstream (relatively long distances) in the beam and fall out.

After reviewing the big intimidator focal point images, I actually don't think that the grid points are moving or disappearing in that one either. The difference is that there is a circular ring pattern superimposed on the grid.

I also tried a 125mm biconvex lens. First I had the light diverging from the laser (with a lens) and then focused by the 2nd lens. This produced a grid pattern similar to the grid of dots from the last setup. It didn't hold extremely well. I then tried focusing the light with the laser's lens (focused close to the laser) and letting it expand to fill most of the 125mm lens. This produced a ring pattern and trapped better.

Made a new violet filter mount to screw onto 58mm diameter DSLR lenses.\\
{{:erich:z:img_20160510_135108830.jpg?200|}}

----

===== 5-6 May 2016 =====

I have been looking for a good optical configuration for trapping. Due to the size of the galvo mirrors and the spacing between them, the minimum focal distance for a focusing lens placed right before the galvos is about 115mm (for the particle to be held 1-2cm from the edge of the last mirror). The first galvo mirror (x) is about 30mm, yielding a maximum possible NA of 0.375. In practice we may not be able to use the full width of that mirror, so a NA between 0.31 and 0.37 is reasonable. This is comparable to the NA of the late big intimidator, which had a NA of about 0.3.

I have a few lenses I'm going to try using. By varying the focus of the laser's first lens and the distance between the first focal point and the 2nd lens, I can control the NA to be close to a desired value for various lenses. 

So far I have tried using a pair of 330mm, 120mm diameter lenses, collimating the light with the first one and focusing with the 2nd. This produced a terrible focal point, likely because the large lenses are more difficult to align precisely. It was not a problem of too little power, since there was over 500mW at the focal point.

{{:erich:img_20160506_145306072.jpg?200|}} {{:erich:img_20160506_150921151.jpg?200|}}

I paired the disassembled microscope webcam with the 60x objective for focal point viewing. I need to adjust their positions a bit, but it looks like it will work well.

----

===== 4 May 2016 =====

  * removed entry side wall from galvo box (actually all walls) and remounted galvos
  * tried filling the big lens more, it held a little better. Tomorrow I will try filling it completely by moving the violet laser closer to the 2nd mirror (2nd mirror is already filled)
  * re-built focal point viewing mount so it is much more convenient to use

----

===== 3 May 2016 =====

  * checked violet reflectivity thru galvo mirrors - it is good, only about 20% loss (similar to other wavelengths)
  * Finished mounting violet laser. TEC is superglued to heatsink, laser is taped to the TEC. This is so I can turn it 90 degrees easily and see if that holds better.
  * Tried a few lens setups to see if I could hold particles. 125mm focuses about 1cm past the edge of the galvo box (that's if the focusing lens is placed inside the entry hole). A plano-convex 125mm lens worked fairly well holding, but only at high power. I also tried one of the very big longer lenses, and that focused maybe 6-8 in past the box. It held for only a couple seconds but wasn't well aligned. I will try removing the wall of the box on the entry side to allow a larger beam diameter and have the lens closer to the mirror.
  * Tried holding with an 808nm 4W laser I found. It didn't hold at all. The focal point looks like a line (is it a diode array?)
  {{ :erich:img_20160503_175412283.jpg?200 |}}

----
===== 2 May 2016 =====
{{ :erich:img_20160502_140843717.jpg?100|}} 
  * built current regulator to drive TEC at 1.5A
  * Scott made a heatsink to mount the laser on the TEC
  * put Al on galvo mirrors (Jacob)
  * worked on focal point lens mount

\\
\\
{{ :erich:z:img_20160510_115521594.jpg?200|}}
TEC is working well, even with the laser running at 580mA. The only thing that may be a problem is the voltage regulator for the TEC runs very hot. I have a slab of aluminum screwed onto it but that gets hot too. The laser's current regulator needs a higher voltage than the TEC's regulator, so the extra voltage gets converted into heat.

The aluminum mirrors are much better. Blue goes from 15mW to 12mW, and the other lasers get attenuated only a little bit also. I still need to check the violet.

----

===== 29 April 2016 =====

  * mounted the new galvos on the optics table
  * tested TEC cooling for violet laser - it works, but will need a heatsink with a flat side for the laser to go in
  * tested galvo control code with position sweep to verify that is working (positions are not scrambled)
  * started setting up optics for new galvos - blue is attenuated to about 1/50 power through the two gold mirrors. They will need to be coated in something different.

----

===== 28 April 2016 =====

I made an animated gif for the pictures of the big intimidator's focal point. I also cleared the big intimidator off the optics table to make more space.

I wired up a constant current driver that will supply a maximum of 580mA (given enough voltage), similar to the one I made for my 100mW violet diode. I also pressed and soldered leads onto a new 1W violet diode and tested it with this driver. It is putting out easily over 600mW of power - I didn't test the output power at max current because I don't think the light meter can go that high. I still need to hot glue the connections on the back and put it with a fan or TEC.

I re-measured the output from the 100mW violet diode, now that I know how to set a custom wavelength on the meter. It was getting a max of 49mW out of the galvos and 72mW right after the diode/1st lens.

----

===== 27 April 2016 =====
I spent some time figuring out what was wrong with the SPI driver for the new galvos. It turns out the problem was that the CLK and SYNC pulses affect the data loading and output on falling edges, not rising edges as we thought. After switching the code accordingly, I was able to send arbitrary position commands to the galvos. This could be due to a few possible things: 1) the + and - wires from the cable are backwards from what they say they are (and possibly the X/Y signals are backwards also, meaning we are really getting the opposite position from what we think we are), 2) the RS-485 receiver chip is wired backwards (really equivalent to 1), 3) the DAC's signal interface doesn't match what the datasheet says.

I noticed that when going from (65535, 65535) to (0,0), the galvos reset themselves (to the center position, I think). It seems to only do this reset for this particular position change. Either this is a feature of the hardware, or the current draw for this movement is exceeding the power supply's capacity and the boards are losing power. I need to test it with a 4A power supply.

As I am planning to start using a higher power violet laser, I also measured the output power from the 100mW violet laser I was using to hold particles with the first galvo system. The output from the diode/lens was about 71mW, and after all the optics, after the galvos it was 48.4mW. That is a lot lower than my estimate of 100mW. I actually think this number is low, because the power meter only goes down to 445nm for wavelength. It always reads a lower power when you are set for the wrong wavelength. This diode should be putting out about 100mW at the current I am driving it at, so the output power at the end may be closer to 60mW.

----

===== 26 April 2016 =====
I made a first attempt at controlling the new galvos with the SPI implementation that Drew helped me out with. The galvos moved, but in somewhat unpredictable and inconsistent ways.

I used the arduino that used to be controlling the Big Intimidator, so before taking it, I wanted to get some images of the focal point from that system, just in case. I was somewhat surprised by the results. See here: [[Big intimidator focal point]].

I took photos of the old galvo system, before I started unplugging things:\\
{{:erich:img_20160426_094407129.jpg?200|}}{{:erich:img_20160426_094330673_top.jpg?200|}}{{:erich:img_20160426_094350098_top.jpg?200|}}

----

===== Focal point intensity profile imaging =====
I read a paper where the researchers created an image of the intensity variation near the focal point of a laser. They used a microscope objective and a CCD near the focal point, and moved it in small increments (microns), then combined the images to create a horizontal cross-section. I have been experimenting with this method, and was able to see some dark circular rings near the focal point with the verdi. So far I have just used the microscope lens to magnify the focal point and project it onto a piece of paper about a foot away, but I plan to add a CCD to get high res pictures. This could be useful in improving our trap and understanding why certain optics hold better.
{{ :erich:focal_point_mag_2.jpg?200|}}{{ :erich:focal_point_mag.jpg?200|}}
----

===== Current regulator for powering laser diodes: (3/9/2016) =====
Today I put together a circuit to drive a laser diode with a constant current. This is safer than just powering the diode from a power supply as it is easy to turn up the current too high. Most of our lasers have drivers with them that should regulate the current, but this could come in handy if you have a diode without a driver or if you just want to know exactly how the driver is going to behave.

Here is the schematic (found at [[https://sites.google.com/site/dtrlpf/home/flexdrives/rog8811]]):
{{::en_driver.png|}}

You can leave out the pot and diode if you want. The important thing to know is that the resistance value determines the output current. Iout = 1.25V / R

Also, the schematic says to use an LM317, but I usually use low-dropout versions of that part, the LM1117 (up to 800mA) or LM1085 (up to 3A). The chips can run on a supply of up to 15 V. There is a minimum voltage required to reach the regulated current level, and the threshold is dependent on the voltage dropped by the load.

{{:erich:current_regulator.jpg?100 |}}
Here is the one I made to drive a 405nm diode at about 113mA. This one works between 9.2V and 15V, but less voltage means less heat.
----

===== Particle size measurement: =====

{{:erich:size_measure_2.jpg?200 |}}I set up a blue laser directed from the side toward the focal region of the green laser used to hold particles, and expanded it using a microscope lens. It is positioned so that the microscope lens' focal point is just to the right of the green laser's focal point. I was unable to get any particles trapped on this occasion, so I couldn't confirm whether the particles can be resolved with this method.
----
This was my initial trial at home. I was able to resolve cinnamon on a paper clip and a needle. It remains to be seen whether this method is feasible for observing the sizes of particles we are holding in the beam.

{{:tmp_18959-img_20160220_192800210-321662418.jpg?200|}}

{{:tmp_18959-img_20160220_1927296911102908881.jpg?200|}}

{{:tmp_18959-img_20160220_1930141101822289430.jpg?200|}}

{{:tmp_18959-img_20160225_1202206381836375641.jpg?200|}}
ElectroHolography Laboratory

User Tools

Site Tools

Page Tools
