The vacuum safety policy and design are not clear to me, and I don't know what the first and second defense is. Since we had limited time and bandwidth during the remotely-supported recovery work today, we wanted to work step by step.

The pressure rising rate is 20mtorr/day, and turning on TP3 early next week will resume the main-volume pumping without too much hustle. If you need the IFO time now, contact with Jon and use backing with TP3.

Didn't mean to sound whiny. I will wait until the vacuum team tells me it is okay.

Thanks for checking this out Koji

The builder in 1996 was Process System International, Inc ( Westborough, MA ) It does not exist any longer or I just could not find them. Flow diagramm at Atm1

Should I be keep looking for a company who could quote us for building a similar smaller unit with 10 - 15 cfm flowrate?

Note: my intension with the two mobile-overhead HEPA filter was the same as John Worden's " clean air overpressured tent " at chamber entrance.

Atm2, Our unit has 650 cfm, velocity 90 fpm at resistance 0.5"    It may be enough to give a little overpressure if we seal it well to the chamber

We use to use them to minimize dirt getting inside the chanbers.

We have no number for the CFM without calculation. We can't assume a random number like 10-15

I've visited the purge clean air system at LHO Yarm mid-station with John Worden.

The system is described C981637. There is a schematic in C981637-06-V (Vol.6).pdf although the schematic has some differences (or uncorrected mistakes).

This system is intended to provide positive pressure when a soft cover is attached to a chamber door. When the door is open, the purging does not help to keep the chamber clean because the flow is too slow. This protection has to be done with overhead HEPA filters (22x5000cfm). It may be possible that this purge air helps the tube not to allow dusts to come in. But before using this, the chambers and the tubes have to be cleaned, according to John.

- Here at the site, the purge air system is started up a day before the vent. This system is used for the vent air, the purge air, and turbo foreline filling.

- Air intake (attachment 1): At the site, the air is intaken from the VEA. We want to incorporate somewhat clean air instead of dirty, dusty, outside air.

- Initial filter (attachment 2): a high volume filter before the compressors.

- The compressors (attachment 3, 4) are 5x 6 horse power air compressor each goes up to 160 psi. They are turned on and off depending on the demand of the air. Which is turned on is revolved by the controller to equalize the compressor usage hours.

- The compressed air goes through the air cooler (heat exchanger) to remove the heat by the compressor work.

- This air goes through prefilters and accumulated in the air receiver (100psi) (attachment 5). This receiver tank has an automated vent valve for periodical water drainage at the bottom.

- The accumulated air is discharged to twin drier towers (attachment 6, blue). The tower is operated by the controller (attachment 7) alternately with a period of 4min (or 10min by setting). When one of the towers is working, a humid air comes from the bottom and the dry air is discharged from the top. A part of the dry air goes into the other tower from the top to the bottom and dries the tower. There is a vent at the bottom to discharge water periodically.

- The dried air goes through 4 types of filters. After the last filter, all of the plumbing should be made of stainless steel to keep cleanliness.

- The air goes to the pressure reducing regulator (attachment 8, gray). The final flow speed at the chamber side is 50cfm max, according to John.

- The lower pressure air goes through the final filter (attachment 8, blue). As the pressure is low, this filter is big in order to keep the volume of the air flow.

- The purge air is supplied to the chamber side with KF50 (attachment 9). There is a vent valve (attachment 10) for safety and also to run a dry air for at least a day before the use to clean up the supply line. The purge line is disconnected when no in use.

- The entire system (attachment 11) and size comparison (attachment 12).

Last week, Koji cleaned up the LSC model to make it much more readable, while he was working on piping the ALS signals to the LSC model.  However, somehow the DAQ Channels block got deleted before the model was committed to the svn.  Since there were 2 months between svn checkins for c1lsc.mdl, it's possible that someone had the model open just to look at, and the block got deleted, and that's the version that Koji started with. 

Anyhow, thankfully we have the svn, so Koji and I found that the DAQ Channels block was (as expected) in the previously checked-in version of the LSC model.  I put a copy of the old model onto my desktop, opened it up, copied the DAQ Channels block, and then pasted it into the new cleaned-up version of the model.  (Jamie - is there a way to conveniently download a previous version through the web interface?)

I have checked it in, compiled and restarted the lsc model.  The _DQ channels are back now.

[Larisa and Jenne]

We wanted to get rid of the awkward cart that was sitting behind the 1Y1 rack.  This cart was supplying a +5V offset to the PZT driver, so that we could use the MC length signal to feedback to lock the laser to the MC cavity.  Instead, we put the offset on the last op amp before the servo out on the Mc Servo Board.  Because we wanted +5V, but the board only had +5, +15, -15V as options, and we needed -5 to add just before the op amp (U40 in the schematic), because the op amp is using regular negative feedback, we made a little voltage divider between -15V and GND, to give ourselves -5V.  We used the back side of the voltage test points (where you can check to make sure that you're actually getting DC voltage on the board), and used a 511Ohm and 1.02kOhm resistor as a voltage divider. 

Then we put a 3.32kOhm resistor in ~"parallel" to R124, which is the usual resistor just before the negative input of the op amp.  Our -5V goes to our new resistor, and should, at the output, give us a +5V offset. 

Sadly, when we measure the actual output we get, it's only +2.3V.  Sadface.

We went ahead and plugged the servo out into the PZT driver anyway, since we had previously seen that the fluctuation when the mode cleaner is locked was much less than a volt, so we won't run into any problems with the PZT driver running into the lower limit (it only goes 0-10V).

Suresh has discovered that the op amp that we're looking at, U40 on the schematic, is an AD829, which has an input impedance of a measely 13kOhm.  So maybe the 3.32kOhm resistors that we are using (because that's what had already been there) are too large.  Perhaps tomorrow I'll switch all 3 resistors (R119, R124, and our new one) to something more like 1kOhm.  But right now, the MC is locked, and I'm super hungry, and it's time for some arm locking action.

