40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 81 of 336 Not logged in
ID Date Author Type Category Subject
11535   Fri Aug 28 00:59:55 2015 IgnacioUpdateIOOFinal SISO FF Wiener Filter for MCL

This is my final SISO Wiener filter for MCL that uses the T240-X seismo as its witness.

The main difference between this filter and the one on elog:11532 is the actual 1/f rolloff this filter pocesses. My last filter had a pair of complex zeroes at 2kHz, that gave the filter some unusual behavior at high frequencies, thanks Vectfit. This filter has 10 poles and 8 zeroes, something Vectfit doesn't allow for and needs to be done manually.

The nice thing about this filter is the fact that Eric and I turned this filter on during his 40 min PRFPMI lock last night, Spectra for this is coming soon.

This filter lives on the static Wiener path on the OAF machine, MCL to MC2, filter bank 7.

Anyways, the usual plots are shown below.

Filter:

T240-X (SISO)

Training data + Predicted FIR and IIR subtraction:

Online subtraction results:(High freq. stuff shown for noise injection evaluation of the filter)

MCL

YARM

Subtraction performace:

14764   Tue Jul 16 15:17:57 2019 KojiHowToCDSFinal bit bug of the BIO CDS module

Yutaro talked about the BIO bug in KAGRA elog. http://klog.icrr.u-tokyo.ac.jp/osl/?r=9536

