Annealing run (449-453) on 3" wafers - Crime 11/01/2016 https://dcc.ligo.org/T1600507

Started annealing run Annealing run (489-490) on 3" wafers - Crime 01/18/2017 https://dcc.ligo.org/T1700027 using new hardware

 Started Annealing run (491-496) on 3" wafers - Crime 01/20/2017 https://dcc.ligo.org/LIGO-T1700036 Will be done by Monday

Started an annealing run https://dcc.ligo.org/LIGO-T1700271

Will be ready by Friday morning

Started annealing run https://dcc.ligo.org/T1700293

Will be ready by June 28th afternoon

Annealing of 8 fused silica substrates (50mm/0.5mm) started at 3:30pm, January 25th 2018. Standard program: 9 hours ramp up to 900 C, 9 hours hold, 9 hours ramp down

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.

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.

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.

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

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 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.

I did some FEA simulation of fused silica disks, to identify the lowest usable eigenmode. By usable I mean a mode that has zero elastic energy stored in the center. 

In the attached figures, the dfisk deformation is shown exaggerated, and the color map shows the elastic energy density. All results are obtained with COMSOL/MATLAB, the disk are constrained at a point corresponding to the center of the lower surface. No gravity.

The QPD quadrants are wired accoridng to the following convention

The equations below are wrong. Please refer to https://nodus.ligo.caltech.edu:8081/CRIME_Lab/116 for the correct results

I measured the properties of the beam on the QPD. The total power is 31 uW. The beam shape is not gaussian, since we are seeing the interference of the reflection from the two surfaces:

The X and Y diameters are 1400 and 1300 microns, so I take the average of the two as an estimate of the beam size: 1300 +- 100 um. I also estimated the lever arm length to be 1.03 +- 0.02 m.

This allows me to esitmate the response of the normalized QPD signal to a tilt of the disk surface:

Plugging in the numbers gives a gain of (1900 +- 300) /rad for the normalized signals. I implemented those numbers in the filter banks: now X_NORM and Y_NORM have units of radians, and measure the disk surface angular motion. I also calibrated the SUM channel in microwatts, using the nominal responsivity of 0.45 A/W and the transimpedance of 200k (gain 11.1 uW/V)

Here's teh calibrated spectrum: note that the background noise is much larger than the real one because of the signal jumps.

I measured the noise sources limiting the QPD sensitivity. Unfortunately, I had to do some MATLAB tricks to get rid of the glitches: basically I load the data directly from the raw frames (NDS access to data is not working yet) and remove all jumps in the signals that happen in one single sample and are larger than a manually tuned threshold. This is not perfect, but it's enough to give us a rough idea of the spectrum of the QPD signal. The following plot shows the QPD_X signal (in units of disk motion, radians) in a few situations:

• Blue: normal (laser on, room lights on)
• Orange: laser on, room lights off (including the vacuum gauge)
• Yellow: laser and room light off
• Purple: same as above, but I switched off the PC monitors too
• Green: QPD electronics off (this is the ADC noise)

The total power on the QPD is 30 uW, which correspond to a shot noise limited sensitivity of 4.3e-12 W/rHz. Considering that the signal is the quadrant asymmetry normalized by the total power, the shot noise limited sensitivity is sqrt(2) * SN / Power which once calibrated corresponds to 1.1e-10 rad/rHz.

The following plot shows that shot noise is the dominant source, followed closely by the electronics dark noise. The total agrees perfectly with the measured background noise above 2 kHz. Below that we have some leakage due to the large turbopump peak: this is due to FFT limitations but mostly to unsuppressed glitches.

From the QPD datasheet (Hamamatsu S5981) I learn that the noise equivalent power should be of the order of 2e-14 W/rHz at the sensitivity peak, so probably a factor of two or so worse at the HeNe frequency. It's still much lower than the measured dark noise. 

This sensitivity is already pretty good, but we can improve it by increasing the power on the diode. Indeed, 30 uW corresponds to about 2.7 V after the transimpedance, so we could increase the power by a factor 4 and win a factor 2 in the shot noise to dark noise ratio. Probably not worth it, since it will give us only a 30% gain in high frequency noise.

