The new matching circuit was tested.

Results:

f_nominal  f_actual  response    required mod.  drivng power
 [MHz]      [MHz]    [mrad/V]     [rad]         needed [dBm]
  9.1       9.1        55         0.22      =>   22
118.3     118.2        16         0.01      =>    6
 45.5      45.4        45         0.28      =>   25
 24.1       N/A         2.1       0.014     =>   27

Comments:

- 9.1MHz and 118.3MHz: They are just fine.

- 24.1MHz: Definitely better (>x3) than the previous trial to combine 118MHz & 24MHz.
  We got about the same modulation with the 50Ohm terminated bare crystal (for the port1).
  So, this is sort of the best we can do for the 24.1MHz with the current approach.
  The driving power of 27dBm is required at 24.1MHz

- About the 45MHz
  - The driving power of 27dBm is required at 24.1MHz
  - The maximum driving power with the AM stabilized driver is 23dBm, nominally to say.
  - I wonder how we can reduce resistance (and capacitance) of the 45MHz further...?
  - I also wonder if the IFO can be locked with reduced modulation (0.28 rad->0.2 rad)
  - Can the driver max power be boosted a bit? (i.e. adding an attenuator in the RF power detection path)

I've been looking into recovering the seismic BLRMs for the BS Trillium seismometer. It looks like the problem is probably in the anti-aliasing board. There's some heavy stuff sitting on top of it in the rack, so I'll take a look at it later when someone can give me a hand getting it out.

In detail, after verifying that there are signals coming directly out of the seismometer, I tried to inject a signal into the AA board and see it appear in one of the seismometer channels.

1. I looked specifically at C1:PEM-SEIS_BS_Z_IN1 (Ch9), C1:PEM-SEIS_BS_X_IN1 (Ch7), and C1:PEM-ACC_MC2_Y_IN1 (Ch27). All of these channels have between 2000--3000 cts.
2. I tried injecting a 200 mVpp signal at 1.7862 Hz into each of these channels, but the the output did not change.
3. All channels have 0 cts when the power to the AA board is off.
4. I then tried to inject the same signal into the AA board and see it at the output. The setup is shown in the first attachment. The second BNC coming out of the function generator is going to one of the AA board inputs; the 32 pin cable is coming directly from the output. All channels give 4.6 V when when the board is powered on regardless of wheter any signal is being injected.
5. To verify that the AA board is likely the culprit, I also injected the same signals directly into the ADC. The setup is shown in the second attachment. The 32 pin cable is going directly to the ADC. When injecting the same signals into the appropriate channels the above channels show between 200--300 cts, and 0 cts when no signal is injected.

Steve, the pictures you posted are not the AA board I was referring to. The attached pictures show the board which is sitting beneath the GPS time server.

Using Gautam's Finesse file and the cad files for the 40m optical setup I propagated the arm mode out of the AS port. For the location of the 3.04 mm waist I used the average distance to the ITMs, which is 11.321 m from the beam spot on the 2 inch mirror on the AS table close to the viewport. The 2inch lens focuses the IFO mode to a 82.6 μm waist at a distance of 81 cm, which is what we have to match the aux laser fiber output to.

I profiled the fiber output and obtained a waist of 289.4 μm at a distance of 93.3 cm from the front edge of the base of the fiber mount. Next step is to figure out the lens placement and how to merge the beam paths. We could use a simple mirror if we don't need AS110 and AS55, we could use a polarizing BS and work with s polarization, or we find a Faraday Isolator.

While doing a beam scan with the razor blade method I noticed that the aux laser has significant intensity noise. This is seen on the New Focus 1611 that is used for the beat signal between PSL and aux laser, as well as on the fiber output PD. There is a strong oscillation around 210 kHz. The oscillation frequency decreases when the output power is turned down, the noise eater has no effect. Koji suggested it could be light scattering back into the laser because I couldn't find a usable Faraday Isolator back when I installed the aux laser in the PSL enclosure. I'll have to investigate this a little further, look at the spectrum, etc. This intensity noise will appear as amplitude noise of the beat note, which worries me a little.

For the arm cavity ringdowns, I guess we don't need AS55/AS110 (although I think the camera will still be useful for alignment). But for something like RC Gouy phase characterization, I'd imagine we need the AS detectors to lock various cavities. So I think we should go for a solution that doesn't disturb the AS PD beams. 

It's hard to tell from the plot in the manual (pg 52) what exactly the relaxation oscillation frequency is, but I think it's closer to 600 kHz (is this characteristic of NdYAG NPROs)??  Is the high RIN on the light straight out of the NPRO? 