I think I made the similar change for the 40m model somewhere (don't remember), but be aware of the presense of this bug.

14890   Tue Sep 17 14:43:59 2019 gautamHowToCDSFinal bit bug of the BIO CDS module

Came across this while looking up the BIO situation at 1Y2. For reference, the fix Koji mentions can be seen in the attached screenshot (one example, the other BIO cards also have a similar fix). The 16th bit of the BIO is grounded, and some bit-shifting magic is used to implement the desired output.

 Quote: Yutaro talked about the BIO bug in KAGRA elog. http://klog.icrr.u-tokyo.ac.jp/osl/?r=9536 I think I made the similar change for the 40m model somewhere (don't remember), but be aware of the presense of this bug.
Attachment 1: Screen_Shot_2019-09-17_at_2.44.41_PM.png
14941   Fri Oct 4 22:22:03 2019 gautamUpdateCDSFinal incarnation of latch.py

[KA, GV]

This elog is meant to be a summary of some of the many subtleties on the CM board. The latest schematic of the version used at the 40m can be found at D1500308 .

Latch logic:

• There are several Binary Outputs and one Binary Input to the CM board.
• The outputs control ENABLE/DISABLE switches and gains of amplifier stages, while the input reports whenever the limiter has been reached.
• The variable gain feature is implemented by enabling/bypassing several cascaded fixed gain stages. So in order to change the gain of a single composite amplifier stage, multiple individual amplifier stages have to be switched.
• This is implemented by the user interacting with the hardware via a "control word", consisting of a number of bits depending on the number of cascaded stages that have to be switched.
• This control word is sent to the device via modbus EPICS, which is an asynchronous communication protocol. Hence, it may be that the individual bits composing the control word get switched asynchronously. This would be disastrous, as there can be transient glitches in the gain of the stage being controlled.
• To protect against such problems, there is a latch IC in the hardware between the Binary Inputs to the board (= Binary Outputs from Acromags), and the actual switches (= MAX333) that enable/bypass the cascaded gain stages. The latch IC used is a SN74ALS573. This device acts as a bus, which transmits/blocks changes for multiple bits (= our control word) from propagating, depending on the state of a single bit (= the LATCH ENABLE bit). Thus, by controlling a single bit, we can guarantee that multiple bits get switched synchronously
• In order to use this latch capability, we need some software logic that sets/disables the LATCH ENABLE bit. For our system, this logic is implemented in the form of a continuously running python 🐍 script, located at /cvs/cds/caltech/target/c1iscaux/latch.py. It is implemented as a systemctl service on the c1iscaux Supermicro. The logic implemented in this script is shown in Attachment #1. While the channels referred to in that attachment are for REFL1_GAIN, the same logic is implemented for REFL2_GAIN, AO_GAIN, and the SuperBoosts.
• Some FAQ:
1. Q: Why do we need the soft channels C1:LSC-REFL1_SET_LSB and C1:LSC-REFL1_SET_MSB?
A: These soft channels are what is physically linked to the Acromag Binary Outputs. In order for our latch logic to be effective, we need to detect when the user asks for a change, and then disable the LATCH ENABLE bit (which is on by default, see FAQ #3) before changing the physical acromag channels. The soft channels form the protective layer between the user and the hardware, allowing latch.py to function.
2. Q: Why is there an "_MSB" and "_LSB" soft channel?
A: This has to do with the mbboDirect EPICS channel type, which is used to control the multiple bits in our control word using a single input (= an MEDM gain slider). The mbboDirect data-type requires the bits it controls to have consecutive hardware addresses. However, the Acromag hardware addressing scheme is not always compatible with this requirement (see pg 33 of the manual for why this is the case). Hence, we have to artifically break up the control word into two separate control words compatible with the Acromag addressing scheme. This functionality is implemented in latch.py.
3. Q: Why is the default state of LATCH ENABLE set to ON?
A: This has to do with the fact that all Binary Inputs, not just the multi-bit ones, to the CM board are propagated to the control hardware via a latch IC. For the single-bit channels, there is no requirement that the switching be synchronous. Hence, rather than setting up ~10 more single-bit soft channels and detecting changes before propagating them, we decided to leave the LATCH ENABLE ON by default, and only disable it when changing the multi-bit gain channels. This is the same way the logic was implemented in the VME state code, and we think that there are no logic reasons why it would fail. But if someone comes up with something, we can change the logic.

Acromag BIO testing:

During my bench testing of the Acromag chassis, I had not yet figured out mbboDirect and the latch logic, so I did not fully verify the channel mapping (= wiring inside the Acromag box), and whether the sitching behavior was consistent with what we expect. Koji and I verified (using the LED tester breakout board) that all the channels have the expected behavior 👏. Note that this is only a certification at the front-panel DB37 connectors of the Acromag chassis  testing of the integrated electronics chain including the CM board is in progress...

Attachment 1: LatchLogic.pdf
14947   Tue Oct 8 03:19:14 2019 KojiUpdateCDSFinal incarnation of latch.py

Now with the CM board tested with the signal injected, it turned out that the latch logic was flipped. As the default state locked the digital levels, the buttons other than the mbbo channels were inactive.

By giving 0 to C1:LSC-CM_LATCH_ENABLE, the modification of the digital state is enabled. And with the value of 1, the digital bits on the board is locked.

In order to reflect this, latch.py was modified and now the controls are all activated.

941   Thu Sep 11 11:29:14 2008 josephbConfigurationComputersFinal netgear switch in place in 1Y2
I've placed the final (of 4) Netgear prosafe 24 port switch at the very top of 1Y2. At that location, there are no holes left to screw into, so it has 4 rubber feet and is sitting on the top most signal generator. It has been plugged in and connected to the control room hub with a labeled cat6 ethernet cable.

Its IP address has been set to 131.215.113.253, and has the usual controls password if using the "Smart Wizard Discovery Tool" which comes on the Netgear CD. The CD can be found in the Equipment manuals filing cabinet under Netgear. This program unfortunately only runs on a window PC.

To Do: Fix the C1:ASC ethernet connection which is currently coming straight out the front door and connected to the 1X4 switch (again through the front door).
8961   Fri Aug 2 21:59:36 2013 CharlesUpdateISSFinalized ISS Schematic (hopefully)

Attached is the finalized schematic. The general circuit topology should remain the same from this point forward, although individual component values are subject to change. I will also be adding some more annotations to ensure everything on the board is clear.

In general, I have finally included all of the correct components (i.e. front panel switches are now actually switches and front panel LEDs are now included). I also added an external 'Boost' switch, which can be used to enable or disable the boosts. The motivation for including this switch is that one might want to test functionality of the ISS without using the 'fancy' RMS detection and triggering circuitry. Additionally, one can disable the boosts when all the circuitry is stuffed in order to troubleshoot, so it essentially grants the board some flexibility in its operation.

I am now working on the PCB layout and I should hopefully have that done next week.

Attachment 1: ISS_v3.pdf
Attachment 2: ISS_v3-Power_Reg.pdf
2983   Tue May 25 16:40:27 2010 josephb, alexUpdateCDSFinally tracked down why new models wouldn't talk to each other

The problem with the new models using the new shared memory/dolphin/RFM defined as names in a single .ipc file.

The first is the no_oversampling flag should not be used.  Since we have a single IO processor handling ADCs and DACs at 64k, while the models run at 16k, there is some oversampling occuring.  This was causing problems syncing between the models and the IOP.

It also didn't help I had a typo in two channels which I happened to use as a test case to confirm they were talking.  However, that has been fixed.

8322   Thu Mar 21 09:53:46 2013 AnnalisaUpdateLockingFinding the beat note

Yesterday I tried to find the beat note between the main PSL and the auxiliary NPRO, but I didn't :(

Today I will do a better alignment of the two beams in the PD and try again.

8323   Thu Mar 21 10:19:28 2013 KojiUpdateLockingFinding the beat note

What PD are you using? How much power the beams on the recombining BS are? What kind of BS is it?
How are you looking for the beat note? (on the scope? or spectrum analyzer?)
What was the scanned temp range?

Three points to be checked:

- Polarization

- Alignment

- Temperature

8327   Thu Mar 21 13:11:42 2013 AnnalisaUpdateLockingFinding the beat note

 Quote: Give us more info on the elog: What PD are you using? How much power the beams on the recombining BS are? What kind of BS is it? How are you looking for the beat note? (on the scope? or spectrum analyzer?) What was the scanned temp range? Three points to be checked: - Polarization - Alignment - Temperature

## Experimental Setup

I'm using a 1611 New Focus PD (1 GHZ, with maximum input power 1mW), and the total power hitting on the PD is of about 0.650 mW.

The current of the NPRO laser is set to 1.38 A, so that the input power is 19 mW. The beam is initially damped by a 10% reflection BS and then it hits a 33% reflection BS (where it recombines with the PSL pick-off beam) with 2 mW power.

After this second BS the power is reduced to 0.592 mW.

The PSL pick-off hits on the 33% reflection BS with 65.5 uW power, and it exit with a 47 uW power.

I connected a power supply to apply a Voltage to the slow frequency BNC, in way to tune the laser frequency.

I'm using the AGILENT 4395A Spectrum analyzer to make the measurement. I tried to use the HEWELETT PACKARD 8591E spectrum analyzer, but the monitor didn't turn on.

The temperature spanned until now in only of about 10 deg C, because I realized that I needed a better alignment, so I added a lens in front of the PD and I did a better alignment.

Moreover, the current of the laser is too low, so I need to increase it and add more beam splitters in the beam path to dump the beam, in way to don't reach the PD threshold.

I knew that both the beams are s-polarized, but maybe I can check it again.

Attachment 1: Beat_note_setup.jpg
541   Wed Jun 18 18:26:19 2008 YoichiUpdatePSLFinding the optimal operation temperature for the NPRO by the slow act scan
Being suspicious of the temperature stabilization of the NPRO crystal, I ran the slow scan script written by Rana to find the suitable operation temperature.
The procedure is the same as the one explained in the entry below:
The attached plots show the results. By looking at C1:PSL-126MOPA_126MON, I set the slow slider voltage to 0.
This time, it looks like the temperature control of the NPRO crystal is working fine.
Obviously, PMC picks up many higher order modes. I will try to mode match/align the PMC later.
Attachment 1: FSS-slow-scan.pdf
7953   Tue Jan 29 14:20:02 2013 KojiUpdateGeneralFiner rotation stage for optics characterization

A rotation stage has been ordered.

 Newport Rotation Stage, 360° Coarse, 5° Fine Rotation, Micrometer Newport 481-A Newport Solid Insert for RSP-1T Rotation Stage Newport RSA-1TI Newport Universal Mounting Plate, 2.56 in. x 2.56 in. x 0.5 in., 1/4-20 Thread Newport UP-1A

Specification: Newport 481-A

• Sensitivity: 15 arcsec
• Vernier: 5 arcmin
• Fine travel range: 5 deg
• With Micrometer
15618   Thu Oct 8 08:37:15 2020 gautamUpdateComputer Scripts / ProgramsFinesse GUI

This looks cool, we should have something similar, can be really useful.

15621   Thu Oct 8 18:40:42 2020 KojiUpdateComputer Scripts / ProgramsFinesse GUI

Is it better than Luxor? https://labcit.ligo.caltech.edu/~jharms/luxor.html

14057   Thu Jul 12 14:06:39 2018 keerthanaUpdateelogFinesse and Analytical solution - Comparison

I tried to compare the cavity scan data we get from the Finesse simulation and that we expect from the Analytical solution. The diagram of the cavity I defined in Finesse is given below along with the values of different quantities I used. For the analytical solution I have used two different equations and they are listed below.

Analytical 1 - Blue Graph

$\phi = \frac {2.L.\Omega_1}{c}$

$t_{cav} = \frac{t_e. t_f \exp^{-i\frac{\phi}{2}}}{1- r_f. r_e \exp^{-i\phi} }$

$T_{cav} = \left|{t_{cav}} \right|^2$

Analytical 2 - Red Graph

$F = \frac {4. r_f.r_e}{(1-r_f.r_e )^2}$

$\phi = \frac {2.L.\Omega_1}{c}$

$T_{cav} = \left|{t_{cav}} \right|^2 = \frac {(t_e.t_f)^2}{(1 - r_f . r_e)^2} \frac{1}{1+F(\sin\frac {\phi}{2})^2}$

The graph obtained from both these solutions completely matches with each other.

Finesse Solution

The cavity which I defined in Finesse is shown below. The solution from Finesse and the Analytical solution also matches with each other. Another plot is made by taking the difference between Finesse solution and Analytical solution. The difference seems to be of the order of $\approx 10^{-19}$.

The Difference plot is also attached below.

Attachment 1: finesse_cavity.png
Attachment 2: Analytical1.pdf
Attachment 3: Finesse_Analytical.pdf
Attachment 4: Difference.pdf
13915   Mon Jun 4 19:41:01 2018 keerthanaUpdate Finesse code for cavity scan

The cavity scan data obtained from the Finesse simulation is attached here. Fig1 indicates the cavity scan data in the absence of induced misalignment. In that case only the fundemental mode is resonating. But when a misalignment is induced, higher order modes are also present as seen in Fig2. This is in the absence of surface figure error in the mirrors. Now I am trying to provide perturbations to the mirror surface in the form of zernike polynomials and get the scan data fom the simulation. These cavity scan data can be used to develop fitting models. Once we have a model, we can use it to analyse the data from the experimental cavity scan.

Attachment 1: Fig1.png
Attachment 2: Fig2.png
13956   Wed Jun 13 18:08:36 2018 keerthanaUpdate Finesse code for cavity scan

The unit mentioned in the x-axis was wrong. So I have remade the graphs. The point where frequency equals to zero is actually the frequency corresponding to the laser, which is in the range of 1014 Hz and it caliberated as zero.

 Quote: The cavity scan data obtained from the Finesse simulation is attached here. Fig1 indicates the cavity scan data in the absence of induced misalignment. In that case only the fundemental mode is resonating. But when a misalignment is induced, higher order modes are also present as seen in Fig2. This is in the absence of surface figure error in the mirrors. Now I am trying to provide perturbations to the mirror surface in the form of zernike polynomials and get the scan data fom the simulation. These cavity scan data can be used to develop fitting models. Once we have a model, we can use it to analyse the data from the experimental cavity scan.
Attachment 1: finesse1.pdf
Attachment 2: finesse2.pdf
12120   Wed May 18 01:10:22 2016 gautamUpdateCOCFinesse modelling

I've been working on putting together a Finesse model for the current 40m configuration. The idea was to see if I could reproduce a model that is in agreement with what we have been seeing during the recent DRFPMI locks. With Antonio and EricQs help, I've been making slow progress in my forays into Finesse and pyKat. Here is a summary of what I have so far.

• Arm lengths were taken from some recent measurements done by yutaro and me
• Recycling cavity lengths were taken from Gabriele's elog 9590 - it is likely that the lengths I used have errors ~1cm - more on this later. Furthermore, I've tried to incorporate the flipped RC folding mirrors - the point being to see if I can recover, for example, a power recycling gain of ~7 which is what was observed for the recent DRFPMI locks.
• I used Yutaro's most recent arm loss numbers, and distributed it equally between ITM and ETM for modeling purposes.
• For all other optics, I assumed a generic loss number of 25ppm for each surface

Having put together the .kat file (code attached, but this is probably useless, the new model with RC folding mirrors the right way will be what is relevant), I was able to recover a power recycling gain of ~7.5. The arm transmission at full lock also matches the expected value (125*80uW ~ 10mW) based on a recent measurement I did while putting the X endtable together. I also tuned the arm losses to see (qualitatively) that the power recycling gain tracked this curve by Yutaro. EricQ suggested I do a few more checks:

1. Set PRM reflectivity to 0, scan ETMs and look at the transmission - attachment #1 suggests the linewidth is as we expect
2. Set ETM reflectivity to 0, scan PRM - attachment #2 suggests a Finesse of ~60  for the PRC which sounds about right
3. Set ETM reflectivity to 0, scan SRM and verify that only the 55 MHz sidebands resonate - Attachment #3

Conclusion: It doesn't look like I've done anything crazy. So unless anyone thinks there are any further checks I should do on this "toy" model, I will start putting together the "correct" model - using RC folding mirrors that are oriented the right way, and using the "ideal" RC cavity lengths as detailed on this wiki page. The plan of action then is

• Evaluating the mode-matching integrals between the PRC and the arm cavities as a function of the radius of curvature of PR2 and PR3
• Same as above for the SRC
• PRC gain as a function of RoC of folding mirrors
• Mode overlap between the modes from the two arm cavities as a function of the RoC of the two ETMs (actually I guess we can fix RoC of ETMy and just vary RoC of ETMx).

Sidenote to self: It would be nice to consolidate the most recent cavity length measurements in one place sometime...

Attachment 1: arms.pdf
Attachment 2: PRC.pdf
Attachment 3: SRC.pdf
Attachment 4: Finesse_model.zip
12130   Tue May 24 22:49:02 2016 gautamUpdateCOCFinesse modelling - mode overlap scans

Summary:

Having played around with a toy finesse model, I went about setting up a model in which the RC folding mirrors are not flipped. I then repeated the low-level tests detailed in the earlier elog, after which I ran a few spatial mode overlap analyses, the results of which are presented here. It remains to do a stability analysis.

Overview of model parameters (more details to follow):

• PRC length = 6.7727m (chosen using $\dpi{80} l_{PRC} = (N+\frac{1}{2})\frac{c}{2f_1}$, N=0 - I adjusted the position of the PRM to realize this length in the model, while leaving all the other vertex optics in the same positions as in elog 9590
• SRC length = 5.4182 (chosen using $\dpi{80} l_{SRC} = M\frac{c}{2f_2}$ but not $\dpi{80} l_{SRC} = N\frac{c}{2f_1}$, M and N being integers, for M=2 - as above, I adjusted the position of the SRM to realize this in the model, while leaving all other vertex optics in the same positions as in elog 9590. It remains to be verified if it is physically possible to realize these dimensions in vacuum without any beam clipping etc but I think it should be possible seeing as the PRM and SRM had to be moved by less than 2cm from their current positions..
• For the losses, I used the most recent numbers we have where applicable, and put in generic 25ppm loss for all the folding mirrors/BS/AR surfaces of arm cavity mirrors/PRM/SRM. Arm round trip loss was equally distributed between ITMs and ETMs
• Arm lengths used: L_X = 37.79m, L_Y = 37.81m
• To set the "tunings" of the various mirrors, I played around with a few configurations to see where the various fields resonated - it turns out that for PRM, ITMX, ITMY, ETMX and ETMY, the "phase" in the .kat file can be set as 0. while that for the SRM can be set as 90. In the full L1/H1 interferometer .kat files, these are tuned even further to the (tenth?!) decimal place, but I think these values suffice for out purposes.

Results (general note: positive RoC in these plots mean a concave surface as seen by the beam):

• Attachments #1, #2 and #3 reproduce the low-level tests performed earlier for this updated model - i.e. I look at the arm transmission with no PRM/SRM, circulating PRC power with no ETMs, and circulating SRC power with no ETMs. Everything looks consistent here... In Attachment #2, there is no legend, but the (almost overlapping) red and green lines are meant to denote the +f1 and +f2 sidebands.
• Attachments #4 and #5 are a summary of the mode-overlap scans for the PRC and SRC. What I did was to vary the radius of curvature of the RC mirrors (finesse only allows you to vary Rcx and Rcy, so I varied both simultaneously) and calculate the mode overlap between the appropriate pairs of cavities (e.g. PRX and XARM) in the tangential and saggital planes. The take-away here is that there is ~5% mode-mismatch going from an RoC of 1000m to 300m. I've also indicated the sag corresponding to a given RoC - these are pretty tiny, I wonder if it is possible to realize a sag of 1um? I suppose it is given that I've regularly seen specs of surface roughness of lambda/10?
• Attachment #6 shows the PRC gain (calculated as T_PRC * (transmitted arm power with PRM / transmitted arm power without PRM) as a function of the RoC of PR2 and PR3. As a sanity check, I repeated this calculation with lossless HR surfaces (but with nominal 25ppm losses for AR surfaces of ITMs, and BS etc), shown in Attachment #7. I think these make sense too...
• Attachment #8 - in order to investigate possible mode mismatch between the arm modes due to different radii of curvature of the ETMs, I kept the ETMY RoC fixed at 57.6m and varied the ETMY RoC between 50m and 70m (here, I've plotted the mode matching efficiency as a function of the RoC of the ETM in the X and Y directions separately - the mode overlap is computed as $\dpi{80} \frac{1}{\sqrt{2}}(x^2 + y^2)$ where x and y denote the overlap in the tangential and saggital planes respectively. It would seem that we only lose at most a couple of percent even if the RoCs are mismatched by up to 10m...
• Attachment #9 - .kat file and the various pykat scripts used to generate these plots...

Next step is to carry out a stability analysis...

Attachment 1: armTransmission.pdf
Attachment 2: prcFSR.pdf
Attachment 3: srcTransmission.pdf
Attachment 4: modeMatchPRX.pdf
Attachment 5: modeMatchSRX.pdf
Attachment 6: PRCgainScan.pdf
Attachment 7: PRCgainLossless.pdf
Attachment 8: armModeMatchScan.pdf
Attachment 9: Finesse_files.zip
12131   Tue May 24 23:17:37 2016 ericqUpdateCOCFinesse modelling - mode overlap scans

I think you should use the current actual PRC & SRC cavity lengths as measured, as it would be simplest to simply replace the folding mirror optics without changing the macroscopic lengths / optic positions. (EDIT: Gautam rightly points out that we have to move things around regardless, since our current lengths include propagation through the folding mirror subtrates)

Moreover, the recycling cavity lengths you posted are not the right "ideal" lengths to use, as they do not account for the complex reflectivities of the sidebands off of the arm cavities (I have made this mistake myself). See this 40m wiki page for details.

In short, given our current modulation frequency, the ideal lengths to use would be:

• Ideal arm length of 37.795 m
• Ideal PRC length of 6.753 m
• Ideal SRC length of 5.399 m

These are the lengths that the recycling cavity optics were positioned for (though we did not achieve them perfectly). If you do a finer PRC/SRC length scan around the DRFPMI resonance of your model, you would presumably see some undesired sideband splitting.

2903   Mon May 10 17:47:16 2010 josephbSummaryCDSFinished

So I finished writing a script which takes an .ipc file (the one which defines channel names and numbers for use with the RCG code generator),  parses it, checks for duplicate channel names and ipcNums, and then parses and .mdl file looking for channel names, and outputs a new .ipc file with all the new channels added (without modifying existing channels).

The script is written in python, and for the moment can be found in /home/controls/advLigoRTS/src/epics/simLink/parse_mdl.py

I still need to add all the nice command line interface stuff, but the basic core works.   And already found an error in my previous .ipc file, where I used the channel number 21 twice, apparently.

Right now its hard coded to read in C1.ipc and spy.mdl, and outputs to H1.ipc, but I should have that fixed tonight.

2908   Mon May 10 20:33:29 2010 KojiSummaryCDSFinished

This IPC stuff looks really a nice improvement of CDS.

Please just maintain the wiki updated so that we can keep the latest procedures and scripts to build the models.

 Quote: So I finished writing a script which takes an .ipc file (the one which defines channel names and numbers for use with the RCG code generator),  parses it, checks for duplicate channel names and ipcNums, and then parses and .mdl file looking for channel names, and outputs a new .ipc file with all the new channels added (without modifying existing channels).  The script is written in python, and for the moment can be found in /home/controls/advLigoRTS/src/epics/simLink/parse_mdl.py I still need to add all the nice command line interface stuff, but the basic core works.   And already found an error in my previous .ipc file, where I used the channel number 21 twice, apparently. Right now its hard coded to read in C1.ipc and spy.mdl, and outputs to H1.ipc, but I should have that fixed tonight.

16499   Fri Dec 10 15:59:23 2021 PacoUpdateBHDFinished Coil driver (even serial number) units tests

[Paco, Anchal]

We have completed modifications and testing of the HAM Coil driver D1100687 units with serial numbers listed below. The DCC tree reflects these changes and tests (Run/Acq modes transfer functions).

 SERIAL # TEST result S2100608 PASS S2100610 PASS S2100612 PASS S2100614 PASS S2100616 PASS S2100618 PASS S2100620 PASS S2100622 PASS S2100624 PASS S2100626 PASS S2100628 PASS S2100630 PASS S2100632 PASS S2101648** FAIL (Ch1, Ch3 run mode) S2101650** FAIL (Ch3 run mode) S2101652** PASS S2101654** PASS

** A fix had to be done on the DC power supply for these. The units' regulated power boards were not connected to the raw DC power, so the cabling had to be modified accordingly (see Attachment #1)

Attachment 1: dc_fail.jpg
16514   Thu Dec 16 15:32:59 2021 AnchalUpdateBHDFinished Coil driver (odd serial number) units tests

We have completed modifications and testing of the HAM Coil driver D1100687 units with serial numbers listed below. The DCC tree reflects these changes and tests (Run/Acq modes transfer functions).

 SERIAL # TEST result S2100609 PASS S2100611 PASS S2100613 PASS S2100615 PASS S2100617 PASS S2100619 FAIL (CH2 phase) S2100621 PASS S2100623 PASS S2100625 PASS S2100627 PASS S2100629 PASS S2100631 PASS S2100633 Waiting for more components S2101649** PASS S2101651** PASS S2101653** PASS S2101655** PASS

** A fix had to be done on the DC power supply for these. The units' regulated power boards were not connected to the raw DC power, so the cabling had to be modified accordingly.

Further, Paco fixed the two even serial number units (S2101648, S211650) that failed the test. The issues were minor soldering mistakes that were easily resolved.

16517   Thu Dec 16 17:57:17 2021 AnchalUpdateBHDFinished Coil driver (odd serial number) units tests

S2100619 was fixed by Koji and it passed the test after that.

Quote:
 SERIAL # S2100619 FAIL (CH2 phase)

12329   Mon Jul 25 10:54:55 2016 PrafulUpdateComputer Scripts / ProgramsFinished MEDM Tab on Summary Pages

The MEDM screen capture tab is now working and up on the summary pages: https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160725/medm/

Please let me know if you have any suggestions or notice any issues.

12330   Mon Jul 25 12:22:18 2016 ranaUpdateComputer Scripts / ProgramsFinished MEDM Tab on Summary Pages

Looks pretty great. However, there's two problems:

1) Some of the MEDM screens don't show the time. You can fix this by editing the screens and copy/paste from screens which have working screens.

2) The snapshot script seems to not grab the full MEDM screen sometimes.

These are not a very big deal, so you can get the microphones working first and we can take care of this afterwards.

12439   Wed Aug 24 23:47:30 2016 PrafulUpdateElectronicsFinished Prototype Box

Gautam helped me drill holes in a metal box and I set up my circuit inside. Everything seems to be working so far. Tomorrow I'll be suspending the box near the PSL and setting up a data channel. Attached are some pictures of the box- sorry some of the angles turned out weird.

Attachment 1: out1.pdf
Attachment 2: out2.pdf
Attachment 3: out3.pdf
Attachment 4: in1.pdf
Attachment 5: in2.pdf
3116   Thu Jun 24 16:59:24 2010 josephbUpdateVACFinished restoring the access connector and door

[Jenne,  Kiwamu, Steve, Sharmila, Katherine, Joe]

We finished bolting the door on the new ITMX (old ITMY) and putting the access connector section back into place.  We finished with torquing all the bolts to 40 foot-pounds.

2597   Fri Feb 12 13:56:16 2010 josephbUpdateComputersFinishing touches on IP switch over

The GPIB interfaces have been updated to the new 192.168.113.xxx addresses, with Alberto's help.

Spare ethernet cables have been moved into a cabinet halfway down the x-arm.

The illuminators have a white V error on the alarm handler, but I'm not sure why.  I can turn them on and off using the video screen controls (except for the x arm, which has no computer control, just walk out and turn it on).

There's a laptop or two I haven't tracked down yet, but that should be it on IPs.

At some point, a find and replace on 131.215.xxx.yyy addresses to 192.168.xxx.yyy should be done on the wiki.  I also need to generate an up to date ethernet IP spreadsheet and post it to the wiki.

4056   Wed Dec 15 12:46:18 2010 KojiSummaryIOOFinishing up the vac work

What else?

v: Edit on Dec 15 10PM v: Edit on Dec 16 10PM 

JD:  We should check OSEMs for all optics *after* table leveling.  Some of them (esp. BS and ITMX) are currently close to their limits right now.

KA: Check green alignment.

Take photos of the tables.

Fix the leveling weights

 Location    Optics            Action -------------------------------------------------------------- @ITMX -     v POX             alignment             v POP1/POP2       alignment             v Table Leveling

@ITMY -     POY               mirror replacement (45deg->0deg) / alignment             v SR2-TT          alignment             v SRM Tower       alignment / EQ-stop release             v SRM             alignment             v SRM OSEM             vvSRM OPLEV (X2)  install (VIS)/ alignment             v ITMY OPLEV (X2)   install (VIS)/ alignment             v OM1/OM2         install (DLC 45deg)/ alignment                    v Table Leveling

@BSC -      v OM3             install (DLC 45deg/ alignment)             v OM4(PZT)          neutralize, adjustment             IPPOS steering    alignment             v BS OPLEV        alignment             v PRM OPLEV(x2)     alignment             Beam dumps             Table Leveling

@IMC -      v REFL              mirror replacement　(45deg->0deg)

@ETMX -     Al foil removal             Table Leveling

@ETMY -     ETMY damping             OSEM             OPLEV             Al foil removal             Table Leveling

@OMC -      v OM5(PZT)        neutralize, adjustment

@ITM/ETM -  Mirror Wiping 

15490   Thu Jul 16 14:41:22 2020 gautamUpdateGeneralFire extinguisher inspection

The (masked) tech accessed all areas in the lab (office area, control room, VEA) between ~230pm-3pm. The laser safety goggles he used have been kept aside for appropriate sanitaiton.

15530   Mon Aug 17 21:24:43 2020 gautamUpdateGeneralFire extinguisher inspection

A technician came to the lab today at ~4pm. He entered the VEA (with booties and googles), and also the clean and bake lab. The whole procedure lasted ~10 minutes. I did not follow him around, but was available in the control room throughout the process. I think the whole episode went without incident.

BTW, this guy didn't ring the doorbell, I just happened to be here when he came by. I don't know if this is usual practise - are we happy with the technicians entering the VEA and/or clean and bake labs without supervision? AFAIK, this wasn't scheduled.

1940   Tue Aug 25 02:37:53 2009 ranaConfigurationComputer Scripts / ProgramsFirefox 3.5 installed for 64 bit linux in apps/
Attachment 1: DSC_0620.JPG
5863   Thu Nov 10 16:26:46 2011 MirkoUpdateComputersFirefox kills elog

Had to restart the elog many times. For some reason firefox 8 on Win 7 kills the elog pretty consistently when trying to make a new entry. IE9 works fine ....

14010   Sat Jun 23 13:08:41 2018 JonUpdateAUXFirst Coherent AUX Scan of PRC Using AM Sidebands

[Jon, Keerthana, Sandrine]

Thu.-Fri. we continued with PRC scans using the AUX laser, but now the "scanned" parameter is the frequency of AM sidebands, rather than the frequency of the AUX carrier itself. The switch to AM (or PM) allows us to coherently measure the cavity transfer as a function of modulation frequency.

In order to make a sentinel measurement, I installed a broadband PDA255 at an unused pickoff behind the first AUX steering mirror on the AS table. The sentinel PD measures the AM actually imprinted on the light going into the IFO, making our measurement independent of the AOM response. This technique removes not only the (non-flat) AOM transfer function, but also any non-linearities from, e.g., overdriving the AOM. The below photo shows the new PD (center) on the AS table.

With the sentinel PD installed, we proceeded as follows.

• Locked IFO in PRMI on carrier.
• Locked AUX PLL to PSL.
• Tuned the frequency of the AUX laser (via the RF offset) to bring the carrier onto resonance with the PRC.
• Swept the AOM modulation frequency 0-60 MHz while measuring the AUX reflection and injection signals.

The below photo shows the measured transfer function [AUX Reflection / AUX Injection]. The measurement coherence is high to ~55 MHz (the AOM bandwidth is 60 MHz). We clearly resolve two FSRs, visible as Lorentzian dips at which more AUX power couples into the cavity. The SURFs have these data and will be separately posting figures for the measurements.

With the basic system working, we attempted to produce HOMs, first by partially occluding the injected AUX beam with a razor blade, then by placing a thin two-prong fork in the beam path. We also experimented with using a razor blade on the output to partially occlude the reflection beam just before the sensor. We were able to observe an apparent secondary dip indicative of an HOM a few times, as shown below, but could not repeat this deterministically. Besides not having fine control over the occlusion of the beams, there is also large few-Hz angular noise shaking the AS beam position. I suspect from moment to moment the HOM content is varying considerably due to the movement of the AS beam relative to the occluding object. I'm now thinking about more systematic ways to approach this.

14011   Sat Jun 23 20:54:35 2018 KojiUpdateAUXFirst Coherent AUX Scan of PRC Using AM Sidebands

How much was the osc freq of the marconi? And then how much was the resulting freq offset between PSL and AUX?

Are we supposed to see two dips with the separation of an FSR? Or four dips (you have two sidebands)?

And the distance between the dips (28MHz-ish?) seems too large to be the FSR (22MHz-ish).
cf https://wiki-40m.ligo.caltech.edu/IFO_Modeling/RC_lengths

14017   Tue Jun 26 10:06:39 2018 keerthanaUpdateAUXFirst Coherent AUX Scan of PRC Using AM Sidebands

(Jon, Keerthana, Sandrine)

I am attaching the plots of the Reflected and transmitted AUX beam. In the transmission graph, we are getting peak corresponding to the resonance frequencies, as at that frequency maximum power goes to the cavity. But in the Reflection graph, we are obtaining dips corresponding to the resonance frequency because maximum power goes to the cavity and the reflected beam intensity becomes very less at those points.

Attachment 1: TRANS.pdf
Attachment 2: REFL.pdf
7860   Wed Dec 19 21:35:33 2012 KojiSummaryGeneralFirst Contact Training with Margot

[Koji, Steve]

First Contact Training with Margot

12223   Tue Jun 28 20:43:23 2016 KojiSummaryCOCFirst Contact cleaning practice

Made a dry run of the in-situ cleaning for a 3inch optic.

Attachment 1: The Al dummy mass is clamped in the suspension cage.
Attachment 2: The front surface was painted. The nominal brush with the FC bottle was used.
Attachment 3: Zoom in of the front surface.
Attachment 4: The back surface was painted.
Attachment 5: The back surface was peeled.
Attachment 6: The front surface was peeled too.
Attachment 7: The peeled layers.

Findings:

1. To paint a thick layer (particlarly on the rim) is the key to peel it nicely.

2. It was helpful for easier peeling to have mutiple peek tabs. Two tabs were sufficient for ~1" circle.

3. The nominal brush with the bottle was OK although one has to apply the liquid many times to cover such a large area. A larger brush may cause dripping.

4. The nominal brush was sufficiently long once the OSEMs are removed. In any case it is better to remove the OSEMs.

Attachment 1: IMG_20160628_170335196.jpg
Attachment 2: IMG_20160628_171547769.jpg
Attachment 3: IMG_20160628_171607802.jpg
Attachment 4: IMG_20160628_172328190.jpg
Attachment 5: IMG_20160628_174541960.jpg
Attachment 6: IMG_20160628_174556004.jpg
Attachment 7: IMG_20160628_174617198.jpg
7388   Fri Sep 14 16:39:14 2012 ericq, jenneUpdateGeneralFirst In Vac Picture

After much fussing, we got a picture of MMT1 with the beam.

Using the iris doesn't seem feasible. Since it has to be significantly separated from the optic, it is hard to judge whether it is centered, especially in yaw.

It took ~30 min to get this picture. Comments on whether this kind of picture is good enough are welcomed, since there are many more to be taken.

Attachment 1: mmt1.jpg
7389   Fri Sep 14 18:15:43 2012 ranaUpdateASCFirst In Vac Picture

Looks good. Any way that you can tell in an unambiguous way, where the beam is, is very good. Ideally we want to have1-2 mm accuracy.

2964   Fri May 21 00:51:06 2010 JenneUpdateIOOFirst MC mode measuring (hopefully) done

[Jenne, Kiwamu, Steve]

Round 1 of measuring the MC mode is pretty much done.  Yay.

Earlier today, Steve and I launched the MC beam off the flat mirror just after the Faraday, and sent it down toward ETMY(new convention). We ended up not being able to see it all the way at the ETM because we were hitting the beam tube, but at the ITM chamber we could see that the beam looked nice and circle-y, so wasn't being clipped in the Faraday or anywhere else.  To do this we removed 2 1inch oplev optics.  One was removed from the BS table, and wrapped in foil and put in a plastic box.  The other was just layed on its' side on the BS table.

I then took the beam out of the BS chamber, in order to begin measuring the mode.  I left the flat fixed mirror in the place of what will be PZT SM1, and instead used the PZT mirror to turn the beam and get it out the BS chamber door.  (Thoughts of getting the beam to the BS oplev table were abandoned since this was way easier, since Kiwamu and Steve had made the nifty table leg things.)  Kiwamu and I borrowed an 2inch 45P Y1 optic from the collection on Koji's desk (since we have ZERO 2inch optics on the random-optic-shelf....no good), to shoot the beam down the hallway of the Yarm (new convention).  We used the beam scan on a rolling cart to measure the beam at various distances.  I made some sweet impromptu plum bobs to help make our distance measurements a bit more accurate.

We stopped at ~25 feet from the BS chamber, since the spot was getting too big for the beam scanner.  If it turns out that I can't get a good fit with the points I have, I'll keep everything in-chamber the same, and do the farther distances using the good ol' razor blade technique.

I have measurements for the distances between the beam scan head and the opening of the BS chamber.  Tomorrow, or very soon after, I need to measure the distances in-chamber between the MC and the BS chamber opening.  Plots etc will come after I have those distances.

Next on the to-do list:

1.  Measure distances in-chamber for first mode scan.

2.  Plot spot size vs. distance, see if we need more points. Take more points if needed.

3.  Put in MMT1, repeat measurements.

4.  Put in MMT2, rinse and repeat.

5.  Move the PZT mirror to its new place as SM1, and figure out how to connect it.  Right now the little wires are hooked up on the BS table, but we're going to need to make / find a connector to the outside world from the IOO table. This is potentially a pretty big pain, if we don't by happenstance have open connectors on the IOO table.

5727   Fri Oct 21 18:20:54 2011 MirkoUpdateCDSFirst OAF version running

[Jenne, Jamie, Mirko]

We got the first version of the oaf code based on Matt"s code running!! :-)
Produces already data for e.g. MICH DOF. But don"t trust that. It's only 10 taps long and delay is not adjusted.

16007   Thu Apr 8 17:04:43 2021 Anchal, PacoUpdateSUSFirst Successful Coil Balancing

Today, we finally crossed the last hurdle and got a successful converging coil balancing run.

### What was the issue with POS?

• Position of the MC2 mirror is being sensed using C1:IOO-MC_F_DQ channel which is proportional to the resonant frequency of the locked IMC.
• However, this sensor is always 180 degrees out of phase of our actuator, the coils.
• When the coils push the mirror forward, the length of the cavity actually decreases.
• We added an extra option of providing a sign to the sensors such that -1 will be multiplied to sensed values for sensors which measure in opposite direction to the actuation.
• This is important, because the feedback is applied to the coil output matrix assuming a particular direction of acctuation.
• When we gave negative sign for the position sensor, it all started making sense and the algorithm started converging.

### First run parameters:

• We used binwidth of 0.25 Hz and duration of excitation as 41s. This would give welch and csd averaging of 19. We used median averaging to ignore outliers.
• This iteration was run after PIT and YAW were separetly uncoupled before. We'll post a clean start to end run results in near future.
• The iteration works in following manner:
• Define a constant coil matrix C = [[1, 1, 1], [1, 1, -1], [1, -1, 1], [1, -1, -1]] which is ideal coil output matrix.
• In each iteration, the output matrix Ok is defined as (note @ is the matmul operator):
Ok = C @ Ak
where Ak is a 3x3 matrix. A-1 is identity matrix.
• At the end of each iteration, a sensing matrix is calculated in dimensions sensedDOF x excitedDOF, Sk
• For next iteration, Ak+1 is calcualted by:
Ak+1 = Ak - b * (Sk - I)
where I is the identity matrix.
• At convergence, the sensing matrix would become same as identity and matrix A will stop updating.
• For this run, we kept the parameter b to be 0.05. This is similar to the KP parameter in PID loops. It should be between 0 and 1.
• Since b value was small enough to allow for convergence from the inital point, but later it slowed down the process a lot.
• Ideally, we should figure out a way to increase this paramter when the coil has been balanced somewhat, to increase the speed of the algorithm.
• Secondly, we have a code which excites all DOFs at different frequencies directly using excitation channels in coil output matrix using awg.py. But for some reason, the excitation channel for 4th row in the output matrix column only connects intermittantly. Because of this, we can't use this method reliably yet. We can investigate more into it if suggested.

### Balancing characteristics:

• Attachment 1 shows how the distance of sensing matrix falls as iterations increase. We only ran for 50 iterations.
• Attachment 2 shows how different off-diagonal terms of sensing matrix decreased.
• Note that POS -> PIT, POS -> YAW and PIT-YAW have settled down to the noise floor.
• The noise floor can be improved by increasing the excitation amplitude and/or increasing the duration of measurement.
• Attachment 3 shows the evolution of sensing matrix as iterations move.

### Final balanced output matrix:

Final balanced output coil matrix for MC2
POS PIT YAW COILS
1.02956 1.13053 1.19116 UL
1.01210 1.09188 -0.74832 UR
0.98737 -0.85502 0.70485 LR
0.96991 -0.89366 -1.23463 LR
Final Sensing Matrix
Exc POS Exc PIT Exc YAW
Sens POS 1 -2.96e-2 8.00e-3
Sens PIT 8.58e-4 1 -4.84e-3
Sens YAW 5.97e-4 -1.15e-3 1

### Code features and next:

• Majority of the code is in two files: scripts/SUS/OutMatCalc/MC2crossCoupleTest.py and scripts/SUS/OutMatCalc/crossCoupleTest.py .
• The code runs from start to end without human involevement and restores the state of channels in any case (error, kyboard interrupt, end of code) using finally statement.
• Currently, each excitation is done one at a time through LockIn1. As mentioned above, this can be sped up 3 times if we get the awg.py to work reliably.
• The complete code is in python3 and currently is run through native python3 on allegra (a new debian10 workstation with latest cds-workstation installed).
• The code can be easily generalized for balancing any optic. Please let us know if we should work on making the generalized optic.
• We're also working on thinking about increasing b as iterations move forward and the error signal becomes smaller.
• We can also include the uncertainty in the Sensing matrix measurement to provide a weighted feedback. That way, we can probably increase b more.
Attachment 1: SDistanceFromIdentity.pdf
Attachment 2: SmatIterations.pdf
Attachment 3: SmatrixPlots.pdf
565   Wed Jun 25 11:36:14 2008 Max JonesUpdateComputer Scripts / ProgramsFirst Week Update
For the first week I have been modifying the noise budget script in caltech/NB to run with 40 m parameters and data. As per Rana's instructions, I have tried to run the script with only seismic and Darm sources. This involves identifying and changing channel names and altering paramter files (such as NB/ReferenceData/C1IFOparams.m). To supply the parameter files, I have copied the H1 files with (as yet only) slight modification. The channel name changes have been made to mirror the sites for the most part. Two figures are attached which show the current noise budget. The Day plot was taken 6/23/08 at ~10:30 am. The night plot was taken 6/22/08 at ~11:00 pm . Note that the SRD curve is for the sites and not for the 40 m (I hope to change that soon). Also in one of the plots the DARM noise signal is visible. Obviously this needs work. A list of current concerns is

1) I am using a seismic transfer function made by previous SURF student Ryan Kinney to operate with channels of the form C1:PEM_ACC-ETMY_Y (should I be using C1:DMF-IX_ACCY?) and the channels I am currently using are the acceleraometers for the mode cleaner with names of the form C1:PEM_ACC-MC1_X. Rana said that he thinks these may be the same but I need to be sure.

2) We don't have a DARM_CTRL channel but the code requires it, currently I am using DARM_ERR as a substitute which is probably partly responsible for the obvious error in DARM noise.