Just to confirm that my noise estimates make sense, here's a plot of the not-normalized QPD signal that gives the X motion (sum and difference of all four quadrants):

This is the signal after compensating for the whitening filter. If I remove this compensation, the following plot gives the noises in terms of the voltage directly in input to the ADC (or in output of the analog board):

So the total "dark" electronic noise is about 13 uV/rHz.

I did a roughly estimate of the sources of electronic noise:

• QPD dark current noise, from datasheet, at the peak sensitivity is equivalent to 2e-14 W/rHz, or 2 nV/rHz at the output of the TI stage
• First stage: Johnson-Nyquist noise of the TI resistor: 58 nV/rHz
• First stage: output voltage noise of the LT1124: 3 nV/rHz
• First stage: input curent noise of the LT1124, converted to the output: 60 nV/rHz

So the total noise at the outoput of the first stage is about 84 nV/rHz. The second stage adds a gain of 30 at high frequency, and negligible noise. So at the output of the whitening we have 2.5 uV/rHz. The DRV135 adds another gain of 2 and a neglegible output noise. 

So the total electronic noise at the output of each quadrant is 5 uV/rHz. Since we are combining four of them, the total expected electronic noise is 10 uV/rHz, which is not too far from the measured value. 

We are basically dominated equally by the Johnson-Nyquist noise of the TI resistor and by the input current noise of the LT1124. No gain to be obtained by changing the whitening.

So I’m sending a 1.123 Hz sinusoid into the ADC, and generating 3.123 Hz sines and cosines in the model. Frequencies are reasonably incommensurable with one second.

Here are the nominal parameters of the disk with flats

A COMSOL simulation gives the frequencies and mode shapes shown in the attached PDF file. Following the list of frequencies and a classification of the mode family (numer of radial nodes, number of azimuthal nodes in a half turn):

Last night measurements didn't work well: even without exciting the modes, the ADC was saturating because of the low frequency signal, particularly a 58 Hz peak:

When the modes were rang up, thing got clearly even worse:

Modification of whitening filter

So I modified the whitening filter, changing C6 from 2.2u to 220nF. The old and new whitening filters are shown below. We have the same amount of whitening at high frequency, but less amplification of the junk at ~50-100 Hz

With this modification, there's no more saturation, even when the modes are excited.

The excitation is working fine. However, there is a large cross coupling in the excitation between channels: so if I switch on only one of the ESD paths, I actually excite all other disks too.  It might be due to the common ground or to the fact that the cables run close to each other. This needs some investigation, but it's not a big issue for the moment being.

On the other hand, the optical levers are very well decoupled: each one sees a different set of modes. So there is no measurable cross coupling between the disks or the readout.

There seems to be something fishy with the Y picomotor of QPD3: it doesn't always move in the same direction for the same set of steps. Some investigations needed here too. Autocentering might fail, but it's still possible to center it manually.

Excitation at 4:56pm (quiet time before excitation 1170032165, quiet time after excitation 1170032234).

Another excitation at 8:30am (2017-02-02) (quiet time before excitation 1170088185, quiet time after excitation 1170088373)

While I was working, the network connection went down. I tried to reboot the workstation, but I won't boot anymore.

• First issue: firmware of network card disappeared. I managed to download it on a USB stick and install it back
• Second issue: mismatch of NVIDIA graphic card drivers and kernel. Can't start X

Working on it...

Reinstalled Debian 8, all packages and CDS software.

Everything seems to be working fine now.

Instructions on how to setup a workstation are available here:

https://nodus.ligo.caltech.edu:8081/Cryo_Lab/1135

I'll copy them here and integrate once I got the C.Ri.Me. workstation up and running

** libmotif4 >> libxm4 : sudo apt-get install libxm4

** all .sh files in etc must be modified to point to the correct version of the downloaded software

** add the following line to the end of the ligoapps-userv-end.sh file to get medm and striptool working