I suspect that the LD of the aux laser is dying.
- The max power we obtain from this laser (700mW NPRO) is 33mW. Yes, 33mW. (See attachment 1)
- The intensity noise is likely to be relaxation oscillation and the frequency is so low as the pump power is low. When the ADJ is adjusted to 0, the peak moved even lower. (Attachment 2, compare purple and red)
- What the NE (noise eater) doing? Almost nothing. I suspect the ISS gain is too low because of the low output power. (Attachment 2, compare green and red)

Aidan called saying nodus was down at ~345pm. I was able to access it at ~330pm. I couldn't ssh in from my machine or the control room ones. So I went to 1X7 and plugged in a monitor to nodus. It was totally unresponsive. Since the machine wasn't responding to ping either, I decided to hard-reboot it. Machine seemed to come back up smoothly. I had trouble getting the elog started - it wasn't clear to me that the web ports were closed by default, so even though the startELOGD.sh script was running fine, the 8080 port wasn't open to the outside world. Anyways, once I figured this out, I was able to start the elog. DokuWiki also seems to be up and running now... 

I found megatron in a similar state to that which nodus was in yesterday. Clued by the fact that MCautolocker wasn't executing the mc scripts (as was evident from looking at the wall StripTool trace), I tried ssh-ing into megatron, but was unable to (despite it being responsive to ping requests). So I went into the VEA and plugged in a monitor to megatron - saw nothing on it. With no soft reboot options available, I power cycled the machine via the front panel button. It came back up smoothly. I manually restarted the autolocker, FSSslow and EX thermal control processes (the former two with initctl, while the latter runs in a tmux session). Everything seems alright for now. Not sure how long megatron has been dead for.

In September 2017 I measured ~150mW output power, which was already kind of low. What are the chances of getting this one repaired? Steve, can you please check the serial number? It's probably too old like the other ones.

Steve was calibrating the load cells at the EY table with the crane - we didn't get through the full procedure today, so the area near the EY table is kind of obstructed. The 100kg donut is resting on the floor on the North side of the EY table and is still connected to the crane. There are stopper plates underneath the donut, and it is still connected to the crane. Steve has placed cones around the area too. The crane has been turned off.

Motivation:

We'd like to know how much actuation is required on the ETMs to lock the DARM degree of freedom. The "disturbance" we are trying to cancel is the seismic driven length fluctuation of the arm cavity. In order to try and estimate what the actuation required will be, we can use data from POX/POY locks. I'd collected some data on Friday which I looked at today. Here are the results.

Method:

• I collected the error and control signals for both arm cavities while they were locked to the PSL.
• Knowing the POX/POY sensing response and the actuator transfer functions, we can back out the free running displacements of the two arm cavities.
  • I used numbers from the cal filters which may not be accurate (although POX sensing response which was recently measured).
  • But the spectra computed using this method seem reasonable, and the X and Y arm asds line up around 1 Hz (albeit on a log scale).
  • In this context,  is really a proxy for  and similarly for L_Y so I think the algebra works out correctly.
  • I didn't include any of the violin mode/AA/AI filters in this calculation.
• Having calculated the arm cavity displacements, I computed "DARM" as L_y- L_x and then plotted its asd.
• For good measure, I also added the quadrature sum of 4 optics' displacement noise as per the 40m GWINC model - there seems to be a pretty large discrepancy, not sure why.

If this approach looks legit, I will compute the control signal that is required to stabilize this level of disturbance using the DARM control loop, and see what is the maximum permissible series resistance we can use in order to realize this stabilization. We can then compare various scenarios like different whitening schemes, with/without Barry puck etc, and look at coil driver noise levels for each of them. 

Here is an updated plot - the main difference is that I have added a trace that is the frequency domain wiener filter subtraction of the coherent power between the L_X and L_Y time series. I tried reproducing the calculation with the time domain wiener filter subtraction as well, using half of the time series (i.e. 5 mins) to train the wiener filter (with L_X as target and L_Y as witness), but I don't get any subtraction above 5 Hz on the half of the data that is a test data set. Probably I am not doing the pre-filtering correctly - I downsampled the signal to 1 kHz, weighted it by low passing the signal above 40 Hz and trained the Wiener filter on the resulting time series. But this frequency domain Wiener filter subtraction should be at least a lower bound on DARM - indeed, it is slightly lower everywhere than simply taking the time domain subtraction of the two data streams.

To do:

• Re-measure calibration numbers used.
• Redo calculation once the numbers have been verified.