Any suggestions are appreciated. Max.
Attachment 1: C1_NoiseBudgetPlot_Day.eps
Attachment 2: C1_NoiseBudgetPlot_Night.eps
6879   Wed Jun 27 11:33:28 2012 MashaUpdateGeneralFirst Week Update

This week I wrote Matlab code, most of which can be found in /users/masha

First, I wrote a simulation seismicFilter.m which filters noisy seismic noise with a desired signal of non-seismic noise. The signals are purely simulated, so I played around with zero-pole-gain generation of transfer functions to obtain them. The function takes the number of taps, the filter type (Wiener or adaptive nlms) as well as an iteration step size and number of iterations, and generates PSD plots of the witness signal, the desired signal, the estimated (filtered) signal, and the error. I'm not sure that I am properly implementing the Wiener part of the code, and I assume the line "[W, R, P] = miso_firlev(TAPS, noisySeismicSignal1, seismicSignal2); " generates W, a filter with TAPS number of weights, but  then "[y, error] = filter(W, 1, noisySeismicSignal1);" generates an error signal of size TAPS rather than N, the size of the original signal. Perhaps I should calculate error using e(t) = d(t + a) - w(t)*x(t), where "a" is the delay.

I have various screenshots in my directory of what seismicFilter.m generates, and I will take a larger screenshot, as well as generate a learning curve (for error vs. number of taps) when I can use Sasha's computer for a bit, since it both has more computing power and a larger screen.

