The following two pictures were taken from the same angle with green (left) and red (right) incident laser at an angle of 15deg from the incident beam (reflected to about -5deg). Some scattering centers are collocated. The green laser power is about 5 times as high as the red laser power, but this factor does not seem to calibrate the image well (the green image becomes too dark dividing all pixel values by 5). So there seems to be a significant difference in the divergence of the two lasers. We will have to use a photodiode to get the calibration factor. These images were taken after cleaning the mirror. Before cleaning, there was way too much scattering and the images were mostly saturated.
Please see prosidures for pumping down and venting with air for the test vacuum chamber here https://dcc.ligo.org/T1600304
We played around with Matlab today. The first step was to convert light wavelengths into RGB colors. In this way we can combine images taken at different colors. The picture shows the purple and red images (stored in gray scale) in heat colormap. Then the sum of these two images is calculated in their natural RGB colors.
Steve Maloney, a visiting highschool teacher, and I have started to set up a new scattering experiment in the Richter lab. The idea is to take images of large-angle scattered light using different lasers. We have one 633nm laser, and 532nm and 405nm laser pointers. The goal is to uniformly illuminate the same disk of about 1cm diameter on a silver-coated mirror with all three colors. We use a silver-coated mirror to make sure that the light is reflected from the same layer so that all colors are scattered from the same abberations.
The image shows one of the laser pointers and the HeNe laser. The first step is to widen the beam with a f=5cm broadband, AR coated lens (Newport PAC15AR.15). The diverging beam is then aligned through an iris to give it the right size on the mirror. In this way, illumination is almost uniform on the mirror surface.
The mirror is mounted over the rotation axis of a unipolar stepper motor. For the moment we only took images from fixed direction (initially with a commercial digital camera, later with a monochromatic Sony XT-ST50 CCD camera. The problem with the commercial camera was that you cannot completely control what the camera is doing. Also it would have been very difficult to calibrate the image once you start comparing scattering with different colors. A f=7.5cm lens is used to image the illuminated disk on the CCD chip to make maximal use of its resolution. The CCD signal is read out on a Windows machine with an EasyCap video capture device connected to a USB port. Standard software can then be used to take images or record videos. For some reason the capture device reduces the image size to 640x480 pixels (a little less than the size of the CCD chip).
Eventually the camera and lens will be mounted on a metal arm whose orientation is controlled by the stepper motor. The stepper motor was part of the Silicon Motor Reference Design (Silicon Laboratories). It comes with all kinds of cables and a motor control board. Software is provided to upload compiled C code to the board, but for our purposes it is easiest to use primitive communication methods between the PC and the board. We are working with HyperTerminal that used to be part of Windows installations, but now it has to be downloaded from the web. This program can send simple commands through TCP/IP and COM ports. These commands allow us to position the motor and define its rotation speed. Since our PC does not have a serial port, we purchased a Belkin USB Serial Adapter. You will have to search the web to find suitable drivers for Windows 7 x64. Luckily, Magic Control Technology has similar products and the driver for their U232-P9 USB/serial adapter also works for the Belkin product.
So our goal for the remaining weeks is to take many images from various angles and to set up the experiment in a way that we can VNC into our lab PC and control everything from the Red Door Cafe.
M. D. Ediger, in PNAS (2014), pp. 11232–11233.
A. J. Leggett and D. C. Vural, arXiv cond-mat.dis-nn, arXiv:1310.3387 (2013).
L. Berthier and M. D. Ediger, arXiv cond-mat.mtrl-sci, 40 (2015). Phys. Today.
G. Parisi and F. Sciortino, Nature Materials 12, 94 (2013).
S. Singh, M. D. Ediger, and J. J. de Pablo, Nature Materials 12, 139 (2013).
Nothing has happened since Steve, the visiting highschool teacher, has left. Meanwhile, some parts of the multi-color BRDF setup were delivered. I assembled everything today and realigned the lasers. Everything is ready now for a three-color BRDF measurement (the previous Richter record was 2 colors). I will claim back my video capture device as soon as possible from my neighbors and then take new images.
Today we improved alignment of the lens-camera arm. We discovered earlier that this alignment affects the amount of "snowfall" on the scattering images. Looking at the latest 405nm video (see attachment), one can still see snowfall, but it is considerably weaker now and the true scatter image is clearly visible. We took a set of scatter images at certain scattering angles and produced BSDF curves. The shape of these curves has partially to do with the snowfall contribution, but one also has to keep in mind that the mirror quality is much worse than what has been used in the Fullerton measurement. We still need to calibrate these curves. The calibration factor is different for the two images so that you cannot even compare them at the moment except for their shape.
Today we also got the new broadband lens for the camera arm. First measurements show that image quality is better. Playing a bit around with distances between object mirror, lens and image plane, we also found that image quality becomes better when the lens and camera get closer to the mirror (which is only an issue for the 405nm measurement since 633nm and 532nm look very good anyway). So we are thinking to change the camera arm setup to make it much shorter.
We have the new 405nm laser pointer. The image to the left shows the scattered light from the red laser, the image to the right scattered light from the purple laser. Both images were taken 30deg with respect to the normal of the mirror surface. Also, we got a new gallon of Methanol. After cleaning the mirror multiple times, the scattered light became significantly weaker. So the purple images look very different from red and green. It could be that the lens that we use to image the mirror surface is the problem since it is specified for the wavelength range 1000nm-1550nm. Could it also be the CCD camera? Anyway, to be sure I will order another broadband lens.
Here a little purple video. It starts with scattering angle around 15deg and stops at about 80deg.
There are some clear point defects visible especially at small angles.
I will not start to think about some other interesting details of this video before I got the new lens.
Ed: The AVI did not run on Mac. I posted it on youtube. Koji
My bad, a cable was disconnected.
Finally, I tried to excite the disks, but I couldn't get any motion of the optical lever beams. To be investigated, there might simply be some cables disconnected.
We were confused a bit about how the camera image changes when you move the arm that holds the camera and lens around the mirror. It seems that scattering centers move in ways that cannot be explained by a misaligned rotation axis. So we wanted to make sure that the mirror surface is actually imaged as we intended to. We generated a white grid with 0.7cm spacing and black background on a monitor. The image that we saw is exactly how we expected it to be. So the image mystery has other reasons.
Reinstalled Debian 8, all packages and CDS software.
Everything seems to be working fine now.
While I was working, the network connection went down. I tried to reboot the workstation, but I won't boot anymore.
Working on it...
The last two ring downs I measured today showed a weird behavior of the lowest modes:
Although I'm not 100% sure, I suspect this is related to the fact that the beam reflected from the black glass was so close to the beam reflected by the disk that I could see interference.
So I broke vacuum and improved the setup, adding a peek washer below one edge of the black glass, to wedge it. In this way the reflection from the black glass is largely separated: it misses the upper periscope mirror and it is dumped on a black panel (together with the viewport reflection).
I realigned everything, installed back the disk and started pumping down at 1:30pm.
The wandering line I mentioned in my previous elog, which is spoiling most of the sensitivity, turns out to be power noise of the laser.
I used a Thorlabs PDA100 and a SR785 to measure the power noise out of the laser directly, and saw a huge forest of peaks above 20kHz. Among them, a couple of peaks are moving up and down in frequency very fast. The plot below compares two different times of the Thorlabs HNL210L laser (the new one, 21 mW) with the old JTSU laser we are using for the test setup:
The noise of the new laser is cleary much larger (even after the laser has been on for some time) and non stationary. This is a big issue for us. I will contact Thorlabs to inquire if this behavior is normal.
The attached video file shows the peaks dancing around on the SR785 screen.
I added three 1"x1" viton pads below the base plate, and realigned the entire optical system to the horizontal reference
The pads seem to reduce a bit the vibrations in the QPD_X direction, but significantly improve the situation in the QPD_Y direction, see below:
We connected the analog output of the vacuum gauge controller to one of the ADC channels. The signal is calibrated so that the pressure is 10^(X3:CR1-PRESSURE_LOGTORR_OUT). Unfortunately the RTG does not know how to compute 10^x...
This afternoon we opened the tall belljar vacuum chamber, and took everything out of it. All the stuff that was inside the chamber is "temporarily" stored on the floor beside the optical table.
We installed a "spacer" into the chamber, made from one of the optical table legs that were sitting in the hallway. We installed one of the aluminum base plates on top of it, so that the optical components will be at the level of the viewport. Another leg and a thinner base plate are installed out of the chamber, at a similar level.
After this we closed the chamber with one of the flats used for the old chamber, and a rubber o-ring. We started the roughing pump, quickly reached a pressure below 1 mTorr and switched on the turbo pump. Unfortunately, it seems that the low pressure gauge is not working properly, so we don't know what's the pressure right now. We'll check the gauge and controller tomorrow morning and swap it out if needed.
Fixed the 307 gauge controller (a missing contact on the rair panel). The low pressure gauge was connected to 1G port and has measured 1.7E-6 torr. We are not sure since how long the turbo was operating (no vacuum logger yet).
Installed a gate valve between the roughing and tubbo pump. See below a pump down curve. The convection gauge is not calibrated. the turbo started at 14th min (at about 3 torr)
At 5pm the pressure was 6.5e-6 torr.
Checked again at:
As decided at out Red Door meeting, we're going to clean the vacuum chamber and move it to the large table, which will be enclosed in a clean room.
So today we disassembled and packaged the vacuum chamber, which is now ready to be trasnspoted to be cleaned and baked.
This afternoon I removed the old periscope from CR0 and installed a new one with finely adjustable mount, like those in the new chamber. I realigned the optical lever to the horizontal refererence.
Today I measured the amount of space available on the table for the new (4-fold) C.Ri.Me. setup. It's 1050 x 1220 mm, with the table hole in it.
So I updated the optical layout to fit into this space, and optimized the telescope to have a beam spot on the QPD of the order of 350 um. The average lever arm length is 1.5 m, so the optical gain will be about 7000 /rad.
Four substrates from University Wafers (76.2mm / 0.5mm) in chamber
Today I swapped out the 8mW laser and installed two 2.5 mW lasers. I rebuilt the input part of the optical levers and re-aligned everything. See below for a picture of the new setup: red beams are input, yellow beams are output. I also installed a protective screen all around the table, to abvoid any suprios beam to get out.
The lasers are behaving well, there is no high noise or wandering lines. The spectrum below is taken in air: that explains the excess of noise in the few kHz region.
The turbo pump of the CR0 chamber runs at 833 Hz. It causes vibrations that pollute the measurements in the CR1-4 chamber. In particular CR1 is extremely sensitive and the line is highly up-converted. It's not clean why CR1 is more sensitive than CR2-3-4.
I changed the set point of the test chamber turbo pump to 666 Hz. This was done by setting the "standby rotation speed" to 80% and enabling the standby condition.
I looked into a couple of turbo pump switch on periods, and in both cases when the pump speed hits 58 Hz, a resonance is excited. I'm not sure what's resonating.
Today I let the roughing pump reduce the pressure to a level lower than usual, and this seems to mitigate the effect. The disk wasn't shaking as much as it did in previous pump-downs.
For a long time I had problems with the GPS time in frames being different from the real one.
This morning I rebooted the cymac3 and swapped the function generator with a new one.
I tested the GPS time in frames by switching on teh ESD noise at a given GPS time and checking the frames. The times are aligned.
I'll have to wait and see if this remains stable over time (in the past i saw an acculation of few seconds per day)
EDIT: I checked the two SR DS345 one against the other. Indeed, when bpth set to generate 65536 Hz, there is a continuos drift in the relative phase, accounting for one cycle over about 3.9 seconds. This would sum up to one second over ~256000 seconds, or about 3.5 days. It seems more or less comparable with the amount of GPS time mis-syncronization I saw. I'll have to wait a few days to see if the new clock is stable.
Things seems to be worse now. This morning I injected noise at GPS 1165078533 (real time, as obtained from the python command line, and consistent with what displayed in the MEDM screen) and found the injection in the data at GPS 1165078555, so 22 seconds later...
Now the time difference is about 30 seconds. It seems that the real time model is about 29 seconds advanced with respect to the GPS time one gets from a python script command running on the cymac3
The GPS time I get from python is the same I get from a shell script on the workstation or on the cymac3. I checked that it is also consistent with the GPS time on cymac2.
I moved the picomotors at precise times and looked at the data in the frames. Indeed the data has the wrong time stamp.
I swapped the SR signal generator with an Agilent 33210A. Shut down and restarted the cymac3. Now the command line GPS and the IOP model GPS are aligned within one second. Let's see if it stays this way.
Update at 5pm, GPS times are still in sync.
Unfortunately, this morning the model time is again wrong...
I put back the Stanford Reserch signal generator. On a scope, the timing signal looks good. There is a small ripple and some noise in the flat parts. I found that when I unplug the DAC timing cable, the ripple and the noise goes away.
I'm leaving the DAC timing unplugged for the night, and I'm using a script to track the difference between the machine time and the front-end time.
For the last ~day the difference between the frontend GPS time and the machine GPS time remained constant between -1 and -2 seconds
I reconnected the DAC timing cable at
PST: 2016-12-08 09:23:06.934999 PST
UTC: 2016-12-08 17:23:06.934999 UTC
After that, the timing started to drift at a rate of about 1 second every 2300 seconds (4.35e-4). So the conclusion is that the culprit for the timing issue is on the DAC connection side.
This afternoon I installed the picomotor and the translation stage that will be used to move the retaining rings up and down. No partciular problem: I only had to add some small aluminum foil shims between the ear of some rings and the square plate, to make the rings as horizontal as possible.
I tested the motion: with 300000 steps it's possible to move the rings all the way from the parked (down) position, to the up position. I also checked that when the rings are up, I can place four substarates and they fall properly into the alignment groove. Since the maximum speed of the picomotor is 2000 steps/s, it takes 150 seconds to move up and down the ring.
Finally, positive steps means that the rings are moving up, negative that they're moving down.
I raeligned the optical levers to the position I obtained by centering the samples with the rings. I haven't tested the repeatability yet.
The ring motion up and down was not very smooth, again due to friction on the centering pins.
So, after centering the rings using the pins and securing the rings to the translation stage, I removed all pins.
Now the motion up and down is very smooth.
I still have to fine tune the amount of steps that are needed to go up and down.
However, initial tests don't show a good repeatability of the positioning. My main suspect is that the vibration caused by the picomotor cause the disks to slip on the silicon lens. Indeed, when the disks are sitting on the rings, one can clearly hear them "rattle".
My previous test showed that the timing drift was somehow related to the output of the signal generator being connected to the DAC.
Some more findings follow. When the CyMAC is powered down, the timing sent to the DAC is highly distorted. It stays the same even when I power the CyMAC up again, and it gets better only after the IOP process is started. My guess is this has something to do with the DAC board initialization. In the following: first trace is the timing signal with CyMAC off; second with the CyMAC powering on, but IOP not yet started; third when the IOP process is running.
A small residual distortion around the transitions is visible. This is not present on the original signal, or even if the ADC only is connected to the timing.
To try to debug the problem, I set up a second signal generator (not locked to the first one) and used it to provide the DAC timing. In this way ADC and DAC get their timing from two different signal generators.
I still see the same small distortion on the DAC timing. More important, I noticed that the signals generated by the DAC (here a 1kHz sinusoid) are very noisy: there is a very large glitch at every clock transition. Is this a sign that tha DAC is malfunctioning? I don't recall seeing anything like that in any other case. In both screeshots, the purple trace is the DAC output (1 kHz sinusoid) and in the second screenshot the blue trace is the DAC timing. It's clear that there is a glitch every time the clock signal transitions.
I swapped the DAC with another one, but I see the same behavior in the output signal. Here's a spectrum of the DAC output, with and without output.
I find sometimes that the probe configuration can give these distorted signals. For the Tektronix probes, its best to use a 500 MHz probe instead of the BNC clip leads. The probe also should be compensated by attaching to the gold fingers square wave generator on the scope front and adjusting the capacitor in the probe with a little screwdriver until the square wave becomes perfect.
Following the model from R. Nawrodt et al. Investigation of mechanical losses of thin silicon flexures at low temperatures, CQG 30 (2013) 115008, I predicted the thermo-elastic losses in the Si sample. The model matches quite well the measurements:
Here are some details on the model, eq. 1 and 2 of the cited paper:
The model is for a cantilever, but it fits well enough for our disk too.
Yesterday we received the prototype of the disk suspension and retain system. Everything looks good. I checked that the disk fits in the holder, and all dimensions are good. The coil holders are out for winding, so I couldn't test the movimentation yet.