Putting a slightly cleaned up version of this plot in now - I'm only including the coherence-inferred DARM estimate now instead of the straight up time domain subtraction. So this is likely to be an underestimate. At low (<10 Hz) frequencies, the time domain computation lines up fairly well, but I suspect that I am getting huge amounts of spectral leakage (see Attachment #2) in the way I compute the spectrum using scipy's filtering routine (once the Wiener filter has been computed). Note that Attachment #2, I didn't break up the data into a training/testing set as in this case, we just care about the one-off offline performance in order to get an estimate of DARM.

The python version of the wiener filter generating code only supports [b,a] output of the digital filter, an sos filter might give better results. Need to figure out the least painful way of implementing the low-noise digital filtering in python...

Instead of trying to couple the fiber output into the interferometer, I'm doing the reverse and maximize the amount of interferometer light going into the fiber. I set up the mode-matching solution shown in attachment #1 and started tweaking the lens positions. Attachment #2 shows the setup on the AS table. After the initial placement I kept moving the lenses in the green arrow directions and got more and more light into the fiber.

When I stopped this work yesterday I measured 86% of the AS port light coming out the other fiber end, and I have not yet reached a turning point with moving the lenses, so it's possible I can tickle out a little more than that.

It occured to me though that I may have been a little hasty with the placement of the mirror that in attachment #2 redirects the beam which would ordinarily go to AS55. For my arm ringdown measurements this doesn't matter, I could actually place it even before the 50/50 beamsplitter that sends light onto AS110 and double the amount of light going into the IFO. What signals are needed for the Guoy phase measurement? Is AS 110 sufficient, or do we need AS55?

I think we need AS55 for locking the configuration Jon suggested - AS55 I and Q were used to lock the SRMI previously, and so I'd like to start from those settings but perhaps there is a way to do this with AS110 I and Q as well.

Summary:

Using the Wiener Filter estimate of the DARM disturbance we will have to cancel, I computed how the control signal would look like for a few scenarios. Our DACs are 16-bit, +/-10V (i.e. +/-32,768cts-pk, or ~23,000cts RMS). We need to consider the shape of the de-whitening filter to conclude whether it is feasible to increase the series resistance by x10 or not.

Some details:

Note that in this first computation, I have not considered

• Actuation range required by other loops (e.g. local damping, Oplev etc).
• At some point, I need to add the 2P/c radiation pressure disturbance as well.
• The control signal is calculated assuming we are actuating equally on both ETMs (but with opposite phase).
• RMS computation is done from 30 Hz downwards, as above 30 Hz, I think the estimate from the previous elog is not true seismic displacement. 
• De-whitening filters (or digital whitening), which will be required to suppress DAC noise at 100Hz.
• DARM loop shape, specifically low-pass to avoid sensing noise injection. In this calculation, I just used the pendulum transfer function.

While doing this calculation, I have accounted for the fact that right now, the analog de-whitening filters in the ETM drive chain have a x3 gain which we will remove. Actually this is an assumption, I have not yet measured a transfer function, maybe I'll do one channel at EY to confirm. Also, the actuator gains themselves need to be confirmed.

As I was looking at the coil driver schematic more closely, I realized that there are actually two separate series resistances, one for the fast controls path, and another for the DC bias voltage from the slow ADCs. So I think we have been underestimating the Johnson noise of the coil drivers by sqrt(2). I've also attached screenshots of the IFOalign and MCalign screens. The two  ITMs and ETMX have pitch DC bias values that are compatible with a x10 increase of the series resistance. But even so, we will have ~3pA/rtHz per coil from the two resistances.

gautam 8pm May8: Seems like I had confirmed the x3 gain in the EX de-whitening board when Johannes and I were investigating the AI board offset.

example of plots illustrating DAC range / saturation

There was an earthquake, all watchdogs were tripped, ITMX was stuck, and c1psl was dead so MCautolocker was stuck.

Watchdogs were reset (except ETMX which remains shutdown until we finish with the stack weight measurement), ITMX was unstuck using the usual jiggling technique, and the c1psl crate was keyed.

There is no beam going into the IFO at the moment. There was definitely a spot on the AS camera after I restored the suspensions yesterday, as you can see from the ASDC level in Attachment #1. But at around 2pm Pacific yesterday, the ASDC level has gone to 0. I suspect the TTs. There is no beam on the REFL camera either when PRM is aligned, and PRM's DC alignment is good as judged by Oplev.

Normally, I am able to recover the beam by scanning the TTs around with some low frequency sine waves, but not today. We don't have any readback (Oplev/OSEM) of the TT alignment, and the DC bias values havent jumped abnormally around the time this happened, judging by the OUT16 monitor points (see Attachment #2). The IMC was also locked at the time when this abrupt drop in ASDC level happened. Unfortunately, we don't have a camera on the Faraday so I don't know where the misalignment is happening, but the beam is certainly not making it to the BS. All the SOS optics (e.g. BS, ITMX and ITMY) are well aligned as judged by Oplev.