The funciton filterConvergence.m, meanwhile, is similar, except it takes two file names as real data, and uses realDataFilter.m to run the filtering. Currently, I am working with data from C1:IOO-MC_F_DQ-Online  and C1:PEM-SEIS_GUR1_X_IN1_DQ-Online, and I will include screenshots of these once I get on Sasha's computer.

In order to generate the data, meanwhile, I had to modify the python script, and thus wrote mashaImportingData.py for myself. Likewise, plotSignalFromFile.m visualizes this data, both in the time domain and in the frequency domain.

On the side, I wrote an NLMS filter in adaptiveFilterSimulationNLMS.m, and compared is to Matlab's NLMS filter in NLMStest.m (using generated data) and adaptiveFilterSimulation.m using twn input signals. Right now, it's faster on smaller inputs and smaller tap sizes, but then begins to choke and run slower than the Matlab one when these get to big. In order to improve it, I have to develop a better method of generating the initial weights.

As far as machine learning goes, once I find the number of taps for the convergence of both the Wiener filter and the NLMS filter, I will email Denis for further instructions. At some point, however, I should generate learning sets from the seismometers and the MCL (or the DARM), and thus have to find adequate times at which I can take data (probably not from the DARM, however, because it was rarely on).

6878   Wed Jun 27 11:27:49 2012 LizUpdate First Week Update!

