I bet the calibration is out of date; probably we replaced the OL laser for the BS and didn't fix the cal numbers. You can use the fringe contrast of the simple Michelson to calibrate the OLs for the ITMs and BS.

Summary:

I've been trying to put together the cost-function that will be used to optimize the Oplev loop shape. Here is what I have so far.

Details:

All of the terms that we want to include in the cost function can be derived from:

1. A measurement of the open-loop error signal [using DTT, calibrated to urad/rtHz]. We may want a breakdown of this in terms of "sensing noises" and "disturbances" (see the previous elog in this thread), but just a spectrum will suffice for the optimal controller given the current noises.
2. A model of the optical plant, P(s) [validated with a DTT swept-sine measurement]. 
3. A model of the controller, C(s). Some/all of the poles and zeros of this transfer function is what the optimization algorithm will tune to satisfy the design objectives.

From these, we can derive, for a given controller, C(s):

1. Closed-loop stability (i.e. all poles should be in the left-half of the complex plane), and exactly 2 UGFs. We can use MATLAB's allmargin function for this. An unstable controller can be rejected by assigning it an extremely high cost.
2. RMS rrror signal suppression in the frequency band (0.5Hz - 2Hz). We can require this to be >= 15dB (say).
3. Minimize gain peaking and noise injection - this information will be in the sensitivity function, . We can require this to be <= 10dB (say).
4. RMS of the control signal between 10 Hz and 200 Hz, multiplied by the digital suspension whitening filter, should be <10% of the DAC range (so that we don't have problems engaging the coil de-whitening).
5. Smallest gain margin (there will be multiple because of the various notches we have) should be > 10dB (say). Phase margin at both UGFs should be >30 degrees.
6. Terms 1-5 should not change by more than 10% for perturbations in the plant model parameters (f0 and Q of the pendulum) at the 10% (?) level. 

We can add more terms to the cost function if necessary, but I want to get some minimal set working first. All the "requirements" I've quoted above are just numbers out of my head at the moment, I will refine them once I get some feeling for how feasible a solution is for these requirements.

For a start, I attempted to model the current Oplev loop. The modeling of the plant and open-loop error signal spectrum have been described in the previous elogs in this thread.

I am, however, confused by the controller - the MEDM screen (see Attachment #2) would have me believe that the digital transfer function is FM2*FM5*FM7*FM8*gain(10). However, I get much better agreement between the measured and modelled in-loop error signal if I exclude the overall gain of 10 (see Attachments #1 for the models and #3 for measurements).

What am I missing? Getting this right will be important in specifying Term #4 in the cost function...

GV Edit 2 Aug 0030: As another sanity check, I computed the whitened Oplev control signal given the current loop shape (with sub-optimal high-frequency roll-off). In Attachment #4, I converted the y-axis from urad/rtHz to cts/rtHz using the approximate calibration of 240urad/ct (and the fact that the Oplev error signal is normalized by the QPD sum of ~13000 cts), and divided by 4 to account for the fact that the control signal is sent to 4 coils. It is clear that attempting to whiten the coil driver signals with the present Oplev loop shapes causes DAC saturation. I'm going to use this formulation for Term #4 in the cost function, and to solve a simpler optimization problem first - given the existing loop shape, what is the optimal elliptic low-pass filter to implement such that the cost function is minimized? 

There is also the question of how to go about doing the optimization, given that our cost function is a vector rather than a scalar. In the coating optimization code, we converted the vector cost function to a scalar one by taking a weighted sum of the individual components. This worked adequately well.

But there are techniques for vector cost-function optimization as well, which may work better. Specifically, the question is  if we can find the (infinite) solution set for which no one term in the error function can be made better without making another worse (the so-called Pareto front). Then we still have to make a choice as to which point along this curve we want to operate at.

Summary:

Currently, I am unable to engage the coil-dewhitening filters without destroying cavity locks. One reason why this is so is because the present Oplev servos have a roll-off at high frequencies that is not steep enough - engaging the digital whitening + analog de-whitening just causes the DAC output to saturate. Today, Rana and I discussed some ideas about how to approach this problem. This elog collects these thoughts. As I flesh out these ideas, I will update them in a more complete writeup in T1700363 (placeholder for now). Past relevant elogs: 5376, 9680. 

1. Why do we need optical levers?
   • ​​To stabilize the low-frequency seismic driven angular motion of the optics.
2.  In what frequency range can we / do we need to stabilize the angular motion of the optics? How much error signal suppression do we need in the control band? How much is achievable given the current Oplev setup?
   • ​​To answer these questions, we need to build a detailed Oplev noise budget.
   • Ultimately, the Oplev error signal is sensing the differential motion between the suspended optic and the incident laser beam.
   • What frequency range does laser beam jitter dominate the actual optic motion? What about mechanical drifts of the optical tables the HeNes sit on? And for many of the vertex optics, the Oplev beam has multiple bounces on steering mirrors on the stack. What is the contribution of the stack motion to the error signal?
   • The answers to the above will tell us what lower and upper UGFs we should and can pick. It will also be instructive to investigate if we can come up with a telescope design near the Oplev QPD that significantly reduces beam jitter effects (see elog 10732). Also, can we launch/extract the beam into/from the vacuum chamber in such a way that we aren't so susceptible to motion of the stack?
3. What are some noises that have to be measured and quantified?
   • Seismic noise
   • ​​Shot noise
   • Electronics noise of the QPD readout chain
   • HeNe intensity noise (does this matter since we are normalizing by QPD sum?)
   • HeNe beam pointing / jitter noise (How? N-corner hat method?)
   • Stack motion contribution to the Oplev error signal
4. How do we design the Oplev controller?
   • ​​The main problem is to frame the right cost function for this problem. Once this cost function is made, we can use MATLAB's PSO tool (which is what was used for the PR3 coating design optimization, and also successfully for this kind of loop shaping problems by Rana for aLIGO) to find a minimum by moving the controller poles and zeros around within bounds we define.

5. What terms should enter the cost function?

   • ​​In addition to those listed in elog 5376
   • We need the >10Hz roll-off to be steep enough that turning on the digital whitening will not significantly increase the DAC output RMS or drive it to saturation.
   • We'd like for the controller to be insensitive to 5% (?) errors in the assumed optical plant and noise models i.e. the closed loop shouldn't become unstable if we made a small error in some assumed parameters.
   • Some penalty for using excessive numbers of poles/zeros? Penalty for having too many high-frequency features.
6. Other things to verify / look into
   • ​​Verify if the counts -> urad calibration is still valid for all the Oplevs. We have the arm-cavity power quadratic dependance method, and the geometry method to do this.
   •  Check if the Oplev error signals are normalized by the quadrant sum.
   • How important is it to balance the individual quadrant gains?
   • Check with Koji / Rich about new QPDs. If we can get some, perhaps we can use these in the setup that Steve is going to prepare, as part of the temperature vs HeNe noise invenstigations.

Before the CDS went down, I had taken error signal spectra for the ITMs. I will update this elog tomorrow with these measurements, as well as some noise estimates, to get started.

Attachment #1 - Measured error signal spectrum with the Oplev loop disabled, measured at the IN1 input for ITMY. The y-axis calibration into urad/rtHz may not be exact (I don't know when this was last calibrated).

From this measurement, I've attempted to disentangle what is the seismic noise contribution to the measured plant output.

• To do so, I first modelled the plant as a pair of complex poles @0.95 Hz, Q=3. This gave the best agreement with measurement by eye, I didn't try and optimize this too carefully. 
• Next, I assumed all the noise between DC-10Hz comes from only seismic disturbance. So dividing the measured PSD by the plant transfer function gives the spectrum of the seismic disturbance. I further assumed this to be flat, and so I averaged it between DC-10Hz.
• This will be a first seismic noise model to the loop shape optimizer. I can probably get a better model using the GWINC calculations but for a start, this should be good enough.

It remains to characterize various other noise sources.

I have also confirmed that the "QPD" Simulink block, which is what is used for Oplevs, does indeed have the PIT and YAW outputs normalized by the SUM (see Attachment #2). This was not clear to me from the MEDM screen.

GV 30 Jul 5pm: I've included in Attachment #3 the block diagram of the general linear feedback topology, along with the specific "disturbances" and "noises" w.r.t. the Oplev loop. The measured (open loop) error signal spectrum of Attachment #1 (call it y) is given by:

If it turns out that one (or more) term(s) in each of the summations above dominates in all frequency bands of interest, then I guess we can drop the others. An elog with a first pass at a mathematical formulation of the cost-function for controller optimization to follow shortly.

I came across a paper (see reference) where they have used DAOPHOT, an astronomical software tool developed by NOAO, to study the point scatterers in LIGO test masses using images of varying exposure times. I'm going through the paper now. I think using this we can analyze the MC2 images and make some interesting observations.

Reference:  L.Glover et al., Optical scattering measurements and implications on thermal noise in Gravitational Wave detectors test-mass coatings Physics Letters A. 382. (2018)

I have updated the wiki with the layout of the out-of-vac optical tables: Updated optical tables

I used the new camera to take pictures.

Lesson learnt after the update:

To use the new canon to take better pictures of optics tables; set the camera to manual mode; no flash and iso at around 800 or higher if you can hold the camera still for that long. The autofocus works beautifully...so you will not need any minor tweaking of lens to take pictures. 

I uploaded an updated optickle model of the upgrade to the SVN directory with the optickle models (here).

[Jenne, Suresh, with support from Jamie and Koji]

MC spots measured, MC1, MC3 no change.

No clipping going through Faraday.

Beam hitting to the right of center of PZT1.  It was translated sideways so we are now hitting it on the center.  Knobs adjusted so we hit center of MMT1.

Beam totally obscured by Faraday on the way to MMT2.  MMT2 moved north, so that we clear the Faraday by more than a beam diameter.  MMT1 knobs adjusted to hit center of MMT2.

MMT2 knobs adjusted to hit center of PZT2.

PZT2 didn't have enough range with knobs, so we loosened it, pointed then adjusted with knobs so we're hitting center of PRM. 

We need to check spot centering on PRM with camera tomorrow.

Suresh checked that we're not clipped by IP ANG/POS pickoff mirrors, but we haven't done any alignment of IP ANG/POS.

Tomorrow:  Open ITMX door.  Check with Watek that we're hitting center of PRM.  Then look to see if we're hitting center of PR2.  Then, continue through the chain of optics.

 Gouy not Guoy:

http://www.rp-photonics.com/gouy_phase_shift.html

pronounced Goo-eee, with the emphasis on the second syllable.

It's OK; even Siegman got it wrong---48 times.

RA: NO, stil not OK.

Yesterday, I moved the following optics:

1. Lens in front of AS110 PD.
2. BS splitting light between AS110 and AS55.

After moving these components around a bit, I locked them down once I was happy that the beam was pretty well centered on both of them, and also on AS110 and AS55 (measured using O'scope with single bounce from one ITM, other optics misaligned).

The beam was close to clipping on the lens mentioned in #1, probably because this wasn't checked when the 90-10 BS was installed for the AUX laser. Furthermore, I believe we are losing more than 10% of the light due to this BS. The ASDC (which is derived from AS55 PD) level is down at ~110cts as the Michelson is fringing, while it used to be ~200 cts. I will update with a power measurement shortly. But I think we should move ahead with the plan to combine the beam into the IFO's AS mode as discussed at the meeting last week.

Unrelated to this work, but c1psl and c1iscaux were keyed. 

ASDC has something weird going on with it - my main goal yesterday was to calibrate the actuators of ITMX, ITMY and BS using the Michelson. But with the Michelson locked on a dark fringe, the ASDC level changed by up to 50 counts seemingly randomly (bright fringe was ~1000 cts, I had upped the whitening gain to +21dB), even though the CCD remained clearly dark throughout. Not sure if the problem is in the readout electronics or in the PD itself.

Is the 10% specified for P-Pol or for UNP? I contacted CVI about beamsplitters, since their website doesn't list a BS1-1064-90-... option on the website. They say a R=90% beamsplitter would be a custom job. The closest stock item they got is BS1-1064-95-2025-45UNP specified at R=95% for UNPolarized beams. They were kind enough to sent me the measured transmission curves for a recent lot of these, which is attached was uploaded to the wiki [Elog Police K: NO PROPRIETARY DOCUMENTS ON THE ELOG, which is public. Put it on our wiki and put the link here]. The figure is not labeled, but according to the contact Red is S-Pol and Blue is P-Pol, which means that this one actually has R=~90% for P, pretty much what we want. We'll need to buy two of these to make the swap in the setup.

Back to your original point: There's only a BS1-1064-10-2025-45UNP on the website, so unless we got these as custom items, the R for P-Pol is probably NOT actually 10%, just somewhere between 0% and 20%

Of course, many (but no all) of the optics were custom-ordered back in ~2000.

4  std cataloge item fused silica  BS1-1064-95-2025-45UNP 

ordered today. They will arrive no later than July 13, 2018

 Jenne asked me to simulate the signals on POP QPD when moving different mirrors, as a function of the Gouy phase where the QPD is placed.

I used the opportunity to create a MIST simulation file of the entire 40m interferometer, essentially based on my aLIGO configuration file. I used the recycling cavity lengths obtained from our survey, and other parameters from the wiki page. The configuration file is attached (fortymeters.mist).

Coming back to the main simulation, here is the result, both for the "regular" POP QPD and for a 22MHz demodulated one. The Gouy phase is measured starting from PR2. Cavity mirrors are easily decoupled from PRM in the "regular" QPD. As already demonstrated in a previous simulation, ETMs signals are very small in the 22 MHz QPD. Moreover, it is possible to zero the contribution from ITMs by choosing the right Gouy phase, at the price of a reduction of the PRM signal by a factor of 3-4. Simulation files are attached.

Over the past few days, I've been thinking about how to workout the details conerning Rana's request about a 'map' of the vicinity of the 40m interferometer. This map will take the positions of N randomly placed seismic sensors as well as the signals measured by each one of them and the calculated cross correlations between the sensors and between the sensors and the test mass of interest to give out a displacement vector with new sensor positions that are close to optimum for better seismic (and Newtonian) noise cancellation.

Now, I believe that much of the mathematical details have been already work out by Jenne in her thesis. She explains that the quantity of interest that we wish to minimize in order to find an optimal array is the following,

where   is the cross-correlation vector between the seismic detectors and the seismic (or Newtonian) noise,  is the cross-correlation matrix between the sensors and  is the seismic (or Newtonian) noise variance. 

I looked at the paper that Jenne cited from which she obtained the above quantity and noted that it is a bit different as it contains an extra term inside the square root, it is given by

where the new term,  is the matrix describing the self noise of the sensors. I think Jenne set this term to zero since we can always perform a huddle test on our detectors and know the self noise, thus effectively subtracting it from the signals of interest that we use to calculate the other cross correlation quantities.

Anyways, the quantity  above is a function of the positions of the sensors. In order to apply it to our situation, I'm planning on:

     1) Performing the huddle tests on our sensors, redoing it for the accelerometers and then the seismometers (once the data aquisition system is working... )  

     2) Randomly (well not randomly, there are some assumptions we can make as to what might work best in terms of sensor placement) place the sensors around the interferometer. I'm planning on using all six Wilcoxon 731A accelerometers, the two Guralps and the STS seismometer (any more?).

     3) Measure the ground signals and use wiener filtering in order to cancel out their self noises.

     4) From the measured signals and their present positions we should be able to figure out where to move the sensors in order to optimize subtraction.