Being debugged now...

As suspected - the problem was with the TTs. I tested the TT signal chain by driving a low frequency sine wave using AWG and looking at the signal on an o'scope. But I saw nothing, neither at the AI board monitor point, nor at the actual coil driver mon point. I decided to look at the IOP testpoints for the DAC channels, to see if the signals were going through okay on the digital side. But the IOP channels were flatlined, as viewed on dataviewer (see Attachment #1). This despite the fact that the DAC output monitor screen in the model itself was showing some sensible numbers, again see Attachment #1.

Looking at the CDS overview screen, there were no red flags. But there was a red indicator sneakily hidden away in the IOP model's CDS status screen, the "DAC" field in the state word is red. As Attachment #2 shows, a change in the state word is correlated with the time ASDC went to 0.

Note that there are also no errors on the c1lsc frontend itself, judging by dmesg. I want to do a model restart, but (i) this will likely require reboots of all vertex FEs and (ii) I want to know if any CDS experts want to sniff for clues to what's going on before a model restart wipes out some secret logfiles. I'm a little confused that the rtcds isn't throwing up any errors and causing models to crash if the values are not being written to the registers of the DAC. It may also be that the DAC card itself is dead . To re-iterate, all the EPICS readbacks were suggesting that I am injecting a signal right up to the IOP.

Quoting from the runtime diagnostics note:

20180508 4:49am Cabazon earth quake 4.5M at 79 miles away.  ETMX is in load cell measurment condition.

Looking at Steve's plot, I was reminded of the ITMY UL OSEM issue. The numbers don't make sense to me though - 300um of DC shift in UL with negligible shifts in the other coils should have made a much bigger DC shift in the Oplev spot position.

Summary:

1. It seems that after a x10 increase in the coil driver resistance, we will have enough actuation range to control (anti de-whitened) DARM without saturating the DAC.
2. The Barry puck doesn't seem to help us much in reducing the required RMS for DARM control. If this calculation is to be believed, it actually makes the RMS actuation a little bit higher.

See Attachment #1 for the projected control signal ASDs. The main assumption in the above is that all other control loops can be low-passed sufficiently such that even with anti-dewhitening, we won't run into saturation issues.

DARM control loop:

• I'm now calculating the DARM control signal in counts after factoring into account a digital DARM control loop.
• The loop shape is what we used when the DRFPMI was locked in Oct 2015.
• I scaled the overall OLTF gain to have a UGF around 200Hz.
• The breakdown of how the DARM loop is constructed is shown in Attachment #2.

De-whitening and Anti-De-whitening:

• The existing DW shape in the ITM and ETM signal chains has ~80dB attenuation around 100 Hz.
• Assuming ~5uV/rtHz noise from the DAC, 60dB of low-passing gets us to 5nV/rtHz. With 4.3kohm series resistance, this amounts to ~1pA/rtHz current noise (compared to ~3pA/rtHz from the Johnson noise of the series resistance). Actually, I measured the DAC noise to be more like ~700nV/rtHz at 100 Hz, so the current noise contribution is only 0.16pA/rtHz.
• This amounts to getting rid of the passive filter at the end of the chain in the de-whitening board.
• Attachment #3 shows the existing and proposed filter shapes.

It remains to add the control signals for Oplev, local damping, and ASC to make sure we have sufficient headroom, but given that current projections are predicting using up only ~1000cts of the ~23000cts (RMS) available from the DAC, I think it is likely we won't run into saturations. Need to also figure out what the implication of the reduced actuation range will be on handling the locking transient.

I think "OLG" trace is not labeled right; it would be good to see the actual OLG in addition to whatever that trace actually is.

Based on the first plot, however, my conclusion is that:

1. we don't need the passive isolator to reduce the control signal; the control signal is dominated by f < 10 Hz.
2. we should still look into isolators for the reduction of the f > 50 Hz stuff, just to make the overall DARM sensitivity better. But this does not have to be pneumatic since we no longer need 10 Hz isolation. It can instead be a solid piece of rubber to give us a ~20-30 Hz resonance. That would still give us a factor of 5-10 improvement above 100 Hz.
3. In this case, we only need a mass estimate of the end chamber contents with an accuracy of ~25%. If we think we have that already, we don't need to keep doing the jacks-strain gauge adventure.

I was a bit hasty in posting the earlier plots. In the earlier plot, the "OLG" trace was OLG * anti dewhitening as Rana pointed out.