This week, the other SURF students and I got acquainted with the caltech campus, LIGO 40m lab and the expectations of the SURF program.  We went to a lot of safety meetings and lectures that established a framework for the jobs we will be doing over the course of the summer.  I went on several tours of the 40m interferometer (one each with Jenne, Jamie and Steve) to get an overview of the layout and specifics of the setup.  I read parts of R. Ward and A. Parameswaran's theses and Saulson's book in order to prepare myself and gain a broader understanding of the purpose of LIGO.

I also began working in Python this week, primarily graphing PSDs of data from the C1:SUS-ETMY_SENSOR_LR, C1:SUS-ETMY_SENSOR_LL, C1:SUS-ETMY_SENSOR_UR, and C1:SUS-ETMY_SENSOR_UL channels.  I will eventually be using Python to generate the plots for the summary pages, so this is good practice.  The code that I have been working on can be found in /users/elizabeth.davison/script5.py.  Additionally, I have been going through the G1 summary pages and attempting to understand the plots available on them and the code that is available.

My plans for the upcoming week begin with modifying my code and potentially calibrating the channel data so that it is in units of length instead of counts.  I will also access the code from the G1 pages and go over it in depth, hopefully gaining insight into the structure of the website.

3099   Tue Jun 22 20:07:08 2010 JenneUpdate40m UpgradingFirst attempt at Tip Tilt hanging

