As part of trying to figure out what is going on with the ASS, I wanted to figure out what filters are installed on which lockins.

Each "DoF"(1-6) has a zpk(0.1,0.0001,1)gain(1000), which is a lowpass with 60dB of gain at DC, and unity gain at high frequencies.

For the lockins, since there are so many, I made a spreadsheet to keep track of them (attached). 

So, what's the point?  The point is, I think that all of the LOCKIN_I filter modules should be the same, with a single low pass filter.  The Q filter banks don't matter, since we don't use those signals, and the signals are grounded inside the model.  The phase of each lockin was / should be tuned such that all of the interesting signal goes to I, and nothing goes to Q.  The SIG filter modules seem okay, in that they're all the same, except for their band pass frequency.  I just need to check to see what frequency the ASS scripts are trying to actuate at, to make sure we're bandpassing the correct things.

The following MCL filters were left loaded in the T240-X and T240-Y FF filter modules (filters go in pairs, both on):

FM7: SISO filters for MCL elog:11541

FM8: MISO v1 elog:11547

FM9: MISO v1.1 Small improvement over MISO v1

FM10 MISO v2 elog:11563

FM5 MISO v3.1 elog:11584 (best one)

FM6 MISO 3.1.1 elog:11584 (second best one)

 Thanks Koji , for your  hint for the brain teasing puzzle. I was looking into Filters that are usually used in devices like counters, DSO and other scopes. I found that , to improve the quality of the measurement one of the best approach  is averaging. I looked deeper into averaging and found out this:

There are two general use-cases for averaging . The first, successive sample averaging, takes a single acquisition and averages between its samples. The second, successive capture averaging, combines the corresponding  samples of multiple captures to create a single capture. Successive sample averaging is also called boxcar filtering or moving average filtering. In an implementation of this type of averaging each output sample represents the average value of M consecutive input samples. This type of averaging removes noise (one of the reasons the noise level was not bad: http://nodus.ligo.caltech.edu:8080/40m/10151) by decreasing the device's bandwidth(could be one of the reasons why the FC operates in 4 different frequency ranges). It applies an LPF function with a 3dB point approximated by  0.433 * s / M, where M is the number of samples to be averaged, and s is the sample rate in samples per second. 

Now I tried verifying the 3 dB points in the gain plots I generated :

For 1 s Sampling time : the 3 dB point for such a Boxcar filter should be at 0.433* 1/M. If we assume that it averages for 2 samples, M=2 which gives the 3dB point at 0.288 Hz but occurs somewhere between 0.3 and 0.4 Hz.  (http://nodus.ligo.caltech.edu:8080/40m/140619_120548/GainVsFreq.png)

For 0.1s Sampling time: the 3dB point should be at 2.17 Hz and in reality is 2.5 Hz(http://nodus.ligo.caltech.edu:8080/40m/140701_211904/gain.png).

Also, This type of filter will have very sharp nulls at frequencies corresponding to signals whose periods are integer sub-multiples of M/s. As seen my previous plots (http://nodus.ligo.caltech.edu:8080/40m/10118 , http://nodus.ligo.caltech.edu:8080/40m/10070) there are sharp nulls at frequencies

0.4 Hz for 1S sampling time and

at 1.5 Hz,3 Hz for 0.1 S sampling time as correctly predicted.

The moving average filter is  L-sample moving average FIR, with the frequency response as:   H(ω) = (1/L) (1 − e^{− jω L})/(1 − e^{− jω})..

There is an overall delay of (M - 1)/2 samples from such a length-M causal FIR filter. 

The expected bode plots for such a filter with L= 5 is attached(attachment 2).

The expected bode plots for such a filter with L= 4 is attached and compared with the measured.

RXA: When comparing two things, please put them onto the same plot so that they can be compared.

[Jenne, Yoichi]

The final 2 Tip Tilts (#1 and #5) have been suspended.  We have designated #5 the spare.  It looks like there might be a teensy bit of dust on the AR surface of the optic in #5, right near the edge of the coating.  Not a critical issue if this one is the spare, although we should see if we can blow it off with the Nitrogen.  Both #1 and #5's optics were suspended using the thicker wire, 0.0036" diameter.  This leaves 4/5 TTs with this thick wire, and 1 of the 5 has the thin wire.

To do still: Balance both #1 and #5, and then measure the modes of each.  Then we'll be ready to install them into the chambers, and we'll reserve #5 for shake table TFs for some later date.

[Yuta, Sendhil, Jamie, Jenne, Rana]

1. After the MC centering, we tried to align the IFO using IPPOS and IPANG as reference. This did not recover the alignment perfectly. We were clipping at the BS aperture. Using TTs, we centered the beam at BS and PRM.
2. Using TTs, the beam was centered at ITMY and ETMY.
3. IPPOS and IPANG mirrors in-vacuum were aligned and were centered at the out-of-vacuum optics.
4. We checked the centering of the beam on optics in the BS and ITMY chamber. (Yuta will make an elog with the layout)
5. We retro-reflected ITMY at the BS and aligned ETMY such that we saw a couple of bounces in the arm cavity.
6. Using BS, the beam was steered to go through the center of ITMX and ETMX.
7. At this point we were able to see the MI fringes at the AS port.
8. We made fine alignments to the ITMX such that we saw MI reflected at the Farday.
9. We retro-reflected ITMX and aligned ETMX to see the beam bounce at the ITMX.
10. We aligned PRM such that PRC flashes. But we were not happy with the flashes (they were in higher order modes). We suspect that minor tuning of the input pointing might be necessary.
11. We closed for the day

This is the final version of the QPD circuit I'm going to build. After playing around with the spatial arrangement, this should fit into the box that I was planning to use, although it will be a rather tight fit. The pitch, yaw, and summing circuit will be handled with a quad op amp. Planning to meet with Eric tomorrow to figure out the logistics of building things.

In the meantime, I'm reading about designing the ECDL for my summer project with Tara. He sent me several papers to read so we can talk on Wednesday.

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)

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.

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.

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

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.

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. 

[Yuta, Koji, Paco]

Restarting CDS

We were having some trouble restarting all the models on the FEs. The error was the famous 0x4000 DC error, which has to do with time de-synchronization between fb1 and a given FE. We tried a combination of things haphazardly, such as reloading the gpstime process using

without much success, even when doing this again after hard rebooting FE + IO chassis combinations around the lab. Koji prompted us to check the local times as reported by the gpstime module, and comparing it to network reported times we saw the expected offset of ~ 3.5 s. On a given FE ("c1***") and fb1 separately, we ran:

which meant a couple of things:

1. fb1 was serving its time (broadcast to local (martian) network)
2. fb1 was not getting its time from the internet
3. c1*** was not synchronized even though fb1 was serving the time

By looking at previous elogs with similar issues, we tried two things;

1. First, from the FEs, run sudo systemctl restart systemd-timesyncd to get the FE in sync; this didn't immediately solve anything.
2. Then, from fb1, we tried pinging google.com and failed! The fb1 was not connected to the internet!!!

We tried rebooting fb1 to see if it connected, but eventually what solved this was restarting the bind9 service on chiara! Now we could ping google, and saw this output

meaning fb1 was getting its time served. Going back to the FEs, we still couldn't see the ntp synchronized flag up, but it just took time after a few minutes we saw the FEs in sync! This also meant that we could finally restart all FE models, which we successfully did following the script described in the wiki. Then we had to reload the modbusIOC service in all the slow machines (sometimes this required us to call sudo systemctl daemon-reload) and performed burt restore to a last Friday's snap file collection.

IMC realign and MC1 glitch?

With Koji's help PMC locked, and then Yuta and Paco manually increased the input power to the IFO by rotating the waveplate picomotor to 37.0 deg. After this, we noticed that the MC REFL spot was not hitting the camera, so maybe MC1 was misaligned. Paco checked the AP table and saw the spot horizontally misaligned on the camera, which gave us the initial YAW correction on MC1. After some IMC recovery, we saw only MC1 got spontaneously kicked along both PIT and YAW, making our alignment futile. Though not hard to recover, we wondered why this happened.

We went into the 1X4 rack and pushed MC1 suspension cables in to disregard loose connections, but as we came back into the control room we again saw it being kicked randomly! We even turned damping off for a little while and this random kicking didn't stop. There was no significant seismic motion at the time so it is still unclear of what is happening.

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.

I have temporarily abandoned vectfit and aaa since I've been pretty unsuccessful with them and I don't need poles/zeroes to find the unity gain frequency. Instead I'm just fitting the transfer function linearly (on a log-log scale). I've found the UGF at about 5.5 kHz right now, using old data - next step is to get the Red Pitaya working so I can take data with that. Also need to move this code from matlab to python. Uncertainty's propagated using the 95% confidence bounds given by the fit, using curvefit - so just from the standard error, and all points are weighted equally. Ideally would like to propagate uncertainty accounting for the coherence data too, but haven't figured out how to do that correctly yet.

[UPDATE 7/22/2022: added raw data files]

Am still working on using vectfit to find my zeros/poles of a transfer function - now have a more specific project in mind, which is to have a Red Pitaya use the zero/pole data of the transfer function to find the UGF, so we can check what the UGF is at any given time and plot it as a function of time to see if it drifts (hopefully it doesn't). Wrestled with vectfit more on matlab, found out I was converting from dB's incorrectly (should be 10^(dB/20)....) Intend to read a bit of a book by Bendat and Piersol to learn a bit more about how I should be weighting my vectfit. May also check out an algorithm called AAA for fitting instead.

 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.

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.

A rotation stage has been ordered.

Specification: Newport 481-A

• Sensitivity: 15 arcsec
• Graduations: 1 deg
• Vernier: 5 arcmin
• Fine travel range: 5 deg
• With Micrometer

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

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

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

Analytical 2 - Red Graph

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 .

The Difference plot is also attached below.

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.

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 10¹⁴ Hz and it caliberated as zero.

finesse1.pdffinesse2.pdf

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

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 , 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  but not , 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  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...

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. 

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.

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.

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

** 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)

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

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

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

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.

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.

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.

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

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.

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



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.

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.

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

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

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

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

[Koji, Steve]

First Contact Training with Margot