i have also been messing around with Jenne's code on seismic field simulations with the hopes of simulating a version of the seismic field around the 40m in order to understand the NN of the site a little better... maybe. While the data aquisition gets back to a working state, I'm planning on using my simulated NN curve as a way to play around with sensor optimization before its done experimentally.

i have as well been thinking and learning a little bit about source characterization through machine learning methods, specially using neural networks as Masha did back in her SURF project on 2012. I have also been looking at Support vector machines. The reasons why I have been looking at machine learning algorithms is because of the nature of the everchanging seismic field around the interferometer. Suppose we find a pretty good sensor array that we like. How do we make sure that this array is any good at some time t after it has been found? If the array mostly deals with the usual seismic background (quiet) of the site of interest, we could incorporate machine learning techniques in order to mitigate any of the more random disturbances that happen around the sites, like delivery trucks, earthquakes, etc.

An exercise of optimally subtracting one seismometer signal by another using weiner filters was done. Results have been summarized document attached.

[Paco]

In the morning I took some time to align the AUX beams in the XEND table. Later in the afternoon, I did the same on the YEND table. I then locked the AUX beams to the arm cavities while they were stabilized using POX/POY and turned off the PSL hepa off temporarily (this should be turned on after today's work).

After checking the the temperature slider sign on the spectrum analyzer of the control room I took some out-of-loop measurements of both ALS beatnotes (Attachment #1) by running diaggui /users/Templates/ALS/ALS_outOfLoop_Ref_DQ.xml and by comparing them against their old references (red vs magenta and blue vs cyan); it seems that YAUX is not doing too bad, but XAUX has increased residual noise around and above 100 Hz; perhaps as a result of the ongoing ALS SURF loop investigations? It does look like the OLTF UGF has dropped by half from ~ 11 kHz to ~ 5.5 kHz.

Anyways let this be a reference measurement for current locking tasks, as well as for ongoing SURF projects.

The new HAM-A coil drivers have a single DB9 connector for all the binary inputs. This requires that the dewhitening switching signals from the fast system be spliced with the coil enable signals from c1auxey. There is a common return for all the binary inputs. To avoid directly connecting the grounds of the two systems, I have looked for a suitable opto-isolator for the c1auxey signals.

I best option I found is the Ocean Controls KTD-258, a 4-channel, DIN-rail-mounted opto-isolator supporting input/output voltages of up to 30 V DC. It is an active device and can be powered using the same 15 V supply as is currently powering both the Acromags and excitation. I ordered one unit to be trialed in c1auxey. If this is found to be good solution, we will order more for the upgrades of c1auxex and c1susaux, as required for compatibility with the new suspension electronics.

I have received the opto-isolator needed to complete the new c1auxey system. I left it sitting on the electronics bench next to the Acromag chassis.

Here is the manufacturer's wiring manual. It should be wired to the +15V chassis power and to the common return from the coil driver, following the instructions herein for NPN-style signals. Note that there are two sets of DIP switches (one on the input side and one on the output side) for selecting the mode of operation. These should all be set to "NPN" mode.

As Jon wrote we need to use the NPN configuration (see attachments). I tested the isolator channels in the following way:

1. I connected +15V from the power supply to the input(+) contact.

2. Signal wire from one of the digital outputs was connected to I1-4

3. When I set the digital output to HIGH, the LED on the isolator turns on.

4. I measure the resistance between O1-4 to output(-) and find it to be ~ 100ohm in the HIGH state and an open circuit in the LOW state, as expected from an open collector output.

Unlike the Acromag output, the isolator output is not pulled up in the LOW state. To do so we need to connect +15V to the output channel through a pull-up resistor. For now, I leave it with no pull-up. According to the schematics of the HAM-A Coil Driver, the digital output channels drive an electromagnetic relay (I think) so it might not need to be pulled up to switch back. I'm not sure. We will need to check the operation of these outputs at the installation.

During the testing of the isolator outputs pull-up, I accidentally ran a high current through O2, frying it dead. It is now permanently shorted to the + and - outputs rendering it unusable. In any case, we need another isolator since we have 5 channels we need to isolate.

I mounted the isolator on the DIN rail and started wiring the digital outputs into it. I connected the GND from the RTS to output(-) such that when the digital outputs are HIGH the channels in the coil driver will be sunk into the RTS GND and not the slow one avoiding GND contamination.

- Could you explain what is the blue thing in Attachment 1?

- To check the validity of the signal chain, can you make a diagram summarizing the path from the fast BO - BO I/F - Acromag - This opto-isolator - the coil driver relay? (Cut-and-paste of the existing schematics is fine)

I made a diagram (Attached). I think it explains the blue thing in the previous post.

I don't know what is the grounding situation in the RTS so I put a ground in both the coil driver and the RTS. Hopefully, only one of them is connected in reality.

I mounted the optoisolator on the DIN rail and connected the 3 first channels

to the optoisolator inputs 1,3,4 respectively. I connected the +15V input voltage into the input(+) of the optoisolator.

The outputs were connected to DB9F-2 where those channels were connected before.

I added DB9F-1 to the front panel to accept channels from the RTS. I connected the fast channels to connectors 1,2,3 from DB9F-1 to DB9F-2 according to the wiring diagram. The GND from DB9F-1 was connected to both connector 5 of DB9F-2 and the output (-).

I tested the channels: I connected a DB9 breakout board to DB9F-2. I measured the resistance between the RTS GND and the isolated channels while switching them on and off. In the beginning, when I turned on the binary channels the resistance was behaving weird - oscillating between low resistance and open circuit. I pulled up the channels through a 100Kohm resistor to observe whether the voltage behavior is reasonable or not. Indeed I observed that in the LOW state the voltage between the isolated channel and slow GND is 15V and 0.03V in the HIGH state. Then I disconnected the pull up from the channels and measured the resistance again. It showed ~ stable 170ohm in the HIGH state and an open circuit in the LOW state. I was not able to reproduce the weird initial behavior. Maybe the optoisolator needs some warmup of some sort.

We still need to wire the rest of the fast channels to DBF9-3 and isolate the channels in DBF9-4. For that, we need another optoisolator.

There is still an open issue with the BI channels not read by EPICS. They can still be read by the Windows machine though.

This RTS also use the BO interface with an opto isolator. https://dcc.ligo.org/LIGO-D1002593

Could you also include the pull up/pull down situations?

Since this Ocean Controls optoisolator has been shown to be compatible, I've gone ahead and ordered 10 more:

• (1) to complete c1auxey
• (2) for the upgrade of c1auxex
• (7) for the upgrade of c1susaux

They are expected to arrive by Wednesday.

According to the BO interface circuit board https://dcc.ligo.org/D1001266, PCIN wires are connected to the coil driver and they are not pulled either way.

That means that they're either grounded or floating. I updated the drawing.

I checked the BI situation on the HAM-A coil driver. It seems like these are sinking BIs and indeed need to be isolated from the Acromag unit GND to avoid contamination.

The BIs will have to be isolated on a different isolator. Now, the wires coming from the field (red) are connected to the second isolator's input and the outputs are connected to the Acromag BI module and the Acromag's RTN.

I updated the wiring diagram (attached) and the wiring spreadsheet.

In the diagram, you can notice that the BI isolator (the right one) is powered by the Acromag's +15V and switched when the coil driver's GND is supplied. I am not sure if it makes sense or not. In this configuration, there is a path between the coil driver's GND and the Acromag's GND but its resistance is at least 10KOhm. The extra careful option is to power the isolator by the coil driver's +V but there is no +V on any of the connectors going out of the coil driver.

I installed an additional isolator on the DIN rail and wired the remaining BOs (C1:SUS-ETMY_SD_ENABLE, C1:SUS-ETMY_LR_ENABLE) through it to the DB9F-4 feedthrough. I also added DB9F-3 for incoming wires from the RTS and made the required connection from it to DB9F-4.

I tested the new isolated BOs using the Windows machine (after stopping Modbus). As before, I measure the resistance between pin 5 (coil driver GND) and the channel under test. When I turn on the BO I see the resistance drops from inf to 166ohm and back to inf when I turn it off. Both channels passed the test.

If my understanding is correct, the (photo receiving) NPN transistor of the optocoupler is energized through the acromag. The LED side should be driven by the coil driver circuit. It is properly done for the "enable mon" through 750Ohm and +V. However, "Run/Acquire" is a relay switch and there is no one to drive the line. I propose to add the pull-up network to the run/acquire outputs. This way all 8 outputs become identical and symmetric.

We should test the configuration if this works properly. This can be done with just a manual switch, R=750Ohm, and a +V supply  (+18V I guess).

I updated the wiring diagram according to Koji's suggestion. According to the isolator manual, this configuration requires that the isolator input be configured as PNP.

Additionally, when the switch in the coil driver is open the LED in the isolator is signaling an on-state. Therefore, we might need to configure the Acromag to invert the input.

There are the Run/Aquire channels that we might need to add to the wiring diagram. If we do need to read them using slow channels, we will have to pull them up like the EnableMon channels to use them like in the wiring diagram.

I installed 2 additional isolators in the Acromag chassis. I set all the input channels to PNP. I ran the digital inputs (EnableMon channels) through these isolators according to the previous post.

I tested the digital inputs in the following way:

I connected an 18V voltage source to the signal wire under test through a 1Kohm resistor. I connected the GND of the voltage source to the RTN wire of the feedthrough. When the voltage source was connected, the LED on the isolator turned on and the EPICs channel under test was Enabled. When I disconnected the voltage source or shorted the signal wire to GND the LED on the isolator turned off and the EPICs channel showed a Disabled state.

Following Koji's channel list review, we made changes to the wiring spreadsheet.

Today, I made the changes real in the Acromag chassis. I went through the channel list one by one and made sure it is wired correctly. Additionally, since we now need all the channels the existing isolators have, I replaced the isolator with the defective channel with a new one.

The things to do next:

1. Create entries for the spare coil driver and satellite box channels in the EPICs DB.

2. Test the spare channels.

I edited /cvs/cds/caltech/target/c1auxey1/ETMYaux.db (after creating a backup) and added the spare coil driver channels.

I tested those channels using caget while fixing wiring issues. The tests were all succesful. The digital output channel were tested using the Windows machine since they are locked by some EPICs mechanism I don't yet understand.

One worrying point is I found that the differential analog inputs to be unstable unless I connected a reference to some stable voltage source unlike previous tests showed. It was unstable (but less) even when I connected the ref to the ground connectors on the power supplies on the workbench. This is really puzzling.

When I say unstable I mean that most of the time the voltage reading shows the right value, but occasionly there is a transient sharp volage drop of the order of 0.5V. I will do a more quantitative analysis tomorrow.

To simulate a differential output I used two power supplies connected in series. The outer connectors were used as the outputs and the common connector was connected to the ground and used as a reference. I hooked these outputs to one of the differential analog channels and measured it over time using Striptool. The setup is shown in attachment 3.

I tested two cases: With reference disconnected (attachment 1), and connected (attachment 2). Clearly, the non-referred case is way too noisy.

I redid the differential input experiment using the DS360 function generator we recently got. I generated a low frequency (0.1Hz) sine wave signal with an amplitude 0.5V and connected the + and - output to a differential input on the new c1auxcey Acromag chassis. I recorded a time series of the corresponding EPICS channel with and without the common on the DS360 connected to the Ref connector on the Acromag unit. The common connector on the DS360 is not normally grounded (there is a few tens of kohms between the ground and common connectors). The attachment shows that, indeed, the analog input readout is extremely noisy with the Ref being disconnected. The point where the Ref was connected to common is marked in the picture.

Conclusion: Ref connector on the analog input Acromag units must be connected to some stable voltage source for normal operation.

I've summarized the optomechanics configuration for the in-vacuum aux small optics

It's not obvious here but the post for POP_SM4 is the stack of BA2V, Newport 9953, PLS-T238, LMR1V. The mirror is a CM254-750-E03 curved mirror. This should go on the suspension base. I hope I did not make a mistake there...

Here is more detail of the POP_SM4 mount assembly.

It's a combination of BA2V + PLS-T238 + BA1V + TR-1.5 + LMR1V + Mirror: CM254-750-E03
Between BA1V and PLS-T238, we have to do a washer action to fix the post (8-32) with a 1/4-20 slot. Maybe we can use a 1" post shim from thorlabs/newport.
Otherwise, we should be able to fasten the other joints with silver-plated screws we already have/ordered.

I think TR-1.5 (and a shim) has not been given to Jordan for C&B. I'll take a look at these.

Asked Jordan to clean 2x 1.5" posts (0.5 dia) and a washer with 1" dia.

Summary:

The apparent increase in the ALS noise (witnessed in-loop, e.g. Attachment #2 here) during the CARM offset reduction may have an optomechanical origin. 

Details:

• A simplified CARM plant was setup in Finesse - 3 mirror coupled cavity with PRM, ITM and ETM, 40m params for R/T/L used. 
• For a sanity check, DC power buildup and coincident resonance of the PRC and arm cavity were checked. PRG and CARM linewidth also checks out, and scales as expected with arm losses.
• To investigate possible optomechanical issues - I cut the input power to 300 mW (I estimate 600 mW incident on the PRM), set a PRG of ~20, to mimic what we have right now.
• I drive the ITM at various CARM offsets, and measure the m/m transfer function to itself and the ETM.
• Attachement #1 shows the results. 

Interpretation:

• ericq had similar plots in his thesis, but I don't think the full implications of this effect were investigated, the context there was different.
• The optomechanical resonance builds up at ~10 Hz and sweeps up to ~100 Hz as the CARM offset approaches zero, with amplification close to x100 at the resonance.
• What this means is that the arm cavity is moving by up to 100x the ambient seismically driven dispalcements. 
• The EX/EY uPDH servos have considerable gain at these frequencies, and so the AUX laser frequency can keep up with this increased motion (to be quantified exactly what the increase in residual is).
• However, the ALS loop that maintains the frequency offset b/w the PSL and the AUX lasers is digitial, and only has ~20 dB gain at 30 Hz. - so the error signal for CARM control becomes noisier as we see.
• I speculate that the multiple peaky features in the in-loop error signal are a result of some dynamical effects which Finesse presumably does not simulate.
• The other puzzler is: this simulation would suggest that approaching the zero CARM offset from the other side (anti-spring) wouldn't have such instabilities building up. However, I am reasonably sure I've seen this effect approaching zero from both sides, though I haven't checked in the last month.
• Anyways, if this hypothesis is correct, we can't really take advantage of the ~8pm RMS residual noise performance of the IR ALS system sadly, because of our 250g mirrors and 800mW input power. 
• Possible workarounds:
  • High BW ALS - this would give us more gain at ~30 Hz and this wouldn't be a problem anymore really. But in my trials, I think I found that the IN2 gain on the CM board has to be inverted for this to work (the IN1 path and the IN2 path share a common AO path polarity, and we need the two paths to have the opposite polarity).
  • Cut the input power - this would reduce the optomechanical action, but presumably the vertex locking becomes noisier. In any case, this isn't really practical without some kind of motorized/remote-controlled waveplate for power adjustment. 

Update 415pm 5/6: Per the discussion at the meeting, I have now uploaded as Attachment #2 the force-->displacement (i.e. m/N) transfer functions. I now think these are appropriate units. For the ALS case, we could convert the m/N to Hz/N of extra frequency noise imprinted on the AUX laser due to the increased cavity motion. Is W/N really better here, since the mechanism is extra frequency noise on a beatnote, and there isn't really a PDH or DC error signal?

The plan for the tools in 40m

As of right now, there are 4 tool boxes. X-end, Y-end, Vertex, and the main tool box along the X-arm. The plan is the give each toolbox a set of their own tools. The tools of X-end, Y-end, and Vertex toolboxes will be very similar containing the basic tools such as pliers, screwdrivers, allen ball drivers. Along with this, each tool box will have a tape measure, caliper, level, and other measuring tools we find convinient. 

As for the new toolbox, I have done research and found a few good selections. The only problem I have ran into with this is the width of the tool box corresponding with the prices. The tool cabinet we have now is 41" wide. The issue I have is not in finding another toolbox of the same width, but for a similar price we can find a 54" wide tool cabinet. Would anyone be objected to making a bit more space for this?

How the tools will stay organized.

I the original idea I had was to use a specified color of electrical tape for each tool box. Then to wrap the corresponding tools tools with the same color tape. But it was brought to my attention that the electrical tape would become sticky over time. So, I think the using the label maker would be the best idea. with the labels being 'X' for X-end, 'Y' for Y-end, 'V' for vertex, and 'M' for main toolboxes.

An idea for the optical tables:

Anchal brought it up to me that it is a hassle to go back and forth searching for the correct sizes of Hex Keys and Allen Wrenches. The idea of a pouch on the outside of each optical table was mentioned so I brought this up to Paco. Paco also gave me the idea of a 3D printed stand we could make for allen ball drives. Does anyone have a preference or an idea of what would be the best choice and why? 

A few sidenotes: 

Anchal mentioned to me a while back that there are many cables that are laying on the racks that are not being used. Is there a way we could identify which ones are being used? 

I noticed that when we were vented that a few of the chamber doors were leaning up against the wall and not on a wooden stand like others. Although, the seats for the chamber doors are pretty spacious and do not give us much clearance. For the future ones, could we make something more sleek and put the wider seats at the end chambers?

The cabinets along the Y-Arm are labelled, but do not correspond with all the materials inside or are too full to take in more items. Could I organize these? 
 

[Jenne, Mirko]

To reiterate: We changed the OSEM loop shape for MC1-MC3. Below in black is the old loop shape, which simulated pendulum response in there. In red is the new loop shape.

The differences are due to extra filter in C1:SUS-MC?_SUSPOS module 6,7,9

6: Elliptical LP @ 2.5Hz
7: Inverse Chebychev HP @0.3Hz
8: 1st order LP @ 10Hz

This has the potential to be unstable, but is not. At some point these filters should be tuned further.

I just connected the Ottavia to the Netgear box and its working just fine. It'll remain switched on over the weekend.

Today, I and Jigyasa connected the Ottavia to one of the unused monitor screens Donatella. The Ottavia CPU had a label saying 'SMOKED''. One of the past elogs, 11091, dated back in March 2015, by Jenne had an update regarding the Ottavia smelling 'burny'. It seems to be working fine for about 2 hours now. Once it is connected to the Martian Network we can test it further. The Donatella screen we used seems to have a graphic problem, a damage to the display screen. Its a minor issue and does not affect the display that much, but perhaps it'll be better to use another screen if we plan to use the Ottavia in the future. We will power it down if there is an issue with it.

It has been working fine the whole day(we didn't do much testing on it though). We are leaving it on for the night.

Ottavia had been left running overnight and it seems to work fine. There has been no smell or any noticeable problems in the working. This morning Gautam, Kaustubh and I connected Ottavia to the Matrian Network through the Netgear switch in the 40m lab area. We were able to SSH into Ottavia through Pianosa and access directories. On the ottavia itself we were able to run ipython, access the internet. Since it seems to work out fine, Kaustubh and I are going to enable the ethernet connection to Ottavia and secure the wiring now.