PATH="/ligo/apps/ubuntu12/epics-3.14.12.3_long/extensions/bin/linux-x86_64:$PATH"

** to fix diaggui problem, create a symbolic link in /usr/lib/x86_64-linux-gnu/

sudo ln -s libtiff.so.5 libtiff.so.4

The following table shows the lowest eigenfrequency (Hz) for different sizes of disks

In the last days Jamie installed the patched kernel to run the real time system (RTS) on the new CyMAC. Today (with Jamie's remote advices) I managed to get a IOP (input output process) model compiled and running. There is still no timing input (to be fixed at the beginning of the netx week, I'm presently missing a connector which is on order).

Running the x1iop model gives:

controls@cymac3:/opt/rtcds/tst/x1/scripts$ ./startx1iop 

x1iopepics: no process found

Number of ADC cards on bus = 1

Number of DAC16 cards on bus = 1

Number of DAC18 cards on bus = 0

Specified filename iocX1.log does not exist.

x1iopepics X1 IOC Server started

controls@cymac3:/opt/rtcds/tst/x1/scripts$ awg_server Version $Id: awg_server.c 2917 2012-05-22 22:33:39Z alexander.ivanov@LIGO.ORG $

channel_client Version $Id: gdschannel.c 4170 2016-04-05 21:24:46Z jonathan.hanks@LIGO.ORG $

testpoint_server Version $Id: testpoint_server.c 3303 2013-03-05 23:33:45Z alexander.ivanov@LIGO.ORG $

/opt/rtcds/tst/x1/target/gds/bin/awgtpman -s x1iop -4 -l /opt/rtcds/tst/x1/target/gds/awgtpman_logs/x1iop.log started on host cymac3 hostid ffffffffd783d97b 

awgtpman Version $Id: awgtpman.c 4170 2016-04-05 21:24:46Z jonathan.hanks@LIGO.ORG $

I copy here parts of an email from Jamie with instructions on how to run the RTS on the cymac:

I had to change the site/ifo to be "caltech/x3" to avoid EPICS
collisions with other cymacs.  You'll need to update your models to
reflect this change (change names, site/ifo parameters in the model,
etc.).  So for instance, change x1iop -> x3iop, and update the params
block inside.

daqd is installed and running, although I haven't really stress tested
it yet (no models/channels/etc).  It's running under systemd, which is
the Debian service management system.  You can control daqd with the
following commands:

# systemctl restart daqd
# systemctl stop daqd
# systemctl start daqd
# systemctl status daqd
# journalctl --unit=daqd

controls@cymac3:~ 0$ systemctl status daqd
● daqd.service - Advanced LIGO RTS daqd service
  Loaded: loaded (/etc/systemd/system/daqd.service; enabled)
  Active: active (running) since Sat 2016-07-09 11:22:38 PDT; 23h ago
Main PID: 20827 (daqd-standiop)
  CGroup: /system.slice/daqd.service
          └─20827 /usr/bin/daqd-standiop -c /etc/advligorts/daqdrc
controls@cymac3:~ 0$ sudo journalctl --unit=daqd
...

Remember to restart daqd ("systemctl restart daqd") after you add/change
models.

I've gotten all the RCG components working, but not without some small
kinks.  The RCG currently expects a specific EPICS install, different
than the system install we're using right now.  I've hacked a way to
make this work seemlessly for model builds, but it requires sourcing the
following file before *starting* models:

/opt/rtapps/epics/etc/epics-user-env.sh

So in the mean time, you can start/stop models via the following:

$ . /opt/rtapps/epics/etc/epics-user-env.sh
$ /opt/rtcds/caltech/x3/scripts/startx1iop
 

We played around a bit with the cymac, in efforts to make things better.

• We disabled some more fancy-sounding options in the machine's BIOS
• I created safe.snap files for the x3iop and x3tst models 
  • x3iop's was created by booting the model while mashing the EPICS command to set the burt restore bit, and then saving the EPICS database to file via the SDF screen
  • x3tst's was created by copying an existing .snap file 