I've attached the schematic.  The stuff that we fitzed with was all on page 8.

I can not think of any reason that the input impedance of 13kOhm between the pos/neg inputs produces such a big change at the output. In any case, the differential voltage between the pos/neg inputs produces a big output. But the output was just 2V or so. This means that the neg input was actually about zero volt. This ensures the principle of the summing amplifier of this kind.

Because the input impedance of the summing node (the additional resister you put at the negative input) is not infinity, the voltage divider is not perfect and shows 10% reduction of the voltge (i.e. the output will have +4.5V offset instead of +5V). But still it is not enough to explain such a small output like 2.3V.

What I can think of is that the earlier stages somehow have the offset for some reason. Anyway, it is difficult to guess the true reason unless all of the nodes around the last stage are checked with the multimeters.

At least, we can remove the voltage divider and instead put a 10k between -15V and the neg input in order to impose +5V offset at the output. This costs 1.5mA instead of 10mA.

[Koji, Suresh]

    We looked at the board and found that the resistor R119 (the feed back) is 1.65k instead of the 3.32k that was needed for unity gain.  The gain has been intentionally reduced to 0.5 so that output range would be close to the 0-10V that is required at the input range of the PZT driver which follows.   A note to this effect is already present in the D040180-B, page 8.

    The voltage divider with 1k and 0.5k provides 4.5V (ref Koji's note above) this provides 2.25V at the output due to the gain of 0.5.  To get to the original goal of introducing a 5V offset on the output, we introduced the modification shown in the  'D040180-B with 5V offset.pdf' uploaded below.  Please check page 8, the changes are marked in red.  We checked to make sure that the output is 5V when the input is disconnected. 

The PCB pics at the end are also attached.  The 4.99k resistor is glued onto the PCB with epoxy and placed as close to the opamp possible.

Put the accelerometers on top of MC2. Orientated as the arms,GUR1 and STS1:

Should be fixed a bit more rigidly.

Looking into the signals at a quiet time:

Hmm. Either the acc. are mislabeled or there is really bad x-y coupling. The connectors in the back of the acc. power supply / amplifier box are in ascending order.

[josephb,Suresh]

We put in the fiber for use with the Dolphin reflected memory between c1sus and c1lsc (rack 1X4 to rack 1Y3).  I still need to setup the dolphin hub in the 1X4 rack, but once that is done, we should be able to test the dolphin memory tomorrow.

Power Spectral Density plot using PyNDS, comparing 5 fast data channels for ETMX.

**EDIT** Script here:

import nds
import numpy as np
import matplotlib.pyplot as plt
import time
daq=nds.daq('fb', 8088)
channels=daq.recv_channel_list()
e=0
start=int(time.time()-315964819)
rqst=['C1:SUS-ETMX_SENSOR_UR','C1:SUS-ETMX_SENSOR_UL','C1:SUS-ETMX_SENSOR_LL','C1:SUS-ETMX_SENSOR_LR','C1:SUS-ETMX_SENSOR_SIDE']    #Requested Channels
for c in channels:
    if c.name in rqst:
        daq=nds.daq('fb', 8088)
        data=daq.fetch(start-100, start, c.name)
        vars()['psddata'+str(e)], vars()['psdfreq'+str(e)]=plt.psd(data[0],NFFT=16384,Fs=c.rate)
        vars()['label'+str(e)]=c.name
        e+=1
plt.figure(1)
plt.clf()
plt.title('PSD Comparison')
plt.grid(True, which='majorminor')
plt.xlabel(r'Frequency $Hz$')
plt.ylabel(r'Decibels $\frac{dB}{Hz}$')       
for x in np.arange(0,e):
    plt.loglog(psdfreq0, 10*vars()['psddata'+str(x)], label=vars()['label'+str(x)])
plt.legend()
plt.show()

 Is there any stuff to install, etc?  Y'know, for those of use who don't really know how to use computers and stuff....

 No new stuff for these computers.  Everything should be installed already.

After getting some help from the Basler technical support, I was directed to the following ftp link:

ftp://Pylon4Linux-ro:h50UZgkl@ftp.baslerweb.com

I went to the pylon 2.1.0 directory and downloaded the pylon-2.1.0-1748-bininst-64.tar.bz2 file.  Inside of this tar file was another one called pylon-bininst-64.tar.bz2 (along with some other sample programs). I ran tar -jxf on pylon-bininst-64.tar.bz2 and placed the results into the /opt/pylon directory.  It produced a directory of includes, libraries and binaries there.

After playing around with the make files for several sample programs they provided, I finally have been able to compile  them.  At several places I had to have the make files point to /opt/pylon/lib64 rather than /opt/pylon/lib.  I'll be testing the camera with these programs on Monday.  I'd also like to see if this particular distribution will work on Centos machines.  There's some comments in one of the INSTALL help files suggesting packages needed for an install on Fedora 9, which may mean its possible to get this version working on the Centos machines.

When trying to install an older version of Pylon packaged for Debian that Joe B. had sent, it gave the warning that the package was of bad quality along with the details below.

Is it safe to ignore the warning? Or should I hold off on the installation?

Lintian check results for /home/controls/Downloads/pylon-2.3.3-1.deb:
Use of uninitialized value $ENV{"HOME"} in concatenation (.) or string at /usr/bin/lintian line 108.
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.IpConfigurator
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.PylonViewerApp
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.SpeedOMeter
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4.3.2
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so.62
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so.62.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so.3.7.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/plugins/imageformats/libqtiff.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libXMLLoader_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApiPreProcessor
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libGCBase_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libGenApi_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libLog_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libMathParser_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/liblog4cpp_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libgxapi-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libgxapi.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonbase-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonbase.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylongigesupp-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylongigesupp.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonutility-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonutility.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pyloncamemu-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pyloncamemu.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pylongige-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pylongige.so

It looks like we may not need to use this old Pylon version after all. Gautam and I looked into installing SnapPy with the makefile in scripts/GigE/SnapPy/ that he modified (removed the linkage to paths that don't exist in Pylon 5). Compiling took a while (~10 minutes) but eventually succeeded. The package was installed to /ligo/apps/linux-x86_64/camera/

GV 10pm April 10 2017: We didn't actually try executing an image capture or change some settings using the python utilities, that remains to be done..

New script called scripts/ALS/findRedResonance.py finds the IR resonance in less than 20 seconds.

1. Do a ~2 FSR scan of the arm over 10 seconds using the Phase Tracker servo offset ramp. (dt = 10 s)
2. Load the frame data for the TR_OUT and the Phase Tracker phase. (dt = 2 s)
3. Use Python (modern) SciPy to find all peaks with moderate SNR (dt = 3 s)
4. Take the top 3 peaks (all presumably TEM00) and choose the one closest to zero and go there.

The above is the gist of what goes on, but there were several issues to overcome to get the code to run.

1. None of our workstations have a modern enough Python distro to run either the ipython notebooks or the new SciPy with wavelets, so I installed Anaconda Python in the controls home directory.
2. In order to get the peak finder function to work well I gave it a range of peak widths to look for. If we change the speed of the ALS scan by more than 3x, we probably have to change the width array in the function.
3. I've used the find_peaks_cwt function in SciPy. This uses a Ricker ('Mexican Hat') wavelet to find peaks by doing multi-res transforms and looking for ridges in the wavelet space (I think)
4. To make the code run fast, I downsample from 16 kHz to 1 kHz right at the top. Would be better if we had downsampling in v2 of the getData function.

From the last plot:

- Subtracting the offset of 0.0095, the modulation depth were estimated to be 0.20 for 11MHz, 0.25 for 55MHz

- Carrier TEM00 1.0, 1st order 0.01, 2nd order 0.05, 3rd order 0.002, 4th order 0.004

==> mode matching ~93%, dominat higher order is the 2nd order (5%).

Eric: now we have the number for the mode matching. How much did the cavity round-trip loss be using this number?

Today I realized that pip and other python2,3 packages were installed in the conda base environment, so after running

I could run the python-GPIB scripts to interface with the Agilent.

Although, I did have to add a python2 kernel to jupyter/ipython, which I did in a separate conda environment:

[Yehonathan, Gavin]

As the resonant modes of the 40m TMs are at high frequencies (starting at 28.8 kHz) we started background checks to understand if we would be able to see resonant frequency excitations in the DCPD output. We used the SR785 in the Q_OUT_DEMODULATOR port of the INPUT_MODE_CLEANER to measure around this frequency. Currently we could not see any natural excitation about the noise floor indicating it may not be possible to see such a small excitation. In any case we are conducting additional measurements in the I_MON port of 1Y2_POY11 to understand if this is a certainty.

1. Lock IMC
2. Lock one of the arms (only) using the IR PDH signal feeding back to an ETM.
3. Excite the ITM using the SR785 near 28.8 kHz
4. Look for the resulting peak using the SR785 spectra of the POX or POY error signal from the demod board
5. Based on the calibrated noise level of the POX/POY, estimate what the SNR will be of the internal mode peak.

[Yehonathan, Gavin]

Measuring POX11_Q_MON and injecting a signal into the ITMX_UL_IN port a signal could not be seen on the function generator. After debugging the source of the issue was two fold:

• By using the quadrant drives for coils (UL, UR etc) a signal has to pass through a switch before reaching the driver. To resolve this the signal input was switched to POS_IN (driving the entire coil at once rather than in quadrants) which has no switch to bypass.
• The averaging on the Stanford SR785 was set too low. By increasing the averages from 10 to 25 the signal became more visible.

Unrelated to these issues the signal input was switched to POY11_Q_MON and ITMY_POS_IN as part of the debugging process. The function generator used was switched from the Stanford to the Siglant SDG 1032X.

An unrelated issue but note worthy was the Lenovo 40m laptop used to measure the IFO state (locked or unlocked) ran out of battery in a very short timespan.

To gauge where the resonance of the test masses are FEA model of a simple 40m test mass was computed to give an esitimate at what frequency the eigenmodes exist. For the first two modes the model gave resonances at 20.366 kHz (butterfly mode) and 28.820 kHz (drumhead mode). Then by measuring with an acquisition time of 1 s at they frequencies on the SR785 and injecting broad band white noise with a mean of 0 V and a stdev of 2 V, small peaks were seen above the noise at 20.260 kHz and 28.846 kHz. By then injecting a sine wave at those frequencies with 9 Vpp, the peak became clearly visible above the noise floor.

The last step is to measure the natural decay of these modes when the excitation is turned off. It is difficult to tell currently if these are indeed eigenmodes or just large cavity injections with an associated stabilisation time (what could appear as a ringdown decay). More investigation is required.

[Koji, Jenne]

We took measurements of the Q of all the modes that we could think of for TT#4, and then repeated several of the same measurements for TT#2.  We noticed that when we took off the backplane and then replaced it on TT#4, the pitch pointing had changed, so we had to repeat the balancing procedure by slightly shifting the position of the wire clamps relative to the mirror holder. No fun. We decided to quit removing the backplanes. 

The main conclusion of this evening's measurements of TT#4 is that everything looks very close to the design ideas.  Good work team!

TT#4:

'Free Swinging' values (just for interest)

Vert, no damping:   Q = 31.4

Pitch, no damping (ECD backplane removed): Q = ~700

Yaw, no ECDs: Q = ~900

Pos, no ECDs (no measurement) - we had already put the backplane back on, and didn't want to take it off again.

Damped Values:

Vert, with damping: Q = 14.3

Pitch, with ECDs: overdamped, so Q < 1/2

Yaw, with ECDs: Q = 2.3

Pos, with ECDs: Q = 1.4

Side, with ECDs: Q = 1.9

We also measured the resonant frequency of each of the ECDs for this TT (since we had the backplane removed anyway...)

ECD UL: 10.05Hz

ECD UR: 10.15Hz

ECD LL: 10.21Hz

ECD LR: 10.21Hz

TT#2:

Yaw, with ECDs: Q = 7.0

Pitch, with ECDs: overdamped, so Q < 1/2

Vert: Problematic.  No damping, f = 25.9Hz, Q = 36.  With rubber dampers, f = 20.0Hz, Q = 42.   Yes, you read that right.  The frequency is lower, and the Q is higher *with* the damping.  Perhaps our brains are fried.  Perhaps we've discovered new, inconsistent physics (awfully unlikely....). We'll revisit this again tomorrow to figure out what mistake we're making.

Background:
 We need MC to be locked soon, so MC suspensions should be damped well(Q~5).

What I did:
1. Set the correct filters and turn all the damping servo on.

2. Kick the optics by adding some offset into the control loop.

3. Measure the Q-value of the ringdown with my eye.

4. If Q-value seems to be around 5, go to step #5. If not, change the filter gain and go to step #2.

5. Done! Do step #1-4 for all MCs.

All parameters I used for the servo are automatically saved here;
  /cvs/cds/caltech/burt/autoburt/snapshots/2010/Oct/13/20:07/c1mcs.epics

Result:
 Q-values of the damping servo for all MCs are set to around 5.
 Attached is the ringdown of MC2 for example.
 As you can see, my eye was very rough......

Next work:
 - Make a script that does steps #2-5 automatically.
    I need pyNDS module installed to get data using Python.
    I already wrote the rest of the script.
    We'll have Leo help us install pyNDS tomorrow.

Last week and this week I've been working on the characterization of the Q3000 QPDs. The QPDs were named 81, 82, 83, and 94.

• Dark current [OMC LAB ELOG 402]: All the segments looked similar and acceptable except for the seg1 of #82. It has a smaller reverse breakdown voltage (~6V) but even this is an acceptable level.
• Impedance [OMC LAB ELOG 403]: All the segments showed a ~300pF junction capacitance with no reverse bias. This looks quite normal.
• Dark noise [OMC LAB ELOG 404]: All the segments showed ~5pA/rtHz dark noise above 1Hz.

My recommendation is to use #81 and #84 as they have similar dark current characteristics between the segments. But basically, all the QPDs look fine.

The actual junction capacitance and the RF dark noise should be characterized by the actual WFS head circuit.

The QPD packages were labeled and returned to Gautam to be implemented in the WFS heads.

gautam: S/N #84 was installed as the AS WFS QPD. The remaining 3 are stored in the clean cabinet at EX (where the rest of the RF photodiodes are).

Because we would like to get started on testing mount vibrations as soon as possible, I've been trying to get one of the other QPDs we found to work with the summing/subtracting circuit on a breadboard. I've been using a power supply that I think Jamie built 15 years ago... which seems to be broken as of today, since I no longer read any signal from it with an oscilloscope.

I tried using a different power supply, but I still can't read any change in signal with the QPD for any of the quadrants when using a laser pointer to shine light on it. I'll be working with Eric on this later this week. In the meantime, I'll try and come up with a shopping list for the nicer QPD circuit that'll be a longer term side project.

Annalisa and I met yesterday and fixed the voltage regulator on the breadboard so the QPD circuit is working. We will meet with Eric on Thursday to determine the course of action with measurements.

I've remeasured the QPD ASC sensing coefficients, and figured out what I did weird with the actuation coefficients. I've rearranged the controller filters to be able to turn on the boost in a triggered way, and written Up/Down scripts that I've tested numerous times, and Jenne has used as well; they are exposed on the ASC screen. 

All four loops (2 arms * pit,yaw), have their gains set for 8Hz UGF, and have 60 degrees of phase margin. The loop shape is the same as the previous ELOG post. Here is the current on/off performance. The PDH signals (not shown, but in attached xml) show no extra noise, and the low frequency RIN goes down a bit, whic is good. The oplevs error signals are a bit noisier, but I suppose that's unavoidable. The Y-arm performs a bit better than the X-arm. 

The up/down scripts don't touch the filters' trigger settings at all, just handles switching the input and output and clearing history. FM1 contains the boost which is intended to have a longer trigger delay than the filters themselves.

Herein, I will try to paint a more thorough picture of this whole QPD ASC mess. 

Motivation for QPD ASC loops:

• We would like to use the QPDs as a DC arm pointing reference during locking attempts, or over multiple days, if possible. 
• It would be nice if the QPDs could complement the oplevs to reduce angular motion of the cavity. 
• We must not make the single arm longnitudinal noise or RIN worse, because anything observable in the single arm case will be catastrophic at full sensitivity

Actuation design:

As mentioned in a previous ELOG, in single arm lock, I measured the QPD response with respect to the calibrated oplev signals. They were:

For reference, one microradian of either ITM or ETM motion produces about 60um of ETM beam spot displacement, compared to the spot size of ~5mm. 

However, given the lenses on the end tables that are used for green mode matching, that the IR transmitted beam also passes through, the QPDs are not directly imaging the ETM spot position; if they were, they would have equal sensitivity to ITM and ETM motion due to our flat/curved arm geometry. 

From this data, I calculated the actuation coefficients for each DoF as , and similarly for the ITMs, where the d's come from the table above. However, it occurs to me that maybe this isn't the way to go... I'll mention this later. 

Loop design:

Up until now, at every turn, I had not properly been thinking about how the oplev loop plays into all of this. I went to the foton filters, and grabbed the loop and plant models for the ETMY oplev, and constructed the closed loop gain, 1/1+G, and the modified plant, P/1+G, which is what the ASC loop sees as its plant. 

Here, the purple trace explains all of the features I was confused about earlier. 

With this in hand, I set up to design a loop to satisfy our motivations. 

• Bounce/roll mode notches to avoid exciting them
• 1/f UGF crossing at a few Hz, limited by the gain margin at ~10Hz, which is where the phase will hit 180, due to the notches
• 4th order Elliptic lowpass at 100, to avoid contaminating the longnitudinal signals
• 1/f^2 at low frequencies for DC gain

To do this, I inverted the oplev closed loop plant pole around 4Hz to smooth the whole thing out. Here's a comparison of the measured OLG with what I modelled. 

There's a little bit of phase discrepency around 10Hz, but I think it looks about right overall. 

Evaluation:

So, here's the part that counts: How does this actually perform? I took spectra of the QPD error signals, the relevant OpLev signals as out of loop sensors, the PDH error signal and transmitted RIN while single arm locked, with this loop off, and on for all 4 DoFs simultaneously. 

Verdict:

• In-loop signals get small, unsurprisingly.
• Cavity signals unchanged. 
• ITM oplev signals are unchanged (and not plotted, to not clutter the plots (This isn't surprising since the loops mostly actuate on the ETMs).
• ETM oplev signals get smaller around the 3Hz peak, but are louder in other bands. 

This is what makes me think I may need to revisit the actuation matrix. If I did it wrong, I am driving the "invisible" quadrant of the cavity angular DoFs, and this could be what is injecting noise into the oplevs. 

Conclusion:

In the end, I have a better understanding of what is going on, and I don't think we're quite there yet.  

Although the QPD loops are less than ideal right now, I made changes to the ASC model to trigger the QPD loops on and off politely, depending on TRX and TRY. The settings are exposed on the ASC screen. However, I have not yet exposed the FM triggering that I also set up to make sure the integrator doesn't misbehave if the arm loses lock. We probably don't want to trigger them on at anything lower than arm powers of about 1.0. 

I've tested the triggering by randomly turning LSC mode on and off, and making sure that the optics don't recieve much of a kick as the QPD loops engage a few seconds after the LSC boosts do, or when lock is lost. This works as long as there isn't much of a DC offset befire the loops are engaged. (Under 20 counts or so is fine)

As a side note, I was going to use the TRIG_SIG signals sent via the LSC model via SHMEM blocks for the ASC triggering, but oddly, the data streams that made it over were actually the MICH and SRCL TRIG_SIGs, instead of XARM and YARM as labelled. I double checked the simulink diagrams; everything seemed fine to me. In any case, ASS was already recieving TRX and TRY directly via RFM, so I just piped those over to the ASC block. This way is probably better anyways, because it directly references the arm powers, instead of the less obvious LSC triggering matrix. 

Today I finished building the adding/subtracting circuit for the QPD and tested that the QPD could see a laser moving across its visual field for both pitch and yaw. It didn't seem to behave weirdly (saturate) at the edges, but I need to test this more carefully to be sure.

However, this circuit uses many op amps, which will cause problems for building the actual circuit to fit into the QPD box. I am trying to figure out how to do this with fewer op amps (both with a quad op amp for amplifying the signals from the QPD and by summing/subtracting the signals with a single op amp instead of 3).

I finally got around to asking Steve to order more breadboards! Trying to determine what would be a good QPD to order for the final circuit, since we do not have any unmounted QPDs that aren't ancient. I'll read up on things I don't know enough about (namely op amps).

Summary 

I have been working on setting up a QPD which can eventually be used to calibrate the PZT, and also orient the PZT in the mount such that the pitch and yaw axes roughly coincide with the vertical and horizontal.

The calibration constants have been determined to be:

X-axis: -3.69 V/mm

Y-axis: -3.70V/mm

Methodology:

I initially tried using the QPD setup left behind by Chloe near MC2, but this turned out to be dysfunctional. On opening out the QPD, I found that the internal circuitry had some issues (shorts in the wrong places etc.) Fortunately, Steve was able to hand me another working unit. For future reference, there are a bunch of old QPDs which I assume are functional in the cabinet marked 'Old PDs' along the Y-arm. 

I then made a circuit with which to read out the X and Y coordinates from the QPD. This consists of 4 buffer amplifiers (one for each quadrant), and 3 summing amplifiers (outputs are A+B+C+D = sum, B+C-A-D = Y-coordinate, and A+B-C-D = X-coordinate) that take the appropriate linear combinations of the 4 quadrants to output a voltage that may be calibrated against displacement of the QPD. 

The output from the QPD is via a sub-D connector on the side of the pomona box enclosing the PD and the circuitry, with 7 pins- 3 for power lines, and 4 for the 4 quadrants of the QPD. It was a little tricky to figure the pin-out for this connector, as there was no way to use continuity checking to map the pins to quadrants. Therefore, I used a laser pointer, and some trial and error (i.e. shine the light on a given quadrant, and check the sign of the X and Y voltages on an oscilloscope) to map the pin outs. Steve tells me that these QPDs were made long before colour code standardisation, but I note here the pin outs in any case for future reference (the quadrant orientations are w.r.t the QPD held with all the circuitry above it, with the active surface facing me):

Red= +Vcc

Black= -Vcc

Green = GND

Blue = Upper Left Quadrant

White = Upper Right Quadrant

Purple = Lower Left Quadrant

Grey = Lower Right Quadrant

Chloe had noted that there was some issue with the voltage regulators on her circuit (overheating) but I suspect this may have been due to the faulty internal circuitry. Also, she had used 12 V regulators. I checked the datasheet of the QPD, Op-Amp LF347 (inside the pomona box) and the OP27s on my circuit, and found that they all had absolute maximum ratings above 18V, so I used 15V voltage regulators. The overheating problem was not a problem anymore.

I then proceeded to arrange a set up for the calibration (initially on the optical bench next to MC2, but now relocated to the SP table, and a cart adjacent to it). It consists of the following:

• He-Ne laser source
• Y2 2-inch mirror (AR and HR coated for 532nm) glued onto the PZT and mounted on a machined Newport U100P  - see this elog for details.
• QPD mounted on a translational stage whose micrometers are calibrated in tenths of an inch (in the plots I have scaled this to mm)
• A neutral density filter (ND = 2.0) which I added so that the QPD amplifier output did not saturate. I considered using a lens as well to reduce the spot size on the QPD but found that after adding the ND filter, it was reasonably small.
• High-voltage power supply (on cart)
• Two SR power supplies (for the PZT driver board and my QPD amplifier
• SR function generator
• Laser power source
• Two oscilloscopes
• Breadboard holding my QPD amplifier circuit

Having set everything up and having done the coarse alignment using the mirror mount, I proceeded to calibrate the X and Y axes of the QPD using the translational stage. The steps I followed were:

• Centre spot on QPD using coarse adjustment on the mirror mount: I gauged this by monitoring the X and Y voltage outputs on an oscilloscope, and adjusted things till both these went to zero.
• Used the tilt knob on the translational stage to roughly decouple the X and Y motion of the QPD.
• Kept Y-coordinate fixed, took the X-coordinate to close to its maximum value (I gauged this by checking where the voltage stopped changing appreciably for changes in the QPD position.
• Using this as a starting point, I moved the QPD through its X range, noting voltage output of the X-coordinate (and also the Y) on an oscilloscope.
• Repeated the procedure for the Y-coordinate.
• Analysis follows largely what was done in these elogs. I am attaching the script I used to fit an error function to the datapoints, this is something MATLAB should seriously include in cftool (note that it is VERY sensitive to the initial guess. I had to do quite a bit of guessing).

The plots are attached, from which the calibration values cited above are deduced. The linear fits for the orthogonal axis were done using cftool. There is some residual coupling between the X and Y motions of the QPD, but I think this os okay my purposes. 

My next step would be to first tweak the orientation of the PZT in the mount while applying a small excitation to it in order to decouple the pitch and yaw motion as best as possible. Once this is done, I can go ahead and calibrate the angular motion of the PZT in mrad/V.

                                                            X-Axis                                                                                                                                Y-axis                                                

I finished working out the circuit and figured out where the broken connections were. This is diagrammed in my notebook (will draw up more nicely and include in future elog post). Within the QPD circuitry, it seems like there are already opamps which regulate the circuit. I need to discuss the final diagram further with Eric.

I rewired the circuit inside the QPD box, which took awhile because it was difficult to solder the wires to such small locations without having multiple wires touch. This is completed, and on Friday I will begin to make the circuit to add/subtract signals to give pitch and yaw.

I corrected the circuit diagram I constructed last time - it would read 0 output most of the time because I made a mistake with the op amps. This will be attached once I discuss it with Eric.

I searched the 40m lab and ended up finding a breadboard in the Bridge lab. I then spent awhile trying to remove the QPD from the circuit board it was on, which was difficult since it had 6 pins. After that, I soldered wires to the QPD legs and began constructing the circuit on the breadboard. I also spent time showing Annalisa the setup and explaining my project.

On Friday I will try and reconstruct all of the circuitry from before for the QPD.

In order to test the mount vibrations, I will likely try and make a different circuit work (with the summing/subtracting on an external breadboard) and designing an optimal circuit will be a side project. This is the circuit with the power supply Rana came up with, and the design I had in mind for the rest of the circuit. In my free time, I will try to figure out what parts to get that reduce noise and slowly work on building this, since it would be useful to have in the lab. 

 https://www.circuitlab.com/circuit/7sx995/qpd-circuit/#postsave_access_control_settings

I have sketched out the circuit design for the QPD. However, it seems like even when using a different opamp configuration, which I talked to Eric about on Friday, space will be a problem. It may be possible to squeeze everything onto a single circuit board to fit in the QPD box but what I think is more likely is that I will need to have 2 separate circuit boards both mounted within the box, one which integrates the signal from the QPD and the other which adds/subtracts (this involves many resistors which will take up a lot of space). I will continue to think about the best design for this.

I will try to have the circuit built in the next week or so, which may be difficult since I just started finals which will take most of my time. I spent most of this week writing up an ECDL proposal for a SURF with Tara. I'll make up for whatever work I miss since I'll be here for my spring break and doing little besides working in lab.

{Gautam, Yehonathan}

In search of the source of discrepancy between the QPD readings in the X and Y arms, we look into the schematics of the QPD amplifier - DCC #D990272.

We find that there are 4 gain switches with the following gain characteristics (The 40m QPD whitening board has an additional gain of 4.5):

Switch 4 bypasses the amps controlled by switch 2 and 3 when it is set to 1 so they don't matter in this state.

Note that according to elog-13965 the switches are controlled through the QPD whitening board by a XT1111a Acromag whose normal state is 1.

Also, according to the QPD amplifier schematics, the resistor on the transimpedance, controlled by switch 1, is 25kOhm. However, according to the EPICS it is actually 5kOhm. We verify this by shining the QPD with uniform light from a flashlight and switching switch1 on and off while measuring the voltages of the different segments. The schematics should be updated on the DCC.

Surprisingly, QPDX switches where 0,0,0,0 while QPDY switches where 1,0,0,1. This explains the difference in their responses.

We check by shining a laser pointer with a known power on the different segments of QPDX that we get the expected number of counts on the ADC and that the response of the different segments is equal.
 

gautam edits:

1. Lest there be confusion, the states of the switches in the (S1, S2, S3, S4) order are (0,0,0,0) for QPDX and (0,1,0,1) for QPDY.
2. The Acromag XT1111 is a sinking BIO unit - so when the EPICS channel is zero, the output impedance is low and the DUT (i.e. MAX333) is shorted to ground. So, the state of the MAX333 shown on the schematics corresponds to EPICS logic level 1, and the switched state corresponds to logic level 0.
3. For the laser pointer test, we used a red laser pointer. Using a power meter, we measured ~100uW of 632nm power. However, we think this particular laser pointer had failing batteries or something because the spot looked sometimes brighter/dimmer to the eye. Anyways, we saw ~10,000 ADC counts when illuminating a single segment (with the QPD gain switches at the 0,0,0,0 setting, before we changed anything). We expect 100uW * 0.4 A/W * 500 V/A * 10 * 40 * 4.5 * 3267.8 cts/V = ~12000 cts. So everything seems to check out. We changed the gain to the 5kohm setting and bypassed the subsequent gain stages, and saw the expected response too. The segments were only balanced to ~10%, but presumably this can be adjusted by tweaking digital gains.

Koji and I had noticed that there was some discrepancy between the switchable gain stages of the EX and EY QPDs. Sadly, there was no indication that these switches even exist on the QPD MEDM screen. Yehonathan and I rectified this today. Both EX and EY Transmon QPDs now have some extra info (see Attachment #1). We physically verified the indicated quadrant mapping for the EX QPD (see previous elog in this thread for the details), and I edited the screen accordingly. EY QPD still has to be checked. Note also that there is an ND=0.4 + ND=0.2 filter and some kind of 1064nm light filter installed in series on the EX QPD. The ND filters have a net transmission T~25%.

After making the EX and EY QPDs have the same switchable gain settings (I also reset the trans normalization gains), the angular motion witnessed is much more consistent between the two now - see Attachment #2. The high-frequency noise of the sum channel is somewhat higher for EX than EY - maybe the ND filters are different on the two ends?

Note that there was an extra factor of 40 gain on the EX QPD relative to EY during the lock yesterday. So really, the signals were probably just getting saturated. Now that the gains are consistent between the ends, it'll be interesting to see how balanced the buildup of the two arms is. There still remains the problem that the MICH loop was too unstable, which probably led to to excess arm power fluctuations.

There is a mark on the QPD surface that is probably dirt (since we never have such high power transmitted through the ETM to damage the QPD). I'll try cleaning it up at the next opportunity.

Friday night myself and Koji measured the Transfer function of the QPD circuit at MC2 side using a chopper . Following was our procedure :

We connected some wires at the input and output of the filter circuit to one of the segment of teh QPD. - seg 1.

A laser light was shined on to the QPD, it was pulsed using a chopper. The frequency of rotation of the chopper was varied.

These wires were then fed to the spectum analyser , and a transfer funstion was observed, It was nearly a low pass filter

The chopper frequency was then made variable by giving the chopper a signal from the spectrum analyser. This signal just swiped a large range of the rpm of the chopper.

Now the input signal looked like a sine wave of varying frequency. the transfer function looked like a perfect LPF, with a small SNR.

Attaching the plot of the TF in the next e-log (this one is on windows and can't access /cvs/cds)

The voltage regulator on the QPD breadboard seems to be having problems... yesterday Eric helped me debug my circuit and discovered that the +12V regulator was overheating, so we replaced it. Today, I found that the -12V regulator was also doing the same thing, so I replaced it. However, it's still overheating. We checked all of the setup for the power regulators yesterday, so I'm not sure what's wrong.

I've also noticed that not all the connections on the breadboard that I've been using seem to work - I may search for a new breadboard in this case. Need to check I'm not doing something stupid with that.

Breadboards may not be suitable for a reliable work. Why don't you switch to any protoboard and real soldering?

[ Yuki, Gautam, Steve ]

Results:
I calibrated a QPD (D1600079, V1009) and made sure it performes well. The calibration constants are as follows:

X-Axis: 584 mV/mm
Y-Axis: 588 mV/mm

Details:
The calibration of QPD is needed to calibrate steeing PZT mirrors. It was measured by moving QPD on a translation stage. The QPD was connected to its amplifier (D1700110-v1) and +-18V was supplied from DC power supplier. The amplifier has three output ports; Pitch, Yaw, and Sum. I did the calibration as follows:

• Center beam spot on QPD using steering mirror, which was confirmed by monitored Pitch and Yaw signals that were around zero.  
• Kept Y-axis micrometer fixed, moved X-axis micrometer and measured the outputs. 
• Repeated the procedure for the Y-axis. 

The results are attached. The main signal was fitted with error function and I drawed a slope at zero crossing point, which is calibration factor. I determined the linear range of the QPD to be when the output was in range -50V to 50V, then corresponding displacement range is about 0.2 mm width. Using this result, the PZT mirrors will be calibrated in linear range of the QPD tomorrow. 

Comments:

• Some X-Y coupling existed. When one axis micrometer was moved, a little signal of the other direction was also generated.
• As Gautam proposed in the previous study, there is some hysteresis. That process would bring some errors to this result.
• A scale of micrometer is expressed in INCH!
• The micrometer I used was made to have 1/2 inch range, but it didn't work well and the range of X-axis was much narrower. 

Reference:
previous experiment by Gautam for X-arm: elog:40m/8873, elog:40m/8884

• The SUM output was from -174 to -127 mV.
• The beam radii calculated from the error func fittings was 0.47 mm.
• Total optical path length measured by a ruler= 36 cm.
• Beam power measured at QPD was 2.96 mW. (There are some loss mechanism in the setup.)

Then the calibration factor of the QPD is

X axis: 584 * (POWER / 2.96mW) * (0.472mm /  RADIUS) [mV/mm]
Y axis: 588 * (POWER / 2.96mW) * (0.472mm /  RADIUS) [mV/mm].

Today I tested the circuitry within the QPD to make sure I had put it back together correctly. The output was able to detect when a laser pointer was shone on different quadrants of the QPD when hooked up to the oscilloscope, so fixing the QPD worked! 

Following this, I spent awhile understanding what was going on with the circuit reading from the QPD. I concluded that the opamp on the QPD circuit acted as a low pass filter, with corner frequency of about 17 kHz, which serves our purposes (we are only interested in frequencies below 1 kHz). I diagrammed the circuit that I plan to build to give pitch and yaw (attached). It will be necessary to make small modifications to the circuitry already built (removing some resistors), which I have started on. 

Next time, I will construct the circuit that adds/subtracts signals on a breadboard and test it with the QPD circuit that is already built. 

 I took better pictures of the circuits of the QPD and spent a couple of hours with a multimeter trying to figure out how all the connections worked. I will continue to do so and analyze the circuits over the weekend to try to understand what is going on. I also have an old SURF report that Eric sent me that is similar to the design I was planning to use to sum the pitch and yaw signals. I will try and look at this over the weekend. 

 I spent awhile today reading about op-amps and understanding what would be necessary to design a circuit which would directly give pitch and yaw of the QPD I am using. After getting an idea of what signals would be summed or subtracted, I opened up the QPD to take better pictures than last time (sorry, the pictures were blurry last time and I didn't realize). It turns out some of the connections have been broken inside the QPD, which would explain why we saw an unchanging signal in Ch2 on the oscilloscope yesterday when trying to test the laser setup. 

I found a couple other QPDs, which I will be using to help understand the circuit (and what is going on). I will be trying to use the same QPD box since it has banana cable and BNC cable adapters, which is helpful to have in the lab. Once I have concluded what the circuitry is like and designed electronics to add and subtract signals, I will build and mount all the circuits within the box (more sturdily than last time) so as to have a quality way of measuring the mount vibrations when I get there.