Here are the updated ones, and a cartoon (Attachment #5) of the loop topology I assumed. I've excluded things like violin filters, AA/AI etc. The overall gain scaling I mentioned in the previous elog amounts to changing the optical sensing response in this cartoon. I now also show the DARM suppression (Attachment #4) for this OLG and the DARM linewidths for RSE. I don't think the conclusions change.

Note that for Signal Recycling, which is what Kevin tells us we need to do, there is a DARM pole at ~150 Hz. I assume we will cancel this in the digital controller and so can achieve a similar OLG shape. This would modify the control signal spectrum a little around 150Hz. But for a UGF on the loop of ~150 Hz, we should still be able to roll-off the control signal at high frequencies and so the RMS shouldn't be dramatically affected.

Steve is looking into acquiring 4.5kohm Vishay Wirewound resistors with 1% tolerance. Plan is to install two in parallel (so that we get 2kohm effective resistance) and then snip off one once we are convinced we won't have any actuation range issues. Do these look okay? They're ~$1.50ea on mouser assuming we get 100. Do we need the non-inductive winding?

Good question! I've never calculated what the resonance frequency would be if had an inductive resistor with our cable capacitance (~50 pF/m I guess).

I found the c1lsc machine to be completely unresponsive today. Looking at the trend of the state word, it happened sometime yesterday (Saturday). The usual reboot procedure did not work - I am not able to bring back any of the models on any of the machines, during the restart procedure, they all fail. The logfile reads (for the c1ioo front end, but they all behave the same):

Not sure what is going on here, or what "Corrutped EPICS data" is supposed to mean. Thinking that something was messed up the last time the model was compiled, I tried recompiling the IOP model. But I'm not able to even compile the model, it fails giving the error message

I suspect this is some kind of path problem - the EPICS_BASE bash variable is set to /cvs/cds/rtapps/epics-3.14.12.2_long/base on the FEs, while /cvs isn't even mounted on the FEs (nor do I think it should be). I think the correct path should be /opt/rtapps/epics-3.14.12.2_long/base. Why should this have changed?

I've shutdown all watchdogs until this is resolved.

As suspected, this was indeed a path problem. Johannes will elog about it later, but in short, it is related to some path variables being changed in order to try and streamline the EPICS processes on the new c1auxex machine (Acromag Era). It is confusing that futzing around with the slow computing system messes with the realtime system as well - aren't these supposed to be decoupled? Once the paths were restored by Johannes, everything compiled and restarted fine. We even have a beam on the AS camera, which was what triggered this whole thing.

Anyways, Attachment #1 shows the current status. I am puzzled by the red TIMING indicators on the c1x04 and c1x02 processes, it is absent from any other processes. How can this be debugged further?

I think the root of the problem is that the /opt/rtapps/ and /cvs/cds/rtapps/ mounting locations point to the same directory on the nfs server. Gautam and I were cleaning up the /cvs/cds/caltech/target/ directory, placing the previous contents of /cvs/cds/caltech/target/c1auxex/, including database files and startup instructions in /cvs/cds/caltech/target/c1auxex_oldVME/, and then moved /cvs/cds/caltech/target/c1auxex2/, which has the channel database and initialization files for the Acromac DAQ, to /cvs/cds/caltech/target/c1auxex/.

This also required updating the systemd entries on c1auxex to point to the changed directory. While confirming that everything worked as before we noticed that upon startup the EPICS IOC complains about not being able to find the caRepeater binary. This was not new and has not limited DAQ functionality in the past, but we wanted to fix this, as it seemed to be some simple PATH issue. While the paths are all correctly defined in the user login shell, systemd runs on a lower level and doesn't know about them. One thing we tried was to let systemd execute /cvs/cds/rtapps/epics-3.14.12.2_long/etc/epics-user-env.sh initializing EPICS. It was strange that the content of that file was pointing to /opt/rtapps/epics-3.14.12.2_long/base, which is not mounted on the slow machines, so we changed the /opt/ it to /cvs/cds/, not realizing that the frontends read from the same directory (as Gautam said, /cvs/cds does not exist as a mount point on the frontend). It ended up not working this way, and apparently I forgot to change it back during clean up. But worse, never elogged it!

In the end, we managed to to give systemd the correct path definitions by explicitly calling them out in /cvs/cds/caltech/target/c1auxex/ETMXenv, to which a reference was added in the systemd service file. The caRepeater warning no longer appears.

[steve,koji,gautam]

Since we think we already know the stack mass to ~25% (i.e. 5000 +/- 1000 lbs), we decided to restore the ETMX stack. Procedure followed was:

• Take photos of all dial indicators and spirit level. We were at ~-22 mils on all 3 indicators, with 0 being the level before we touched the stack two Fridays ago, i.e. May4.
• Raised all four jacks installed underneat blue crossbeams in 5mil increments until we were at +25mils on all of them. At this point, there was negligible load on the load cells on top of the STACIS legs, and we could easily slide the load cells out.
• Rotated all jack screws clockwise (i.e. moving jack screws downwards) by 270 degrees. The southeast jackscrew was rotated by an additional 360 degrees. This was to undo all the jack-screw raising we did on Friday, May 4.
• Re-installed jacks which were present originally on the STACIS legs, taking care to center the jack as best as we could by eye on the STACIS leg, per Dennis Coyne's suggestion not to impose shear strain on STACIS legs. There were supposedly never carrying any load, and are according to Steve, are there more for safety purposes.
• Lowered all four jacks in 5 mil steps until dial indicators read ~0. The Northwest jack resting on the STACIS leg was somehow ~0.5cm (!!) below the blue crossbeam even though the corresponding dial gauge read 0, so we raised the jack until it was barely grazing the bottom of the blue crossbeam (confirmed by looking at the point where the dial indicator started going up again). Not sure why this should have been, best hypothesis we have is that someone (one of us) changed the level of this jack while it was removed from the setup.
• Checked that jack screws could not be turned by hand. At this point, all the load has to be resting on the jack screws, as the jacks we had installed to raise the blue crossbeams could be slid out from underneath the blue beams and hence were carrying no load.
• Took photographs of all dial indicators, spirit level. We were satisfied that we had recovered the "nominal" stack alignment as best as we could judge with the available indicators.
• ETMX Oplev spot had returned to the PD. ETMX watchdog was re-engaged, optic was re-aligned using SLOW bias sliders to center Oplev spot.
• EX NPRO was turned back on, and the green beam was readily locked to a cavity TEM00 mode .

I will upload the photos to the PICASA page and post the link here later.

Since there have been various software/hardware activity going on (stack weighing, AUX laser PLL, computing timing errors etc etc), I decided to do a check on the state of the IFO.

• c1susaux, c1aux and c1iscaux crates were keyed as they were un-telnet-able.
• Single arm locking worked fine, TT alignment was tweaked (as these had drifted due to the ADC failure in c1lsc) to maximize Y arm transmission using the dither servos.
• Arms weren't staying locked for extended periods of time. I particularly suspected ITMX, as I saw what I judged to be excess motion on the Oplev.
• @Steve - ITMX and BS HeNes look like they are in need of replacement judging by the RIN (although the trend data doesn't show any precipitous drop in power). If we are replacing the BS/PRM Oplev HeNe, might be a good time to plan the inejction path a bit better on that table.
• RIN in Attachment #1 has been normalized by the mean value of the OL sum channel. There is now a script to make this kind of plot from NDS in the scripts directory (as I found it confusing to apply different calibrations to individual traces in DTT).

The final set-up of stack measurment with 3 load cells and 4 leveling wedge mounts as Atm 1

Sensor voltages BEFORE and AFTER this attempt.

The EPICS process on the c1ioo front end had died mysteriously. As a result, MC autolocker wasn't working, since the autolocker control variables are EPICS channels defined in the c1ioo model. I restarted the model, and now MCautolocker works.

Tip-Tilt Suspension Design:

Designed a new ECD plate and changed dimensions of the side arms after discussing with Koji. After getting feedback on the changes, I will finish the assembly and send it to him to get approved for manufacturing.

Target: Phase locking can be acheived by giving a scan to the oscilator frequency. This frequency is now controlled using the knobe on the AM/FM signal generator 2023B. But we need to control it remotely by giving the inputs of start frequency, end frequency and the steps.

The frequency oscilator and the computer is connected with the help of GPIB Ethernet converter. The IP address of the converter I used is '192.168.113.109' and its GPIB address is 10.

I could change the oscilator frequency by changing the input frequency with the help of the code I made (Inorder to check this code, I have changed the oscilator frequency multiple times. I hope it didn't create trouble to anyone). Now I am trying to make this code better by adding certain features like numpy, argument parse etc, which I will be able complete by next week. I am also considering to develop the code to have a sliding system to control the oscillatory frequency.

For record: The maximum limit of frequency which i changed upto is 100MHz.

Today, I tested the new mini-circuit frequency counter by connecting it with the beat signal output. The frequency counter works fine. Now I am trying to get a display of the frequency in the computer screen using python programming. I have made the code for remotely changing oscilator frequency and it is saved in the folder 'ksnair'. A picture of the new mini circuits frequency counter is attached below. Part no: UFC-6000, S/N: 11501040012, Run: M075270.

I was planning to set up the additions to the AS table that are outlined in Attachment #1. Unfortunately the beam is too large for the 2mm clear aperture Faraday rotators that we have available at that position. I checked the 40m and QIL and found 5 Faraday isolators/rotators for 1064 nm total, but none have large enough aperture for the current setup. Some options for buying a larger aperture isolator are:

• https://www.newport.com/p/ISO-FRDY-08-1064-W
• https://www.thorlabs.com/thorproduct.cfm?partnumber=IO-5-1064-HP
• https://www.eotech.com/cart/72/free-space-optical-isolators/pavos-series-1045-nm---1080-nm-high-power-optical-isolators---small-aperture-(%E2%89%A45-mm)

I wanted to leave the rest of the setup undisturbed at first, but I think a much easier solution would be to move the 2" focusing lens up by about 12", which moves the beam focus away from AS55 to where the Faraday will be placed, but we can re-focus it with another lens. I may have to change the mode-matching for the aux laser fiber slightly to accomodate this change, but if there are no other concerns I would like to start this work tomorrow (Wednesday).

Tip-Tilt Redesign Project with Koji:

Did further itirations to the ECD backplate. Going to determine minimum thickness between magnet hole and plus sign for eddy current damping.

Chamber optical table layouts

Finished the positioning of optics and instruments in SolidWorks for the Vertex chambers. The reference for positioning is "40m_upgrade_layout_Dec2012.dwg", and solidworks files I created are in the main 40m CAD folder.

All models on the c1lsc front end were dead. Looking at slow trend data, looks like this happened ~6hours ago. I rebooted c1lsc and now all models are back up and running to their "nominal state".

Jon informed me that there are some EPICS channels that JoeB's camera server code looks for that don't exist. I thought Jigyasa and I had added everything last year but turned out not to be the case. I followed my instructions from here, did the trick. While cleaning up, I also re-named the "*MC1" channels to "*ETMX", since that's where the camera now resides. New channels are:

C1: CAM-ETMX_ARCHIVE_INTERVAL (Archival interval in minutes)
C1: CAM-ETMX_ARCHIVE_RESET (Reset Archival interval in minutes)

C1: CAM-ETMX_CONFIG_FILE (Config file)
 

The model of our martian wifi router (NETGEAR R6400) was found in the FBI router list to be rebooted asociated with the malware "VPNFilter" issue.

I checked the attached devices and found bunch of (legit) devices blocked to access the wifi router. This is not an immediate problem as most of the packets do not go through the wifi router. But potentially a problem in some cases like Wifi enables GPIB adapters. So I marked them to be "allowed".

In this opprtunity, I have updated the firmware of the wifi router and this naturally involved rebooting of the device.

[Koji Gautam]

We talked about touch interface of medm. We realized that android (and iOS) has vnc clients. I just installed VNC viewer on my phone and connected to my mac. Typing is tricky but I managed to get into pianosa, then launched sitemap. We could unlock/lock the IMC by screen touch!

Basically we can connect to one of the laptops (or control machines) from a tablet (either android or ipad). It'd be better to put both in a same network. It'd be great if we have a tablet case with a keyboard so that we can type without blocking the screen.

I though that the "C1LSC_TRIG_MTRX" MEDM screen completely controls the triggring of LSC signals. But today while trying to trigger the X-arm locking servo on AS110 instead of TRX, I found some strange behaviour. Summary of important points:

1. Even though the servo was supposed to be triggered on AS110, the act of me blocking the beam on the EX table destroyed the lock. I verified the correlation between me blocking the beam and the lock being destroyed by repeating the blocking at least 10 times at different locations along the beam path (to make sure I wasn't accidentally clipping the Oplev beam for example).
2. Investigating further, I found that me turning off the TRX signal digitally also deterministically led to the X arm lock being lost. To be clear, the TRX DC element in the trigger matrix was 0.
3. Confirmed that TRX wasn't involved in any way in the locking servo (I was checking for normalization of the PDH error signal by the DC transmission value, but this is not done). To do this, I locked the arm, and then turned all elements corresponding to TRX in the PowNorm matrix to 0. Then I disabled the locking servo and re-enabled it, and the lock was readily re-acquired readily.

All very strange, not sure what's going on here. The simulink model diagram also didn't give me any clues. Need's further investigation.

While Keerthana and johannes were working at the end, I made a little cleaning at the yend. I salvaged large amount of hardware inclding optics, optomechanics. We all together should work on returning them to appropriate locations.

As of now, I have made the codes needed to sweep the marconi frequency for taking the cavity scan data, the photo diode at the y-end is conected to the spectrum analyser already and I also have the finesse simulation of the Ideal Fabry-perot cavity. By seeing my last elog entry, Gautam suggested me that I need to take a different approach for estimating the FSR and TMS value from the Finesse graph. That is, by using least square fit models. Now I am trying to do that and get a better estimate of the error values. Based on my understanding I am dividing this project into various tasks.

1. Getting a better estimate of the error value by using least square fits. Also plotting a graph of frequency Vs mode number and finding the value of Free Spectral Range from its slop.

2. Inserting zernike polynomials to the Finesse simulation and with the help of least square fit, plotting the graph of frequency Vs mode number. Understanding the shifts from the Ideal graph we obtained from step 1. Using this data, plotting the phase map corresponding to this.

3. Repeating step 2 by taking different zernike polynomials and creating a data base which will be useful for the analysis of the real data. This will also prepare me to do the fitting models easily.

4. Collecting data from the IFO and applying these fitting models to it. Finding the set of zernike polynomials which are similar to the actual fugure error of the mirror. Plotting the Phase map corresponding to those zernike polynomials.

If you feel that there is some mistake in the steps, please correct me. It will be really helpful!

Steve mentioned two unlabelled optics were found at EX, relics from the Endtable upgrade.

• One was a 1" 45 deg p-pol optic (Y1-1025-C-45P), it looks a bit scratched.
• The other was a Beam Sampler (BSF10-C).

These are now labelled and forked down on the SP table.

Koji's collection of Yend components put away. I cleaned up the  Xend bench today.

Loadcells, leveling wedge mounts  and related items placed under flowbench cabinet next to Guralp staff.

[jon, gautam]

Jon is doing some characterization of the AUX laser setup for which he wanted only the prompt retroreflection from the SRM on the AS table, so the PSL shutter is closed, and both ITMs and ETMs are misaligned. The prompt reflection from the SRM was getting clipped on something in vacuum - the ingoing beam looked pretty clean, but the reflection was totally clipped, as I think Johannes aligned the input beam with the SRM misaligned. So the input steering of the AUX laser beam into the vacuum, and also the steering onto AS110, were touched... Also, there were all manner of stray, undumped beams from the fiber on the AS table Jon will post photos.

Before we began this work, we found that c1susaux was dead so we rebooted it.

All optics have been re-aligned. Jon/Johannes will elog about the work today.

[Jon, Gautam, Johannes]

Jon spent some time trying to align the AUX beam to the SRC today, I got to the game kind of late so maybe others can add more detail.

The AUX beam that is reflected by the SRM looks terribly misshapen - it is quite elongated in vertical direction. Unfortunately I didn't snap a picture of it - anybody? It seemed at first as if this could be clipping - but after confirming the alignment of the AUX beam with the PSL output beam with aligned SRM, a slow dither of the SRM just moved the ugly pattern on the AS camera with no change to its shape - so clipping is unlikely. I'm now thinking that this is just the output beam of the fiber coupler after propagating ~15 meters to the SRM and back - even though this aspheric lens triplet coupler is supposed to be super-duper. I found that if I loosen the fiber slightly and pull it back just a bit at least the spot on the AS camera becomes nice and round - so maybe the fiber just doesn't sit well in this collimator? Not sure why that would be. I checked the fiber tip with the microscope, and while there was some gunk present, the central region and the core were clear (still cleaned using the fiber cleaning kit, which got rid of the debris). Either way, before switching to a different collimator I think we should give the Guoy phase measurement a shot - after all there was plenty of RF signal present on both AS110 and the PDA10CF placed at the YEND.

Looking for rogue beams on the AS table, I started placing some beam dumps. There was one particularly strong source of stray beams - a lens that was labeled with KPX094AR.33_F100. It became apparent after alignment efforts to the IFO had moved the AUX beam signifcantly off-center on this lens. According to the label it should have an AR coating for 1064nm, however judging by the amount of reflected light, it was certainly NOT AR-coated for 1064nm. I replaced it with a bi-convex f=100mm lens with confirmed AR-behavior.

The AUX laser is currently shuttered.

Per our Wednesday meeting, some items to work on are

• Align the zero-order AUX beam into a second collimator on the PSL table, so we can switch the fiber output and look for RF signals at the offset-phaselock frequency without the additional frequency shift from the AOM. This will simpligy the mode spectroscopy scheme significantly
• Abandon the R10/T90 beamsplitters in favor of R90/T10 beamsplitters. We'll swap the large mirror in front of the AS camera with an R90/T10 BS, and follow it up with a second R90/T10 BS that sends the AUX beam to the IFO. This way we'll have identical power levels on AS110 and AS55, and still 90% of the current AUX light going into the IFO, but without strong secondary beams from R10/T90 optics.