• I gave the controls user ownership of /frames via sudo chown controls:controls /frames
• I then created the following folders (which the daqd log was complaining about not finding_
  • /frames/full
  • /frames/trend/minute
  • /frames/trend/minute_raw
  • /frames/trend/second
• I also created the folder /opt/rtcds/tst/x3/target/fb, since that is listed in the daqd config as the nds job dir. (However nds does not seem to be running. Is it needed? I couldn't compile it in the rtbuild directory)

As I see it, the main problems that persist are:

• daqd crashes over and over again every few seconds
  • The logs seem to be complaining about EPICS server problems. Is the related to whatever situation made the epics-env script neccessary?
• The IOP seems to be taking too much time: 8-9 usec
  • This is especially problematic as Gabriele actually wants to run the IOP at an even faster rate than the current 64k, which isn't possible with the current timing

The laboratory workstation is coatings.ligo.caltech.edu

The RTS is cymac3.ligo.caltech.edu

I set up a ssh-mount of the /opt/rtcds/userapps folder in the workstation. I also created shared ssh keys for the controls user, so we can ssh into the cymac3 without password

[EricQ, Gabriele]

The real time system seems to be working properly, except for the excitations: we can't activate any excitation using awggui or diaggui

Eric rebuilt the workstation from scratch installing Debian 8.5. All CDS software seem to be working. We setup a ssh-key for ssh'ing into cymac3 and configured the automatic mount of the remote /opt/rtcds.

The glitches I saw in the data happens roughly every second, even though not exactly on the second. They are suddend jumps on the signal values over one sample, so of clear digital origin

Not so sure anymore...

• those glitches do not happen at regular times
• I tried to send a sinusoid into another ADC channel, and I couldn't see any jump
• using DTT and zooming into the jumps, they don't seem a clean one-sample jump anymore... There might be a bit of ringing before and/or after the jump
• The jumps have different sizes and directions, and they seems to happen at the same time in all four quadrants, but not in the same direction or with the same amplitude

I was suspecting dust crossing the beam, so I build a very rough enclosure, that should help with dust. I don't think I saw any change in the glitches. 

Also:

• glitches are there even with the HeNe off, with ambient light only. So it's not the laser.
• I tried sending a sinusoid into one of the same ADC channels used to acquire the QPD signals. I couldn't see any glitch

So one might conclude that the glictches are produced by the analog QPD electronics. However, I plugged in a scope and I couldn't see any in the analog signal. But I checked only before the DRV135 stages. I'll need some sort of breakout board to test the output of the DRV135.

[Rolf, Ben, Rich, Gabriele]

Rolf couldn't find any good explanation on the software side for the signals jumps. He investigated a bit the reason why IOP takes a long execution time, without success. It's still mysterious why it ran with low time for a while.

One effect of Rolf activity is that now the signal jumps happen at ~0.8 seconds (after the start of each second) instead that ~0.45. This is suspiciously pointing to a software issue...

Ben and I spent a few hours trying to better understand the origin of the glitches. Finally, we plugged in a function generator to the four ADC channels, and we could find the glitches again, at the expected time. So we could rule out completely that it's a problem of the QPD analog electronics.

Some more ivnestigations:

• swapped the SR DS345 with an Agilent 33210A for the timing signal. No change: jumps are still there
• rebooted and powered off the cymac many time, this never changed the glitches or the position in time
• swapped the ADC interface board (D1600196) with a new one similar to that of the crackle lab (D1500402): no change, jumps are still there
• switched off the roughin pump to reduce ambient acoustic noise. Not surprisingly, no change, still jumps
• according to the motherboad manual, PCIe slots 4 and 6 are PCI-EX16, while the other are PCI-EX8. I moved the ADC and DAC to those those slots. Guess what? No change, still jumps

On a bright side, Rolf recompiled the awgman software, and now excitation channels are working.

Here are two more tests I did this morning

• removed the DAC card from the cymac and the models, and restarted everything: signal jumps are still there
• move the cymac2 from the crackling noise lab to the CRIME lab, ans set it up with all the same hardware I was using with the cymac3: there are no jumps, signals look perfect (see plots at the end)

So in conclusion: the problem is in the cymac3 computer, either software or hardware. I tend to excluse an I/O hardware problem, since I used two different ADCs and removed the DAC, without improving the situation.

This plot shows a signal which is generated purely digitally inside a code that I was testing.

Jumps are present even in this case.

Another addition: I was testing some simple code I was writing. Forget about OUT1 and OUT2, but OUT3 and OUT4 should be simple counters. Here's what I get by running the code on cymac3:

Since it didn't make any sense, I ran the same code on cymac2. Here's the (correct) result:

So there's something wrong even when all-digital signals are generated.

Compiled and installed an updated real time model. It acquires the four QPD segments, compute sum and differences, and normalize. I also added three experimental peak tracking components, that will be used to track in real time the amplitude and frequency of the disk modes.

I also created a summary medm screen that can be used to control all the QPD readout. It can be opened from any terminal with the command 'cr1'. I haven't added the peak tracking parts yet.

The X_NORM_OUT and Y_NORM_OUT signals are high passed at 500 Hz, to get rid of low frequency stuff that can affect the peak tracking.

I cross checked the calibration of the sum channel with a  power meter. Now all quadnant signals X3:Q?_OUT and the sum signal X3:CR1-SUM_OUT are correctly calibrated in microwatts.

Installed two new 2TB disks into the cymac3. Also, the main disk has a 1TB partition with the operating system, so I created a new 1TB partition. I created a logic volume that spans the three partitions, for a total of about 5TB. This partition is mounted in /mnt/data and linked to the /frames folder. Frames are written to this new logic volume.

The cymac3 internal clock was off by about 10 seconds. When I tried to start the NTP service, I found out that the cymac3 couldn't reach any external server. It turned out that the gateway in /etc/network/interfaces was set to the wrong address. I fixed it and rebooted. Now NTP is working and the time is correct.

This fixed a small issue with diaggui, which always complained about a data receiving error when starting a measurement (although after the complian the measurement could continue)

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.

I was looking at some past trend data and discovered that EPICS values were not written to the frames. I added the following two lines to /opt/rtcds/tst/x3/target/fb/master to fix this:

/opt/rtcds/tst/x3/chans/daq/X3EDCU_CR1.ini
/opt/rtcds/tst/x3/chans/daq/X3EDCU_TST.ini

Now EPICS values are saved to frames, but they are all zero! I noticed that we always had the same problems with the cymac2 too.

So for the moment being I set up daqd to save X_NORM_IN1 and Y_NORM_IN1 at 32 Hz. In this way I can monitor the QPD centering.

/opt/rtcds/tst/x3/chans/daq/X3EDCU_CR1.ini
/opt/rtcds/tst/x3/chans/daq/X3EDCU_TST.ini

I moved the turbo pump controller out of the clean room. Also, I installed the gauge controller on the Cymac rack.

Apparently, there was a mismatch in the configuration, and DAQD was adding a wonderful 16 Hz comb all over the spectrum.

I stopped the processes, but couldn't restart x3cr1. It turned out that I can't save a channel to frames with a sampling frequency lower than 256 Hz. I changed the model, recompiled and restarted. Now the 16 Hz is gone.

/opt/rtcds/tst/x3/chans/daq/X3EDCU_CR1.ini
/opt/rtcds/tst/x3/chans/daq/X3EDCU_TST.ini

I removed the low pass filter in the QPD SUM signal, used for normalization. This reduced a lot the bump at ~20kHz due to laser intensity noise.

I also switched off the 500 Hz high pass filters in the X_NORM and Y_NORM signals.

Removed the peak meter lock from the model, since it's not used

Added and EPICS binary bit to control the autocenter, added corresponding buttons to the MEDM screen.

Now the GUI stops the autocentering when acquiring the reference spectrum.

The auto_excite.py also stops the autocentering 35 seconds before the excitation and until 35 second after the excitation, to provide for two reference quiet periods.

To be used to automate the laser polishing.

I modified four more QPD boards to implement the new whitening filters detailed in elog 207.