[Jenne, Steve, Nancy, Gopal]

We made an attempt at hanging some of the Tip Tilt eddy current dampers today.

Photo 1 shows the 2 ECDs suspended.

Procedure:

(1) Loosen the #4-40 screws on the side of the ECDs, so the wire can be threaded through the clamps.

(2) Place the ECDs in the locator jigs (not shown), and the locator jigs in the backplane (removed from main TT structure), all laying flat on the table.

(3) Get a length of Tungsten wire (0.007 inch OD = 180um OD), wipe it with acetone, and cut it into 4 ~8cm long segments (long enough to go from the top of the backplane to the bottom).

(4) Thread a length of wire through the clamps on the ECDs, one length going through both ECDs' clamps.

(5) One person hold the wire taught, and straight, and as horizontal as possible, the other person tightened the clamping screws on the ECDs.

(6) Again holding the wire in place, one person put the clamps onto the backplane (the horizontal 'sticks' with 3 screws in them).

(7) The end. In the future, we'll also clip off extra pieces of wire.

When we held up the backplane to check out our handy work, it was clear that the bottom ECD was a much softer pendulum than the top one, since the top one has the wire held above and below, while the bottom one only has the wire held on the top.  I assume we'll trim the wire so that the upper ECD is only held on the top as well?

Lessons learned:

* This may be a 3 person job, or a 2 people who are good at multitasking job.  The wire needs to be held, the ECDs need to be held in place so they don't move during the screwing/clamping process, and the screws need to be tightened.

* Make sure to actually hold the wire taught. This didn't end up happening successfully for the leftmost wire in the photo, and the wire is a bit loose between the 2 ECDs.  This will need to be redone.

* We aren't sure that we have the correct screws for the clamps holding the wire to the backplane.  We only have 3/16" screws, and we aren't getting very many threads into the aluminum of the backplane.  Rana is ordering some 316 Stainless Steel (low magnetism) 1/4" #4-40 screws.  We're going for Stainless because Brass (the screws in the photo), while they passed their RGA scan, aren't really good for the vacuum.  And titanium is very expensive.

The 2nd photo is of the magnet sticking out of the optic holder.  The hole that the magnet is sitting in has an aluminum piece ~2/3 of the way through.  A steel disk has been placed on one side, and the magnet on the other.  By doing this, we don't need to do any press-fitting (which was a concern whether or not the magnets could withstand that procedure), and we don't need to do any epoxying.  We'll have to wait until the ECDs are hung, and the optic holder suspended, to see whether or not the magnet is sticking out far enough to get to the ECDs.

Attachment 1: 2_ECDs_small.jpg
Attachment 2: MagnetStickingOutFar_small.jpg
ELOG V3.1.3-