40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 77 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  15695   Wed Dec 2 17:54:03 2020 gautamUpdateCDSFE reboot

As discussed at the meeting, I commenced the recovery of the CDS status at 1750 local time.

  • Started by attempting to just soft-restart the c1rfm model and see if that fixes the issue. It didn't and what's more, took down the c1sus machine.
  • So hard reboots of the vertex machines was required. c1iscey also crashed. I was able to keep the EX machine up, but I soft-stopped all the RT models on it.
  • All systems were recovered by 1815. For anyone checking, the DC light on the c1oaf model is red - this is a "known" issue and requires a model restart, but i don't want to get into that now and it doesn't disrupt normal operation.

Single arm POX/POY locking was checked, but not much more. Our IMC WFS are still out of service so I hand aligned the IMC a bit, IMC REFL DC went from ~0.3 to ~0.12, which is the usual nominal level.

  4249   Fri Feb 4 13:31:16 2011 josephbUpdateCDSFE start scripts moved to scripts/FE/ from scripts/

All start and kill scripts for the front end models have been moved into the FE directory under scripts:  /opt/rtcds/caltech/c1/scripts/FE/.  I modified the Makefile in /opt/rtcds/caltech/c1/core/advLigoRTS/ to update and place new scripts in that directory. 

This was done by using

sed -i 's[scripts/start$${system}[scripts/FE/start$${system}[g' Makefile

sed -i 's[scripts/kill$${system}[scripts/FE/kill$${system}[g' Makefile

  1308   Mon Feb 16 10:18:13 2009 AlbertoUpdateLSCFE system rebooted

Quote:

Quote:

I didn't get a chance to do much testing since the sus controller (susvme1) went nuts. In retrospect, this could be due to something in the script, so maybe we should try a burt restore to Friday afternoon next time someone wants to look at it.


I tried the burtrestore today, it didn't work. Also tried some switching of timing cables, and multiple reboots, to no avail. This will require some more debugging. We might try diagnosing the clock driver and fanout modules, the penteks, and we can also try rebooting the whole FE system.


I rebooted the whole FE system and now c1susvme1 and c1susvme2 are back on.

I can't restart the MC autolocker on c1susvme2 because it doesn't let me ssh in. I tried to reboot it a few times but it didn't work. Once you restart it, it becomes inaccessible and doesn't even respond to pinging. Although the controls for the MC mirrors are on.

The mode cleaner stays unlocked.
  1309   Mon Feb 16 14:12:21 2009 YoichiUpdateLSCFE system rebooted

Quote:

I can't restart the MC autolocker on c1susvme2 because it doesn't let me ssh in. I tried to reboot it a few times but it didn't work. Once you restart it, it becomes inaccessible and doesn't even respond to pinging. Although the controls for the MC mirrors are on.

The mode cleaner stays unlocked.


MC autolocker runs on op340m, not on c1susvme2.
I restarted it and now MC locks fine.
Before that, I had to reboot c1iool0 and restore the alignment of the MC mirrors (for some reason, burt did not restore the alignment properly, so I used conlog).
  15998   Tue Apr 6 11:13:01 2021 JonUpdateCDSFE testing

I/O chassis assembly

Yesterday I installed all the available ADC/DAC/BIO modules and adapter boards into the new I/O chassis (c1bhd, c1sus2). We are still missing three ADC adapter boards and six 18-bit DACs. A thorough search of the FE cabinet turned up several 16-bit DACs, but only one adapter board. Since one 16-bit DAC is required anyway for c1sus2, I installed the one complete set in that chassis.

Below is the current state of each chassis. Missing components are highlighted in yellow. We cannot proceed to loopback testing until at least some of the missing hardware is in hand.

C1BHD

Component Qty Required Qty Installed
16-bit ADC 1 1
16-bit ADC adapter 1 0
18-bit DAC 1 0
18-bit DAC adapter 1 1
16-ch DIO 1 1

C1SUS2

Component Qty required Qty Installed
16-bit ADC 2 2
16-bit ADC adapter 2 0
16-bit DAC 1 1
16-bit DAC adapter 1 1
18-bit DAC 5 0
18-bit DAC adapter 5 5
32-ch DO 6 6
16-ch DIO 1 1

Gateway for remote access

To enable remote access to the machines on the test stand subnet, one machine must function as a gateway server. Initially, I tried to set this up using the second network interface of the chiara clone. However, having two active interfaces caused problems for the DHCP and FTS servers and broke the diskless FE booting. Debugging this would have required making changes to the network configuration that would have to be remembered and reverted, were the chiara disk to ever to be used in the original machine.

So instead, I simply grabbed another of the (unused) 1U Supermicro servers from the 1Y1 rack and set it up on the subnet as a standalone gateway server. The machine is named c1teststand. Its first network interface is connected to the general computing network (ligo.caltech.edu) and the second to the test-stand subnet. It has no connection to the Martian subnet. I installed Debian 10.9 anticipating that, when the machine is no longer needed in the test stand, it can be converted into another docker-cymac for to run additional sim models.

Currently, the outside-facing IP address is assigned via DHCP and so periodically changes. I've asked Larry to assign it a static IP on the ligo.caltech.edu domain, so that it can be accessed analogously to nodus.

  1038   Fri Oct 10 00:34:52 2008 robOmnistructureComputersFEs are down

The front-end machines are all down. Another cosmic-ray in the RFM, I suppose. Whoever comes in first in the morning should do the all-boot described in the wiki.
  1039   Fri Oct 10 10:20:42 2008 AlbertoOmnistructureComputersFEs are down

Quote:

The front-end machines are all down. Another cosmic-ray in the RFM, I suppose. Whoever comes in first in the morning should do the all-boot described in the wiki.


Yoichi and I went along the arms turning off and on all the FE machines. Then, from the control room we rebooted them all following the procedures in the wiki. Everything is now up again.

I restored the full IFO, re-locked the mode cleaner.
  13385   Tue Oct 17 23:07:52 2017 gautamUpdateCDSFEs unresponsive

While working on the IFO tonight, I noticed that the blinky status lights on c1iscex and c1iscey were frozen (but those on the other 3 FEs seemed fine). But all other lights on the CDS overview screen were green I couldn't access testpoints from these machines, and the EPICS readbacks for models on these FEs (e.g. Oplev servo inputs outputs etc) were frozen at some fixed value. This lasted for a good 5 minutes at least. But the blinky lights started blinking again without me doing anything. Not sure what to make of this. I am also not sure how to diagnose this problem, as trending the slow EPICS records of the CPU execution cycle time (for example) doesn't show any irregularity.

  13386   Wed Oct 18 01:41:32 2017 jamieUpdateCDSFEs unresponsive
Quote:

While working on the IFO tonight, I noticed that the blinky status lights on c1iscex and c1iscey were frozen (but those on the other 3 FEs seemed fine). But all other lights on the CDS overview screen were green I couldn't access testpoints from these machines, and the EPICS readbacks for models on these FEs (e.g. Oplev servo inputs outputs etc) were frozen at some fixed value. This lasted for a good 5 minutes at least. But the blinky lights started blinking again without me doing anything. Not sure what to make of this. I am also not sure how to diagnose this problem, as trending the slow EPICS records of the CPU execution cycle time (for example) doesn't show any irregularity.

So this wasn't just an EPICS freeze?  I don't see how this had anything to do with any of the work I did earlier today.  I didn't modify any of the running front ends, didn't touch either of the end station machines or the DAQ, and didn't modify the network in any way.  I didn't leave anything running.

If you couldn't access test points then it sounds like it was more than just EPICS.  It sounds like maybe the end machines somehow fell of the network momentarily.  Was there anything else going on at the time?

  13387   Wed Oct 18 02:09:32 2017 gautamUpdateCDSFEs unresponsive

I was looking at the ASDC channel on dataviewer, and toggling various settings like whitening gain. At some point, the signal just froze. So I quit dataviewer and tried restarting it, at which point it complained about not being able to connect to FB. This is when I brought up the CDS_OVERVIEW medm screen, and noticed the frozen 1pps indicator lights. There was certainly something going on with the end FEs, because I was able to ping the machine, but not ssh into it. Once the 1pps lights came back, I was able to ssh into c1iscex and c1iscey, no problems.

Could it be that some of the mx processes stalled, but the systemctl routine automatically restarted them after some time? 

Quote:

So this wasn't just an EPICS freeze?  I don't see how this had anything to do with any of the work I did earlier today.  I didn't modify any of the running front ends, didn't touch either of the end station machines or the DAQ, and didn't modify the network in any way.  I didn't leave anything running.

If you couldn't access test points then it sounds like it was more than just EPICS.  It sounds like maybe the end machines somehow fell of the network momentarily.  Was there anything else going on at the time?

 

  13388   Wed Oct 18 09:21:22 2017 jamieUpdateCDSFEs unresponsive
Quote:

I was looking at the ASDC channel on dataviewer, and toggling various settings like whitening gain. At some point, the signal just froze. So I quit dataviewer and tried restarting it, at which point it complained about not being able to connect to FB. This is when I brought up the CDS_OVERVIEW medm screen, and noticed the frozen 1pps indicator lights. There was certainly something going on with the end FEs, because I was able to ping the machine, but not ssh into it. Once the 1pps lights came back, I was able to ssh into c1iscex and c1iscey, no problems.

Could it be that some of the mx processes stalled, but the systemctl routine automatically restarted them after some time?

An mx_stream glitch would have interrupted data flowing from the front end to the DAQ, but it wouldn't have affected the heartbeat.  The heartbeat stop could mean either that the front end process froze, or the EPICS communication stopped.  The fact that everything came back fine after a couple of minutes indicates to me that the front end processes all kept running fine.  If they hadn't I'm sure the machines would have locked up.  The fact that you couldn't connect to the FE machine is also suspicious.

My best guess is that there was a network glitch on the martian network.  I don't know how to account for the fact that pings still worked, though.

  13394   Wed Oct 18 23:11:53 2017 gautamUpdateCDSFEs unresponsive

This happened again just now - it was roughly this time when this happened last night as well.

There was certainly an EPICS freeze of the kind we were used to seeing prior to replacing the martian wireless router sometime in late 2015 (or early 2016?). I was trying to run the dither alignment servos on the Y-arm at this time, and all the StripTool traces flatlined.

I took the opportunity to try accessing testpoints from the iscey ADCs - specifically C1:SUS-TRY_OUT, and it seemed to work just fine. However, I couldn't ssh into c1iscey.

Looking at the dmesg once I was able to ssh in eventually (~2 minutes deadtime tonight, I feel like it was longer yesterday but can't quantify), I see the following: not sure if there are any clues in here, or whether this is the correct log to check. But there are many instances of the nfs server related message in the log. Note that the system time-stamp corresponds to when this freeze happened.

[5461308.784018] nfs: server 192.168.113.201 not responding, still trying
[5461412.936284] nfs: server 192.168.113.201 OK
[5461412.937130] systemd[1]: Starting Journal Service...
[5461412.947947] systemd-journald[20281]: Received SIGTERM from PID 1 (systemd).
[5461412.996063] systemd[1]: Unit systemd-journald.service entered failed state.
[5461413.002627] systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
[5461413.008983] systemd[1]: Stopping Journal Service...
[5461413.014664] systemd[1]: Starting Journal Service...
[5461413.044262] systemd[1]: Started Journal Service.
[5461413.694838] systemd-journald[400]: Received request to flush runtime journal from PID 1

 

  13124   Wed Jul 19 00:59:47 2017 gautamUpdateGeneralFINESSE model of DRMI (no arms)

Summary:

I've been working on improving the 40m FINESSE model I set up sometime last year (where the goal was to model various RC folding mirror scenarios). Specifically, I wanted to get the locking feature of FINESSE working, and also simulate the DRMI (no arms) configuration, which is what I have been working on locking the real IFO to. This elog is a summary of what I have from the last few days of working on this.

Model details:

  • No IMC included for now.
  • Core optics R and T from the 40m wiki page.
  • Cavity lengths are the "ideal" ones - see the attached ipynb for the values used.
  • RF modulation depths from here. But for now, the relative phase between f1 and f2 at the EOM is set to 0.
  • I've not included flipped folding mirrors - instead, I put a loss of 0.5% on PR3 and SR3 in the model to account for the AR surface of these optics being inside the RCs. 
  • I've made the AR surfaces of all optics FINESSE "beamsplitters" - there was some discussion on the FINESSE mattermost channel about how not doing this can lead to slightly inaccurate results, so I've tried to be more careful in this respect.
  • I'm using "maxtem 1" in my FINESSE file, which means TEM_mn modes up to (m+n=1) are taken into account - setting this to 0 makes it a plane wave model. This parameter can significantly increase the computational time. 

Model validation:

  • As a first check, I made the PRM and SRM transparent, and used the in-built routines in FINESSE to mode-match the input beam to the arm cavities.
  • I then scanned one arm cavity about a resonance, and compared the transmisison profile to the analytical FP cavity expression - agreement was good.
  • Next, I wanted to get a sensing matrix for the DRMI (no arms) configuration (see attached ipynb notebook).
    • First, I make the ETMs in the model transparent
    • I started with the phases for the BS, PRM and SRM set to their "naive" values of 0, 0 and 90 (for the standard DRMI configuration)
    • I then scanned these optics around, used various PDs to look at the points where appropriate circulating fields reached their maximum values, and updated the phase of the optic with these values.
    • Next, I set the demod phase of various RFPDs such that the PDH error signal is entirely in one quadrature. I use the RFPDs in pairs, with demod phases separated by 90 degrees. I arbitrarily set the demod phase of the Q phase PD as 90 + phase of I phase PD. I also tried to mimic the RFPD-IFO DoF pairing that we use for the actual IFO - so for example, PRCL is controlled by REFL11_I.
    • Confident that I was close enough to the ideal operating point, I then fed the error signals from these RFPDs to the "lock" routine in FINESSE. The manual recommends setting the locking loop gain to 1/optical gain, which is what I did.
    • The tunings for the BS and RMs in the attached kat file are the result of this tuning.
    • For the actual sensing matrix, I moved each of PRM, BS and SRM +/-5 degrees (~15nm) around each resonance. I then computed the numerical derivative around the zero crossing of each RFPD signal, and then plotted all of this in some RADAR plots - see Attachment #1.

Explanation of Attachments and Discussion:

  • Attachment #1 - Computed sensing matrix from this model. Compare to an actual measurement, for example here - the relative angle between the sensing matrix elements dont exactly line up with what is measured. EQ suggested today that I should look into tuning the relative phase between the RF frequencies at the EOM. Nevertheless, I tried comparing the magnitudes of the MICH sensing element in AS55 Q - the model tells me that it should be ~7.8*10^5 W/m. In this elog, I measured it to be 2.37*10^5 W/m. On the AS table, there is a 50-50 BS splitting the light between the AS55 and AS110 photodiodes which is not accounted for in the model. Factoring this in, along with the fact that there are 6 in-vaccuum steering mirrors (assume 98% reflectivity for these), 3 in air steering mirrors, and the window, the sensing matrix element from the model starts to be in the same ballpark as the measurement, at ~3*10^5 W/m. So the model isn't giving completely crazy results.
  • Attachment #2 - Example of the signals at various RFPDs in response to sweeping the PRM around its resonance. To be compared with actual IFO data. Teal lines are the "I" phase, and orange lines are "Q" phase.
  • Attachment #3 - FINESSE kat file and the IPython notebook I used to make these plots. 
  • Next steps
    • More validation against measurements from the actual IFO.
    • Try and resolve differences between modeled and measured sensing matrices.
    • Get locking working with full IFO - there was a discussion on the mattermost thread about sequential/parallel locking some time ago, I need to dig that up to see what is the right way to get this going. Probably the DRMI operating point will also change, because of the complex reflectivities of the arm cavities seen by the RF sidebands (this effect is not present in the current configuration where I've made the ETMs transparent).

GV Edit: EQ pointed out that my method of taking the slope of the error signal to compute the sensing element isn't the most robust - it relies on choosing points to compute the slope that are close enough to the zero crossing and also well within the linear region of the error signal. Instead, FINESSE allows this computation to be done as we do in the real IFO - apply an excitation at a given frequency to an optic and look at the twice-demodulated output of the relevant RFPD (e.g. for PRCL sensing element in the 1f DRMI configuration, drive PRM and demodulate REFL11 at 11MHz and the drive frequenct). Attachment #4 is the sensing matrix recomputed in this way - in this case, it produces almost identical results as the slope method, but I think the double-demod technique is better in that you don't have to worry about selecting points for computing the slope etc. 

 

Attachment 1: DRMI_sensingMat.pdf
DRMI_sensingMat.pdf
Attachment 2: DRMI_errSigs.pdf
DRMI_errSigs.pdf
Attachment 3: 40m_DRMI_FINESSE.zip
Attachment 4: DRMI_sensingMat_19Jul.pdf
DRMI_sensingMat_19Jul.pdf
  10226   Thu Jul 17 02:57:32 2014 AndresUpdate40m Xend Table upgradeFInish Calculation on Current X-arm mode Matching

Data and Calculation for the Xarm Current Mode Matching

Two days ago, Nick, Jenne, and I took a measurement for the Green Transmission for the X-arm. I took the data and I analyzed it. The first figure attached below is the raw data plotted. I used the function findpeaks in Matlab, and I found all the peaks. Then, by taking close look at the plot, I chose two peaks as shown in the second figure attached below. I took the ratio of the TEM00 and the High order mode, and I average them. This gave me a Mode Matching of 0.9215, which this value is pretty close to the value that I predicted by using a la Mode in http://nodus.ligo.caltech.edu:8080/40m/10191, which is 0.9343. Nick and I measured the reflected power when the cavity is unlocked and when the cavity is locked, so we measured the PreflUnLocked=52+1µW and PreflOnLocked=16+2µW and the backgroundNoise=0.761µW. Using this information we calculated  Prefl/Pin=0.297. Now, since Prefl/Pin=|Eref/Ein|2, we looked at the electric fields component by using the reflectivity of the mirror we calculated 0.67. The number doesn't agree, but this is because we didn't take into account the losses when making this calculation. I'm working in the calculation that will include the losses.

Today, Nick and I ordered the lenses and the mirrors. I'm working in putting together a representation of how much improvement the new design will give us in comparison to the current setup.

Attachment 1: RawDataForTheModeGreenScan.png
RawDataForTheModeGreenScan.png
Attachment 2: ResultForModeMatching.png
ResultForModeMatching.png
Attachment 3: DataAndCalculationOfModeMismatch.zip
  10237   Fri Jul 18 16:52:56 2014 AndresUpdate40m Xend Table upgradeFInish Calculation on Current X-arm mode Matching

Quote:

Data and Calculation for the Xarm Current Mode Matching

Two days ago, Nick, Jenne, and I took a measurement for the Green Transmission for the X-arm. I took the data and I analyzed it. The first figure attached below is the raw data plotted. I used the function findpeaks in Matlab, and I found all the peaks. Then, by taking close look at the plot, I chose two peaks as shown in the second figure attached below. I took the ratio of the TEM00 and the High order mode, and I average them. This gave me a Mode Matching of 0.9215, which this value is pretty close to the value that I predicted by using a la Mode in http://nodus.ligo.caltech.edu:8080/40m/10191, which is 0.9343. Nick and I measured the reflected power when the cavity is unlocked and when the cavity is locked, so we measured the PreflUnLocked=52+1µW and PreflOnLocked=16+2µW and the backgroundNoise=0.761µW. Using this information we calculated  Prefl/Pin=0.297. Now, since Prefl/Pin=|Eref/Ein|2, we looked at the electric fields component by using the reflectivity of the mirror we calculated 0.67. The number doesn't agree, but this is because we didn't take into account the losses when making this calculation. I'm working in the calculation that will include the losses.

Today, Nick and I ordered the lenses and the mirrors. I'm working in putting together a representation of how much improvement the new design will give us in comparison to the current setup.

We want to be able to graphically see how much better it is the new optical table setup in comparison to the current optical table setup. In other words, we want to be able to see how displacement of the beam and how much angle change can be obtained at the ETM from changing the mirrors angles independently. Depending on the spread of the mirrors' vectors we can observe whether the Gouy phase is good. In the plot below, the dotted lines correspond to the current set up, and we can see that the lines are not spread from each other, which essentially mean that changing the angles of the two mirrors just contribute to small change in angle and in the displacement of the beam at the ETM, and therefore the Gouy phase is not good. Now on the other hand. The other solid lines correspond to the new setup mirrors. We can observe that the spread of the line of mirror 1 and mirror 4 is almost 90 degrees, which just implies that there is a good Gouy phase different between these two mirrors. For the angles chosen in the plot, I looked at how much the PZT yaw the mirrors from the elog http://nodus.ligo.caltech.edu:8080/40m/8912. In this elog, they give a plot in mrad/v for the pitch and yaw, so I took the range that the PZT can yaw the mirrors, and I converted into mdegrees/v and then I plotted as shown below. I plot for the current setup and for the new setup in the same plot. The matlab code is also attached below.

Attachment 1: OldAndNewSetupPlotsOfDisplacementAndAngleAtTheETM.png
OldAndNewSetupPlotsOfDisplacementAndAngleAtTheETM.png
Attachment 2: OldSetUpDisplacementAndNewSetup.m.zip
  1498   Mon Apr 20 05:18:42 2009 YoichiConfigurationLockingFM6 and FM10 of LSC-MC were restored
During tonight's locking work, I realized that FM6 and FM10 (both resonant gains around 20Hz) were actually activated by cm_step.
So I restored those filters from the svn history.
Instead, I removed a bunch of unused filters from LSC-DEMOD and LSC-DEMOD_A (moving zero filters) to off load c1lsc.

As for the locking itself, the DARM loop becomes unstable at around arm power = 30. I may have to add a filter to give a broader phase bubble.
  10273   Fri Jul 25 17:28:31 2014 HarryUpdateGeneralFOL Box and PER Update

 Purpose

We're putting together a box to go into the 1X2 rack, to facilitate the frequency counters, and Raspberry Pi that will be used in FOL.

Separately, I am working on characterizing the Polarization Extinction Ratio of the PM980 fibers, for further use in FOL.

What's Been Done

The frequency counters have been mounted on the face of the box, and nylon spacers installed in the bottom, which will insulate the RPi in the future, once it's finally installed.

FOLBox.png

In regard to the PER setup, there is an issue, in that the mounts which hold the collimators rotate, so as to align the axes of the fibers with the polarization of the incoming light.

This rotational degree of freedom, however, isn't "sticky" enough, and rotates under the influence of the stress in the fiber. (It's not much, but enough.)

This causes wild fluctuations in coupled power, making it impossible to make accurate measurements of PER.

What's Next

In the FOL box's case, we've ordered a longer power cable for the raspberry pi (the current one is ~9 inches long).

Once it arrives, we will install the RPi, and move the box into its place in the rack.

In the case of the PER measurement, we've ordered more collimator mounts//adapters, which will hopefully give better control over rotation.

 

  10376   Wed Aug 13 16:12:55 2014 HarryUpdateGeneralFOL Layout Diagram

Per Q's request, I've made up a diagram of the complete FOL layout for general reference.

FOLLayout2.png

  10352   Fri Aug 8 14:27:18 2014 AkhilUpdateComputer Scripts / ProgramsFOL Scripts

 The scripts written for interfacing the FC with R Pi, building EPICS database, piping data into EPICS channels,PID loop for FOL are contained in :

 /opt/rtcds/caltech/c1/scripts/FOL 

The instructions to run these codes on R Pi( controls@domenica) will be available on FOL 40m wiki page.

Also instructions regarding EPICS installation on R Pi and building an EPICS SoftIoc to streamline data from hardware devices into channels will be updated shortly.

 

 

 

 

 

 

  11102   Thu Mar 5 12:27:27 2015 manasaUpdateGeneralFOL fiber box on the PSL table

Working around the PSL table

I have put the FOL fiber box on the PSL table. The fibers carrying AUX and PSL light are connected and the RFPDs have been powered up. I can see the beat frequency on the frequency counters; but for some reason Domenica (that brings the frequency counter values on the medm screens) is not visible on the network even after hard reboot of the raspberry pi. I am neither able to ping nor ssh into the machine. I have to pull the module out and add a monitor cable to troubleshoot (my bad frownI should have left the monitor cable with the raspberry pi in the first place). Anyways, I have handed over the IFO to Q and will play with things again sometime later.

The fiber box on the PSL table is only left there temporariliy till I have things working. It will be stowed on the rack properly later.

In case someone wants the fiber box out of the PSL table, please make sure to power down the RFPDs using the black rocker switches on the side of the box and then disconnect the cables and fibers.

  11650   Tue Sep 29 19:38:09 2015 gautamUpdateGeneralFOL fiber box revamp

The new 2x2 fiber couplers arrived today so Eric gave me an overview on the changes to be made to the existing configuration of the FOL fiber box. I removed the box from the table after ensuring that the PDs were powered OFF and removing and capping all fiber leads on the front panel. Here is a summary of the changes made.

  • On-Off positions for the rocker switches corrected - these switches for the power to the PDs were installed such that the "1" position was OFF. I flipped both the switches such that the "1" position now corresponds to ON (see Attachment #1).
  • All the couplers/beam combiners/splitters were initially removed. 
  • I then re-configured the layout as per the schematic (Attachment #2). I only needed to use one of the 4 new 2x2 couplers ordered. I think the 1x2 couplers are appropriate for mixing the PSL and AUX beams, as if we use a 2x2 coupler, half of the mixed light goes nowhere? Indeed, if we had one more such coupler, we could do away with the 2x2 coupler I am now using to divide the PSL light into two. 
  • The spec-sheets on the inside of the top cover were updated to reflect the new hardware (Attachment #3).
  • The old hardware from the box that was not used, along with their spec-sheets, are stored temporarily in a Thorlabs lab snacks box (all the fibers have been capped).
  • The finished layout is shown in Attachment #4.

I then ran a quick check to see what the power levels were at the input to the PDs, using the fiber coupled power meter. However, I found that there was no light in the fiber marked "PSL light in" (the power meter read out "Sig. Low"). The X arm Aux light had an input power of 1.12 mW, which after the various coupling losses etc went down to 63 uW just before the PD. The corresponding figures for the Y arm are 200 uW and 2.2 uW. I am not too sure of how the AUX light is coupled into fibers so I am not trying to tweak the alignment to see if I get more power. 

Attachment 1: IMG_0017.JPG
IMG_0017.JPG
Attachment 2: FOL_schematic.pdf
FOL_schematic.pdf
Attachment 3: IMG_0018.JPG
IMG_0018.JPG
Attachment 4: IMG_0016.JPG
IMG_0016.JPG
  11652   Wed Sep 30 13:07:13 2015 gautamUpdateGeneralFOL fiber box revamp

Eric pointed out that the 1x2 couplers that were used in the previous arrangement and which I recycled, were in fact NOT appropriate - they are not 50-50 couplers but 90-10 couplers, which explains the measured power levels I quoted here.

I switched out these for a pair of the newly arrived 2x2 couplers, and have also replaced the datasheets on the inside of the top cover. I then redid the power level measurements, and got some sensible values this time (see Attachment #1 for revised layout and measured power levels, numbers in red are powers for PSL light, numbers in green are for AUX laser light, and all numbers are in mW). I did find that the 90-10 splitter in the PSL+Y path was not working (though the one in the PSL+X path seems to be working fine), and hence, have not quoted power levels at the output of these splitters. For now, I guess we can bypass the splitters and take the PSL+AUX light from the 2x2 couplers directly to the PDs.

Attachment 1: FOL_schematic.pdf
FOL_schematic.pdf
  11670   Tue Oct 6 16:56:40 2015 gautamUpdateGeneralFOL fiber box revamp

[gautam, ericq]

We had a look at the IR beat (PSL+Xarm) today using the new FOL fiber box, and compared it to the green beat signal for the same combination. We first switched out the green Y beat input into the RF amplifiers on the PSL table with the PSL+Xarm IR beat input (so in all the plots, the BEATY channels really correspond to the IR beat for PSL+X). The IR and green beat notes were found without much difficulty, and we compared the beat signal PSDs for the green and IR signals (see Attachment #1 - arms were locked to green and the X slow control was turned on). The pink trace (labeled REF1) corresponds to the green beat signal, and was in good agreement with an earlier reference trace Eric had saved for the same signal. The teal trace (labeled REF0) corresponds to the the IR beat signal monitored simultaneously. 

We then went back to the PSL table to check the amplitude of the signal from the broadband fiber PDs using the Agilent network analyzer. An initial measurement yielded a beat note (@~50MHz) at ~-22dbm (17mV rms). We figured that by bypassing the 90-10 splitter in this path, we could get a stronger signal. But after switching out the fiber connections we found that the signal amplitude had fallen to ~-27dbm (10mV rms). As per my earlier measurements here, we expect ~600uW of light on the PD, and a quick calculation suggested the signal should be more like 60mV, so we used the fiber power meter to check the power levels after each of the couplers again. We then found that the fiber connector on the front panel of the box for the PSL input wasnt ideal (the laser power after the first 50-50 coupler was only ~250 uW, though the input was ~1.2  mW). The power after the first coupler also fluctuated unpredictably (<100 uW to 350 uW) in response to slightly tightening/loosening the fiber connections on the front panel. I then switched the PSL input to one of the two unused fiber connectors on the front panel (meant for the 10% of the beat signal for the DC readout), and found that this input behaved much better, with ~450 uW of power available after the first 50-50 coupler. The power going into the beat PD was also measured to be ~550uW, closer to what was expected. The beat signal peak now was ~-14dbm (~30mV rms).

We then once again repeated the comparison between green and IR beat signals - but while in the control room, I noticed that the beat signal amplitude on the network analyzer in the control room was fluctuating by nearly 1.5 divisions on the vertical scale - not sure what the reason for this is. A look at the PSD of the IR beat with higher power incident on the PD was also not encouraging (see blue trace in Attachment #1), it seems to have gotten worse in the 10-30 Hz range. We also looked at the coherence between the beat spectrum and the beat note amplitude in order to look for any linear coupling between the two, but from Attachment #2, we cannot explain the disparity between the green and IR beat spectra. This warrants further investigation.

Everything on the PSL table has now been restored to the configurations before these investigations (i.e. the Y+PSL green beat cable has been reconnected to the RF amplifier, and both green beat PDs have been powered back ON. The fiber PDs are powered OFF) 

Attachment 1: 20151006_Xbeat_psd.pdf
20151006_Xbeat_psd.pdf
Attachment 2: 20151006_Xbeat_coherence.pdf
20151006_Xbeat_coherence.pdf
  11110   Fri Mar 6 14:29:59 2015 manasaUpdateGeneralFOL troubleshooting

[EricQ, Manasa]

Domenica:
Since Domenica was not picking up an IP address and hence not responding to pings or ssh even after power cycling, I pulled it out from the IOO rack and connected it to a monitor. After a bunch of hit and trials, we figured out that the problem was related to the power adapter of the Rpi discussed here : http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=39055

The power adapter has been swapped and this issue has been resolved. Domenica has been remounted on the IOO rack but left with the top lid off for the timebeing.

RF amplifier box:
The frequency counter was setup to read the beat frequency after amplification of the RFPD signals. The output as seen on the frequency counter screen as well as the epics values was intermittent. Also, locking the arms and changing the end laser frequencies did not change the frequency counter outputs. It looks like the RF amplifier is oscillating (Oscillating frequencies were ~107 MHz and 218 MHz) and the input circuit needs to be modified and the connections need better insulation.

As of now, I have connected the RFPD outputs to the frequency counter sans any amplification and we are able to get a readout of the beat frequency at > 40MHz (Frequency counter requires much higher amplitude signals for frequencies lower than that).

  11123   Mon Mar 9 14:43:31 2015 manasaUpdateGeneralFOL troubleshooting

Figuring out the problem with frequency counter readouts:

RF amplifier box:
The frequency counter was setup to read the beat frequency after amplification of the RFPD signals. The output as seen on the frequency counter screen as well as the epics values was intermittent. Also, locking the arms and changing the end laser frequencies did not change the frequency counter outputs. It looks like the RF amplifier is oscillating (Oscillating frequencies were ~107 MHz and 218 MHz) and the input circuit needs to be modified and the connections need better insulation.

As of now, I have connected the RFPD outputs to the frequency counter sans any amplification and we are able to get a readout of the beat frequency at > 40MHz (Frequency counter requires much higher amplitude signals for frequencies lower than that).

The frequency counter has 4 ranges of operation: 
Range 1 : 1 - 40MHz
Range 2: 40 - 190MHz
Range 3: 190 - 1400MHz  
Range 4: 1400 - 6000MHz

I set up the beat frequency readout in various configurations to troubleshoot and have recorded my observation (attachments). The amplifiers in all cases is just a single ZFL-500LN.

There seems to be a problem with the RF amplifier and the frequency counter when they are set together. I am not able to figure it out and stuck right here sad

Attachment 1: schematic for readout and corresponding observations

Attachment 2: Oscilloscope screen snapshot for schematic 3

Attachment 3: Spectrum analyzer screen snapshot for schematic 3

More info: RFPD used is Thorlabs FPD310 and frequency counter is Mini Circuits UFC-6000. The RF amplifier has decoupling capacitors soldered across the power supply.

Attachment 1: FOL_trouble.pdf
FOL_trouble.pdf
Attachment 2: IMAG0341.jpg
IMAG0341.jpg
Attachment 3: IMAG0342.jpg
IMAG0342.jpg
  11128   Tue Mar 10 17:48:07 2015 manasaUpdateGeneralFOL troubleshooting

[Koji, Manasa]

This problem was solved by changing the Frequency Counter range settings.

Frequency counter automatic range setting has been modified and now the range can be manually set depending on the input frequency. New codes have been written to do this. The scripts will be polished and wrapped up shortly.

Quote:

Figuring out the problem with frequency counter readouts:

RF amplifier box:
The frequency counter was setup to read the beat frequency after amplification of the RFPD signals. The output as seen on the frequency counter screen as well as the epics values was intermittent. Also, locking the arms and changing the end laser frequencies did not change the frequency counter outputs. It looks like the RF amplifier is oscillating (Oscillating frequencies were ~107 MHz and 218 MHz) and the input circuit needs to be modified and the connections need better insulation.

As of now, I have connected the RFPD outputs to the frequency counter sans any amplification and we are able to get a readout of the beat frequency at > 40MHz (Frequency counter requires much higher amplitude signals for frequencies lower than that).

The frequency counter has 4 ranges of operation: 
Range 1 : 1 - 40MHz
Range 2: 40 - 190MHz
Range 3: 190 - 1400MHz  
Range 4: 1400 - 6000MHz

I set up the beat frequency readout in various configurations to troubleshoot and have recorded my observation (attachments). The amplifiers in all cases is just a single ZFL-500LN.

There seems to be a problem with the RF amplifier and the frequency counter when they are set together. I am not able to figure it out and stuck right here sad

Attachment 1: schematic for readout and corresponding observations

Attachment 2: Oscilloscope screen snapshot for schematic 3

Attachment 3: Spectrum analyzer screen snapshot for schematic 3

More info: RFPD used is Thorlabs FPD310 and frequency counter is Mini Circuits UFC-6000. The RF amplifier has decoupling capacitors soldered across the power supply.

 

  11135   Wed Mar 11 19:48:25 2015 KojiUpdateGeneralFOL troubleshooting

There is a frequency counter code written by the summer student.
The code needed some cleaning up.
It's still there in /opt/rtcds/caltech/c1/scripts/FOL as armFC.c

This code did not provide unified way to send commands to the FCs.
Therefore I made a code to change the frequency range of the FCs
by removing unused variables and instructions, adding more comments,
adding reasonable help messages and trouble shooting feedbacks.

Obviously these codes only run on domenica (raphsberry Pi host)


/opt/rtcds/caltech/c1/scripts/FOL/change_frange

change_frange : change the freq range of the frequency counter UFC-6000

Usage: ./change_frange DEVICE VALUE
    DEVICE: '/dev/hidraw0' for Xarm, '/dev/hidraw1' for Yarm
    VALUE:
0 - automatic
1 -    1MHz to   40MHz
2 -   40MHz to  190MHz
3 -  190MHz to 1400MHz
4 - 1400MHz to 6000MHz

  11137   Thu Mar 12 11:57:38 2015 KojiUpdateGeneralFOL troubleshooting

BTW, during this trouble shoot, we looked at the IR beatnote spectrum between the Xend and the PSL.
It showed a set of sidebands at ~200kHz, which is the modulation frequency.
There was another eminent component present at ~30kHz.
I'm afraid that there is some feature like large servo bump, a mechanical resonance, or something else, at 30kHz.

We should check it. Probably it is my job.

  835   Thu Aug 14 15:51:35 2008 josephbSummaryCamerasFOUND! The Missing Standoff!
We used a zoom lens on the GC750 to take this picture of the standoff while inside a plastic rubber-glove bag. The standoff with bag is currently scotch-taped to the periodic table of the elements.
Attachment 1: standoff.png
standoff.png
  4180   Thu Jan 20 22:17:12 2011 ranaSummaryLSCFPMI Displacement Noise

I found this old plot in an old elog entry of Osamu's (original link).

It gives us the differential displacement noise of the arms. This was made several months after we discovered how the STACIS made the low frequency noise bad, so I believe it is useful to use this to estimate the displacement noise of the arm cavity today. There are no significant seismic changes. The change of the suspension and the damping electronics may produce some changes around 1 Hz, but these will be dwarfed by the non-stationarity of the seismic noise.

Attachment 1: osamu-1140657006.pdf
osamu-1140657006.pdf
  17089   Thu Aug 18 14:49:35 2022 YehonathanSummaryLSCFPMI Sensitivity

{Yuta, Yehonathan}

We wrote a notebook found on Git/40m/measurements/LSC/FPMI/NoiseBudget/FPMISensitivity.ipynb for calculating the MICH, DARM (currently XARM), CARM (currently YARM) sensitivities in the FPMI lock which can be run daily.

The IN and OUT channels of each DOFs are measured at a certain GPS time and calibrated using the optical gains and actuation calibration measured in the previous post.

Attachment shows the results.

It seems like the UGFs for MICH and DARM (currently XARM) match the ones that were estimated previously (100Hz for MICH, 120Hz for DARM) except for CARM for which the UGF was estimated to be 250Hz and here seems to be > 1kHz.

Indeed one can also see that the picks in the CARM plot don't match that well. Calculation shows that at 250Hz OUT channel is 6 times more than the IN channel. Calibrations for CARM should be checked.

MICH sensitivity using REFL55 at high frequencies is not much better than what was measured with AS55.

DARM sensitivity at 10Hz is a factor of a few better than the single arm lock sensitivity.

Now it is time to do the budgeting.

Attachment 1: Sensitivity_Plot_1344133503.pdf
Sensitivity_Plot_1344133503.pdf
  17091   Thu Aug 18 18:10:49 2022 KojiSummaryLSCFPMI Sensitivity

The overlapping plot of the calibrated error and control signals gives you an approximately good estimation of the freerun fluctuation, particularly when the open-loop gain G is much larger or much smaller than the unity.
However, when the G is close to the unity, they are both affected by "servo bump" and both signals do not represent the freerun fluctuation around that frequency.

To avoid this, the open-loop gain needs to be measured every time when the noise budget is calculated. In the beginning, it is necessary to measure the open-loop gain over a large frequency range so that you can refine your model. Once you gain sufficient confidence about the shape of the open-loop gain, you can just use measurement at a frequency and just adjust the gain variation (most of the cases it comes from the optical gain).

I am saying this because I once had a significant issue of (project-wide) incorrect sensitivity estimation by omitting this process.

  6914   Wed Jul 4 21:11:53 2012 yutaUpdateLockingFPMI in vacuum is back

I aligned FPMI and greens. There's no recognizable difference between before and after the vent.

What I did:
  1. Aligned Y arm to maximize Y green transmission.
  2. Used PZT1/2 to maximize TRY. But since PZT1 doesn't work so much, I had to align Y arm, too (mostly ETMY). This decreases green transmission, but I will leave it.
  3. Aligned BS and X arm to maximize TRX
  4. Fine tune them to minimize ASDC during FPMI lock, without decreasing TRX
  5. Aligned X end green to get TEM00 transmission.

Now, TRY and TRX are both  ~0.89.
Green transmission from Y and X arm are ~123 uW and ~275 uW respectively. Their max we got so far was ~200 uW and ~255 uW.
I still see clipped beam at AS, which I think is from the Faraday edge, as we found in elog #6897.
Below is the Sensoray capture of some ports, and MEDM screen shots to compare with before vent(see #6893).
There are two AS captures, one is without MI lock and the other is with MI lock. Note that PRM/SRM is misalined.

ALL_1025495266.pngMEDMscreenshotswithCOW_20120704.png


Next:
 - I will check ALS
 - I keep Y end green optics untouched since elog #6776, to use it as a reference. We need to realign them if tip-tilts are installed in vacuum, or PZTs are installed in both ends.

  8170   Tue Feb 26 11:55:11 2013 ManasaUpdateLockingFPMI locked

 [Yuta, Manasa]

FPMI locked.

Alignment and lock acquisition
1. Use ITMY/ETMY to maximize green transmission in Y arm (to get closer to arm alignment).
2. Use TT1/TT2 to align arms to IR to the Y-arm (Maximum TRY = 0.84)
3. Use BS/ITMX/ETMX to align IR to the X-arm.
4. Use POY11_I and POX11_I to lock Yarm and Xarm.
5. Use ASDC to lock MI.

Modified
1. X-arm trans camera settings changed.
2. Blocked stray green from reaching TRX PD and camera.

P.S. TRX seems to be moving less on the camera because of the oplevs centered and working from last night.

Plan
Lock green to X arm.

  8171   Tue Feb 26 15:32:47 2013 JenneUpdateLockingFPMI locked

Quote:

P.S. TRX seems to be moving less on the camera because of the oplevs centered and working from last night.

 Ah, yes.  I forgot to mention in my elog last night that Yuta and I found that the ITMX oplev servo had been on, even though the oplev beam was blocked, so ITMX was noisier than it should have been.

  9157   Tue Sep 24 22:19:57 2013 ManasaUpdateGeneralFPMI locked

 [Masayuki, Manasa]

We locked FPMI and measured the FPMI noise (power spectrum of error signal - MICH_IN1) which will be calibrated.

The arms were locked using POX11 and POY11. The sign of MICH gain was changed to lock FPMI (from -30 to +30). 

  7240   Tue Aug 21 01:54:09 2012 JenneUpdateLockingFPMI locked - arms locked with IR

I (for the first time personally) locked the FPMI.  I have data for the POX11I, POY11I, AS55Q error signals for each arm and the Michelson (JenneLockingDTT/FPMI_error_signals.xml), but I haven't calibrated the data yet - Self: do this!  FPMI with arms locked using IR has been happily locked for a long time now - this is good.

From elogs / my old MICH calibration script, I have the plant calibrations of:

POY:  1.4e12 cts/m

POX: 3.8e12 cts/m

AS55: 9.4e9 cts/m

MICH has FM 5 on, Xarm has FM4-10 all on, Yarm has FM3-10 all on. 

Post note: FM 3 - the integrator - for Xarm wasn't triggered.  It turns on just fine, so I've got it triggered just like Yarm.

Also, just remembered - I turned off the XARM TRX power normalization, since it was causing crazy numbers in the xarm servo.  The XARM locked pretty easily after that.

  14926   Wed Oct 2 23:15:02 2019 gautamUpdateLSCFPMI locking

Summary:

I was able to lock the FPMI. The lock was quite stable. However, the fluctuations in the ASDC power suggest that it will be difficult to make a DC measurement of the contrast defect in this configuration. This problem can be circumvented in part by some electronics tuning. However, the alignment jitter couples some HOM light which is an independent effect. Can this be a good testbed for the proposed AS WFS system? 

Details:

  • First, the arm cavities were locked and TRX/TRY were maximized using ASS.
  • Next, AS55_Q-->MICH_A (MICH-->BS) matrix element was set to 1 in the LSC input (output) matrix. The trigger was set to always on.
  • AS55 digital demod phase was -37 degrees.
  • I was then able to increase the gain on the MICH servo and turn on some integrators without any problem.
  • Some guesswork had to be done to get the correct sign. Final servo gain used was -0.8. 

I didn't do any serious budgeting yet - need to think about / do some modeling on how this configuration can be made useful.

Attachment 1: FPMIlocked.png
FPMIlocked.png
  17012   Mon Jul 18 16:39:07 2022 PacoSummaryLSCFPMI locking procedure using REFL55 and AS55

[Yuta, Paco]

In summary, we locked FPMI using REFL55_I, REFL55_Q, and AS55_Q. The key to success was to mix POX11_I and POY11_I in the right way to emulate CARM/DARM, and to find out the correct demodulation phase for AS55.


Procedure

  1. Close PSL shutter and zero offsets in AS55, REFL55, POX11, POY11, and ASDC
    • For ASDC run python3 resetOffsets.py -c C1:LSC-ASDC_IN1, otherwise use the zer offsets on I and Q inputs from the RFPD medm screen.
  2. Lock XARM/YARM using POX/POY to tune demodulation phase.
    • Today, the demode phase in POX11 changed to 104.801, and POY11 to -11.256 deg.
  3. XARM and YARM are used in the following configuration
    • INMAT
      • 0.5 * POX11_I - 0.5 * POY --> XARM
      • 0.5 * POX + 0.5*POY --> YARM
      • REFL55_Q --> MICH (** this should be turned on after POX11/POY11)
    • LSC Filter gains
      • XARM = 0.012
      • YARM = 0.012
      • MICH = +40 (note the sign flip from last time)
    • OUTMAT
      • XARM --> 0.5 * ETMX - 0.5 * ETMY
      • YARM --> MC2
      • MICH --> BS
    • UGFs (sanity check)
      • XARM (DARM) ~ 100 Hz
      • YARM (CARM) ~ 200 Hz
      • MICH (MICH) ~ 40 Hz
  4. Run MICHOpticalGainCalibration.ipynb to see if ASDC vs REFL55_Q looks nice (ellipse in the XY plot), and find any residual offset in REFL55_Q.
    • If the plot doesn't look nice in this regard, the IFO needs to be aligned.
  5. Sensing matrix for CARM/DARM and MICH.
    • With the DARM, CARM and MICH lines on, verify the demod error signals look ok both in mag and phase.
    • For example, we found that CARM error signals were correctly represented by either 0.5 * POX11_I + 0.5 * POY11_I or 0.5 * REFL55_I.
    • Similarly, we found that DARM error signal was correctly represented by either 0.5 * POX11_I - 0.5 * POY11_I or 2.5 * AS55_Q.
    • To find this, we minimized CARM content in AS55_Q, as well as CARM content in REFL55_Q.
  6. We acquired the lock by re-configuring the error point as below:
    • INMAT
      • 0.5*REFL55_I --> YARM (CARM)
      • 2.5 * AS55_Q --> XARM (DARM)
    • During the hand-off trials, we repeatedly ran the sensing matrix and UGF measurements while stopping at various intermediate mixed error points to check how the error signal calibrations changed if at all.
      • Attachment #1 shows the DARM OLTF using POX/POY (blue), only with CARM handoff (green), and after DARM handoff (red)
      • Attachment #2 shows the CARM OLTF using POX/POY (blue), only with CARM handoff (green), and after DARM handoff (red)
      • Attachment #3 shows the MICH OLTF using POX/POY (blue), only with CARM handoff (green), and after DARM handoff (red)
    • The sensing matrix after handoff is below:
Sensing Matrix with the following demodulation phases
{'AS55': 192.8, 'REFL55': 95.63177865911078, 'POX11': 104.80089727128349, 'POY11': -11.256509422276006}
Sensors          	           DARM     	           CARM     	            MICH     	
C1:LSC-AS55_I_ERR_DQ	5.09e-02 (89.6761 deg)	2.03e-01 (-114.513 deg)	1.28e-04 (-28.9254 deg)	
C1:LSC-AS55_Q_ERR_DQ	4.78e-02 (88.7876 deg)	3.61e-03 (-68.7198 deg)	8.34e-05 (-39.193 deg)	
C1:LSC-REFL55_I_ERR_DQ	5.18e-02 (-92.2555 deg)	1.20e+00 (65.2507 deg)	1.15e-04 (-102.027 deg)	
C1:LSC-REFL55_Q_ERR_DQ	1.81e-04 (59.0854 deg)	1.09e-02 (-114.716 deg)	1.77e-05 (-23.6485 deg)	
C1:LSC-POX11_I_ERR_DQ	8.51e-02 (91.2844 deg)	4.77e-01 (67.1709 deg)	7.97e-05 (-72.5252 deg)	
C1:LSC-POX11_Q_ERR_DQ	2.63e-04 (114.584 deg)	1.32e-03 (-113.505 deg)	2.10e-06 (118.146 deg)	
C1:LSC-POY11_I_ERR_DQ	1.58e-01 (-88.9295 deg)	6.16e-01 (67.6098 deg)	8.71e-05 (172.73 deg)	
C1:LSC-POY11_Q_ERR_DQ	2.89e-04 (-89.1114 deg)	1.09e-03 (70.2784 deg)	3.77e-07 (110.206 deg)	

Lock gpstimes:

  1. [1342220242, 1342220260]
  2. [1342220420, 1342220890]
  3. [1342221426, 1342221574]
  4. [1342222753, 1342223230]

Sensitivity estimate (NANB)

Using diaggui, we look at the AS55_Q error point and the DARM control point (C1:LSC-XARM_OUT). We roughly calibrate the error point using the sensing matrix element and actuation gain at the DARM oscillator freq 4.78e-2 / (10.91e-9 / 307.880^2). The control point is calibrated with a 0.95 Hz SUS pole. Attachment #4 shows the sensitivity estimate.

Attachment 1: DARM_07_18_2022_FMPI.pdf
DARM_07_18_2022_FMPI.pdf DARM_07_18_2022_FMPI.pdf DARM_07_18_2022_FMPI.pdf
Attachment 2: CARM_07_18_2022_FPMI.pdf
CARM_07_18_2022_FPMI.pdf CARM_07_18_2022_FPMI.pdf CARM_07_18_2022_FPMI.pdf
Attachment 3: MICH_07_18_2022_FPMI.pdf
MICH_07_18_2022_FPMI.pdf MICH_07_18_2022_FPMI.pdf MICH_07_18_2022_FPMI.pdf
Attachment 4: fpmi_darm_nb_2022_07.pdf
fpmi_darm_nb_2022_07.pdf
  17016   Mon Jul 18 21:41:42 2022 AnchalSummaryLSCFPMI locking procedure using REFL55 and AS55

Now that you have found a working configuration, I suggest we update CARM and DARM filter banks so that they are used in locking those degrees of freedom instead of repurposing XARM/YARM banks. It would be bit easier to understand and leaves room for future changes for one configuration while keeping single arm lock configurations untouched.

  17069   Tue Aug 9 19:54:31 2022 yutaSummaryLSCFPMI locking tonight

[Tega, Anchal, Yuta]

We resored FPMI locking settings. Below is the summary of locking configurations tonight.
To ease the lock acquisition, the step to feedback POX11_I to ETMX and POY11_I to MC2 before POX and POY mixing was necessary tonight.

CARM (YARM):
 - 0.5 * POX11_I + 0.5 * POY11_I handed to 0.5 * REFL55_I
 - YARM filter module, FM4,5 for acquisition, FM1,2,3,6,8 triggered, C1:LSC-YARM_GAIN = 0.012
 - Actuation on -0.77 * MC2
 - UGF ~ 250 Hz

DARM (XARM):
 - 0.5 * POX11_I - 0.5 * POY11_I handed to 4.6 * AS55_Q (it was 2.5 in 40m/17012)
 - XARM filter module, FM5 for acquisition (no FM4), FM1,2,3,6,8 triggered, C1:LSC-XARM_GAIN = 0.015
 - Actuation on 0.5 * ETMX - 0.5 * ETMY
 - UGF ~ 120 Hz

MICH:
 - 1 * REFL55_Q (turned on after XARM and YARM acquisition)
 - MICH filter module, FM4,5,8 for acquisition, FM2,3 triggered, C1:LSC-MICH_GAIN = +40
 - Actuation on 0.5 * BS
 - UGF ~ 100 Hz

Measured sensing matrix:
Sensing Matrix with the following demodulation phases
{'AS55': 200.41785156862835, 'REFL55': 93.7514468401475, 'POX11': 105.08325063571438, 'POY11': -11.343909976281823}
Sensors              DARM                    CARM                   MICH
C1:LSC-AS55_I_ERR_DQ 5.27e-02 (-154.105 deg) 2.83e-01 (132.395 deg) 1.17e-04 (-40.1051 deg)
C1:LSC-AS55_Q_ERR_DQ 3.99e-02 (-151.048 deg) 1.42e-02 (125.504 deg) 1.41e-04 (-2.42846 deg)
C1:LSC-REFL55_I_ERR_DQ 5.59e-02 (77.6871 deg) 1.15e+00 (-44.589 deg) 3.55e-04 (69.2585 deg)
C1:LSC-REFL55_Q_ERR_DQ 1.84e-03 (16.3186 deg) 3.35e-03 (125.67 deg) 4.59e-05 (4.18718 deg)
C1:LSC-POX11_I_ERR_DQ 1.54e-01 (-157.852 deg) 6.07e-01 (-42.1078 deg) 5.55e-05 (73.3963 deg)
C1:LSC-POX11_Q_ERR_DQ 6.83e-05 (-148.591 deg) 6.37e-04 (121.983 deg) 1.35e-06 (43.7201 deg)
C1:LSC-POY11_I_ERR_DQ 1.85e-01 (36.1624 deg) 5.73e-01 (-43.1776 deg) 2.12e-04 (82.16 deg)
C1:LSC-POY11_Q_ERR_DQ 2.16e-05 (130.937 deg) 6.38e-05 (-173.194 deg) 1.40e-06 (47.5416 deg)

FPMI locked periods:
  - 1344129143 - 1344129520
  - 1344131106 - 1344131305
  - 1344133503 - 1344134020

Next:
- Restore CM servo for CARM

  9161   Wed Sep 25 23:15:11 2013 MasayukiSummaryGreen LockingFPMI noise caused by ARM locking
I measured some error signal, OLTFs and responses for FPMI noise estimation. Especially we are interested in the noise from in-loop noise of ALS Green PDH control. The strategy and
 
1) Purpose
 Estimation of the FPMI phase shift noise caused by in-loop noise of Green PDH control. 
 
 
2) What we should figure out
 For that estimation we have to figure out the transfer function from the cavity length change to the phase shift which is measured by MICH.
 
 
3) Strategy
 I attached the block diagram of  our interferometer. Our goal is to find the transfer function H_L-l and to calibrate the out of loop noise of interferometer with that TF and error signal of the PDH control.
 H,A and F mean the sensitivity, actuator response and servo filter for each control loop. L_xarm is the disturbance of the cavity length and l- is the differencial motion of the interferometer
fpmibd.pdf
We can get this H_L-l from measurement of the response from calibrated ETM actuation to the MICH error signal. You can get the formula for calculating H_L-l with simple calculation and that is
 
             1 + G_mich       1 + G_xarm      V_mi  
H_L-l = ---------------  -----------------  ------------
              H_mich             A_etmx         V_excetm
 
 
where the each G is OLTF and V_mi/Vexcetm is the response from the ETM actuation to the MICH error signal.
And then  the FPMI noise in the unit of meter / rHz is
 
                           H_L-l
N_fpmi = l_dis + ------------ Vx
                          H_mich
               
This second term is what we are interested in.
 
To estimate these noises
i) We can calibrate the actuators of  ITMX, ITMY and BS with using the MICH as sensor. So we can calibrate the arm error signals by  excitation of arm length using ITMs actuator.
ii) If we know the TFs of arms, we can calibrate the ETMX and ETMY actuators.
iii) We should know the response from ETMX or ETMY actuating to error signal of mich.
iv) Also we should calibrate the error signal of MICH in FPMI locking(H_mich). We can do that by exciting the BS.
 

Then we can estimate the noises.

 
In next entry, I will write about measurement.

 

  9162   Wed Sep 25 23:59:29 2013 MasayukiSummaryGreen LockingFPMI noise caused by ARM locking

 

Measurement with ARMs

i) By locking the MICH with AS55Q signal I measured the actuator response of ITMX ITMY BS for calibration of each actuator. This measurement was done at the same time with elog#9158. The actuator response was
 
BS : 2.2347e-8 / f^2 [m/count]

ITMX: 5.0843e-9 /f^2 [m/count]

ITMY: 4.9677e-9 / f^2 [m/count]

 
 
ii)By locking the Arms for IR with POX,POY. I measured the OLTF and the response from ITM actuation to POX and POY signal. Attachment 1,2 are the plots of fitted OLTF , the measured OLTF, and residual function (model - measure)/model and the attachment 3,4 are the response of each arm. I fitted the three parameters. Those are the gain, time-delay and cavitypole. Each fitted parameter is
 
XARM ;
timedelay:-282.09 usec, cavity pole : 2872.0 Hz
YARM ;
timedelay:-283.84 usec, cavity pole : 2939.9 Hz
 
The cavity pole seems higher than privious measurement (In 2009). Actually the residual function are increase at the higher frequency region than 1kHz, so I guess the fitting is not so good.One possibility is that in the region where cavity pole effect increase we has not much data.
With fitted OLTF and actuator response I calibrated the H_xarm and H_yarm.
 
Hxarm : 2.9796 e11 [count / m]
Hyarm : 6.1394 e11 [count / m]
 
iii) After that I measured the response from ETM actuation to POX and POY signal to calibrate the ETM actuator. The response of each actuator is
 
ETMX:1.2040e-8 / f^2 [m/count]

ETMY:1.4262e-8 / f^2 [m/count]
 
iv) I calibrated the error signal with OLTF and Hxarm,Hyarm. The result is in Attachment 5

 In high frequency region there is the difference between xarm and yarm. These difference are already there in error signal. I'm not sure where these noise comes from. We will make measurement with Green PDH from tomorrow, so  we can also check with those measurement.

In other region the two noises are very close and also very similar to the plot of the seismic motion in the control room (attached on the front of TV screen).

Attachment 1: XARM_OLTF.pdf
XARM_OLTF.pdf
Attachment 2: YARM_OLTF.pdf
YARM_OLTF.pdf
Attachment 3: XARM_ITMXresponse.png
XARM_ITMXresponse.png
Attachment 4: YARM_ITMYresponse.png
YARM_ITMYresponse.png
Attachment 5: free_running.pdf
free_running.pdf
  9163   Thu Sep 26 01:49:28 2013 MasayukiSummaryGreen LockingFPMI noise caused by ARM locking

 

 Measurement with FPMI


i)By locking the FPMI with AS55Q and arms using POX,POY we measured  the OLTF on AS55Q, the response from BS actuation to error signal on AS55Q  for H_mich. The fitted,  measured OLTF and the residual function is in attachment1. I fitted two parameters and they are time-delay and the gain. The time delay is -275 usec. The time delay in three different control are almost same. The response from BS to AS55Q is in attachment 2.


With these two measuremets, I calclated the H_mich in FPMI. This H_mich should be different from simple MI because the cavity  refrectivity is different from the front mirror. Acrually it changed and the value was
Hmich = 4.4026e7

ii) I excited the ETMX and ETMY and measure the response from actuation to the error signal of MICH on AS55Q. The response is in attachment 3 and 4. from these result I calculated the H_L-l by using the formula as I mentioned. The value was
H_Lx-l = 175.7650 (XARM)
H_Ly-l = 169.8451 (YARM)

iii) I measured the error signal of MICH and XARM and YARM and with measured H_L-l, I estimated the FPMI noise caused by ARM locking. You can see in the higher frequency region than 10 Hz is dominated by noise caused by ARM control in-loop noises. 150 Hz and 220Hz are the UGF of each arms, so the two peaks are caused by arm control. You can see the small difference between FPMI noise and  noise from arms. There are two possibilities, one is that these measurement is not same time measurement so they should have small difference. and  other possibility is the error of the caliculation. But I think it doesn't look so bad estimation.

 

Next step

We will do same measurement with lock the arms the ALS system on tomorrow. Then we will check the PDH servo or other noise source and investigate the ALS system

Attachment 1: MICH_OLTF.pdf
MICH_OLTF.pdf
Attachment 2: BS-RS55Q.png
BS-RS55Q.png
Attachment 3: ETMX-RS55.png
ETMX-RS55.png
Attachment 4: ETMY-RS55.png
ETMY-RS55.png
Attachment 5: plot.pdf
plot.pdf
  9167   Thu Sep 26 23:02:40 2013 ranaUpdateLSCFPMI noise caused by ARM locking

Hidden in Nakano-kun's previous entries was that the phase margin of the X-Arm was only 9 degrees!! This extremely close to instability and makes for huge gain peaking. The feedback loop is increasing noise above 100 Hz rather than suppress. After some tweaks of the LSC filters we got a much more stable loop/.

So we today started to examine the sources of phase lag in the arm cavity sweeps. There were a few unfortunate choices in the XARM LSC filter bank which we tuned to get less delay.

Then I wrote a bunch of detail about how that worked, but the ELOG ate my entry because it couldn't handle converting my error signal noise plot into a thumbnail. Then it crashed and I restarted it. We also have now propagated the changes to the Y arm by copy/paste the filters and the result there is pretty much the same: low phase margin is now 38 deg phase margin. Noise is less bad.

 

Attachment 1: Xarm_sweep_130926.pdf
Xarm_sweep_130926.pdf
Attachment 2: lsc.pdf
lsc.pdf
Attachment 3: err.png
err.png
  9168   Fri Sep 27 00:48:53 2013 MasayukiUpdateLSCFPMI noise caused by ARM locking

Quote:

Hidden in Nakano-kun's previous entries was that the phase margin of the X-Arm was only 9 degrees!! This extremely close to instability and makes for huge gain peaking. The feedback loop is increasing noise above 100 Hz rather than suppress. After some tweaks of the LSC filters we got a much more stable loop/.

So we today started to examine the sources of phase lag in the arm cavity sweeps. There were a few unfortunate choices in the XARM LSC filter bank which we tuned to get less delay.

Then I wrote a bunch of detail about how that worked, but the ELOG ate my entry because it couldn't handle converting my error signal noise plot into a thumbnail. Then it crashed and I restarted it. We also have now propagated the changes to the Y arm by copy/paste the filters and the result there is pretty much the same: low phase margin is now 38 deg phase margin. Noise is less bad.

 

[Rana, Masayuki

 I made the plot of the phase of the digital filters which Rana change and also  of the AA, AI, DAA, DAI filters. Now the biggest phase delay come from the timedelay of the digital system.

phase_badget.png

The UGF is around 150 Hz at that frequency the time delay has biggest phase  delay. Second one is the FM9 filter (this filter is BOOST filter). Then we have the AA filter, AI filter and so on, but these delay is roughly 5 degree.

As I said in previous entry, the time delay of the XARM control is roughly 300 usec, and we have 120 usec even only in C1SUS. Also between the C!SUS and C1LSC we have another 120 usec time delay. We want to increase the UGF to 300 Hz but because of the time delay of the digital system we cannot increase. So we should fix this problem.

 

After changing these filters, the FPMI noise is become better at high frequency. Before we have peak around the 100 Hz (because of 8 degree phase margin...), but they are gone. i attached the noise spectrum. This plot is measured by the real time calibration output. But even then, you can see the extra noise around 100 Hz in FPMI conpare to only MICH.

 FPMI_noises.png

 

 

  9201   Fri Oct 4 02:08:32 2013 MasayukiUpdateGreen LockingFPMI with ALS arm stabilization

[Manasa, Masayuki]

We locked MICH with 2 arms stabilized by ALS control.

Measurement

We measured the power spectrum of the LSC-MICH_IN1  at each step so as to know the in-loop noise of MICH. And also we measured the OLTF of MICH loop and the error signal with BS excited at 580 Hz and MICH notch filter at same frequency enabled to obtain the MICH calibration factor.

1. We locked  MICH using the AS55Q error signal and fedback to BS actuator. (Red curve)

2. We locked  MICH and locked both the arms using POX11 and POY11 error signals and fedback to ETMs actuators.(Blue curve)

3. We stabilized both the arms using ALS. We use the ALS error signals and fedback to ETMs actuators. And then we locked  MICH.(Magenta curve)

Attachment

The green and brown curve are the ALS in-loop noise, which is the _PHASE_OUT_Hz calibrated error signals. So for these two curves the unit of vertical axis is Hz/rHz. The other curves are the MICH in-loop noises and these are not calibrated. So for these curves the unit of vertical axis is counts/rHz.

Discussion

The UGF of MICH loop is 10 Hz with phase margin of 45 degrees (measured today). The FPMI noise with ALS stabilized arms is much larger than the FPMI with IR PDH locked arms above 30 Hz. That is because the ALS arm stability is not as good as the stability of PDH locked arms. We have to analyze and verify the calibrated numbers for FPMI + ALS with model.

Attachment 1: FPMI_ALS.pdf
FPMI_ALS.pdf
  9261   Wed Oct 23 00:13:30 2013 MasayukiUpdateGreen LockingFPMI with ALS arm stabilization

Summary
In 2arms + MICH configuration, residual motion of the cavity will couple with MICH signal. When cavity length change, the reflectivity of cavity also change. And that cause the phase shift in reflected light. That phase shift is detected in MICH signal. When we try to lock the DRMI + arm, that coupling will be problem for lock acquisition. For practice to estimate that coupling, I estimated the coupling between the cavity motion and the AS55Q signal.

What I did

- Measurement steps
  I did the same measurement as that of this entry. For the estimation below steps are needed. The detail of each step will be written below.
  --Measurement and calibration of the AS55Q error signal with MICH + 2arms locked by ALS control
  --Measurement of the ALS in-loop noise and estimation of residual motion of the cavities.
  --Calibration of the coupling from residual arm motion to AS55Q signal

- Calibration of  the AS55Q signal
1. Sensor gain estimation
  We used the same method as the previous entry,
  We excited the BS at 580 Hz with a given amplitude (Vin). We enabled the notch filter at 580 Hz in the LSC MICH servo. We measured  the peak height (Verr) of the AS55Q error signal. We used the actuator response (A_bs) of BS measured in this entry.
  We can get the sensor gain (H) of AS55Q in unit of count/m

          Verr    1
   H = ------- -------
          Vin   A_bs

By this calculation H = 4.2e+07.

2. Fitting of OLTF for the MICH loop
  We measured the OLTF of the MICH loop. Modelled OLTF is fitted into the measurement data. That modelled OLTF includes the actuator response of BS, the MICH servo filters, DAI,DAA,AI,AA filters, the TF of sample and hold circuit. (About DAI, DAA filters and S/H circuit please read this entry. About AI,AA filters please read this entry)  Also I put time-delay into that OLTF. I estimated that time-delay and the gain of OLTF by fitting.  The time delay was 311usec.

OLTF.png

3. Estimation of the MICH free running noise
 With modeled OLTF, I estimated the MICH free running noise.

Estimation of the coupling from residual cavity motion to AS55Q signal
 The ALS in-loop noise data has the unit of Hz/rHz (disturbance of the cavity resonant frequency). By multiplying L_arm/f_laser we can convert the unit to m/rHz (disturbance of the cavity length) .
 I used the same coupling constant between residual motion of cavity and MICH noise as this entry. For estimation of the coupling constant, we excited ETMs  and measured the TF from excitation signal to AS55Q error signal.  I assumed the cavity pole as 4000 Hz. The result is discussed below

Discussion

  ALS in-loop noise include the sensor noise. in high frequency region the in-loop noise is dominated by the sensor noise. So in this region in-loop noise does not mean actual residual motion of the cavity.  And this sensor noise pushes the mirror. So we have to estimate the actual motion of the cavity by multiplying the servo transfer function of the control in this region.

 I made 2 plots. Both include the MICH free running noise and estimated coupling noise from both arms. In one plot, for estimation of the coupling I multiplied only coupling constant to calibrated in-loop noise of the ALS loop. In another plot,  I multiplied coupling constant and OLTF of ALS loop in order to estimate the actual motion of the cavity.  If the 3 curves are coincide in first plot, that means the ALS in-loop noise is same as the residual cavity motion in that region and the MICH free running noise is dominated by coupling from residual cavity motion. If those curves are coincide in second plot, that means the ALS in-loop noise is sensor noise in that region.

 Above 40 Hz, the 3 curves are totally in coincident in first plot. On the other hand in second plot the 3 curves look similar in this region. That may mean above 40 Hz the ALS noise are dominated by sensor noise and MICH free running noise is dominated by the coupling from residual cavity motion.  Also in the region between 10 Hz and 40 Hz, the MICH free running noise seems to be dominated by coupling from cavity motion.

Figure 1

 ALSnoise1.png

Figure 2

ALSnoise2.png

In second plot, the coupling from cavity motion is overestimated. It's possibly because of overestimation of coupling constant, but I'm not sure.
Koji mentioned that we should measure the residual motion of the cavity by using POX and POY. Now the ALS is much more stable than before, so I think we can easily do the measurement again with out of loop measurement. That will be more strait forward measurement.

  17007   Fri Jul 15 19:13:22 2022 PacoSummaryLSCFPMI with REFL/AS55 demod phase adjust

[Yuta, Paco]

  • We first zero the offsets in ASDC, AS55, REFL55, POX11, and POY11 when PSL shutter is closed.
    • After this, we checked the offsets with only ITMX aligned. Some of RFPDs had ~2 counts of offsets, which indicate some RFAM of sidebands, but we decided not to tune Marconi frequencies since the offsets were small enough.
  • We went over the demod phases for AS55, REFL55, POX11, and POY11.
    • For POX11/POY11 first we just minimized the Q in each locked XARM/YARM individually. The newfound values were
      • C1:LSC-POX11_PHASE_R = 106.991
      • C1:LSC-POY11_PHASE_R = -12.820
    • Then we misaligned the XARM by getting rid of the MICH fringe in the ASDC port with ITMX yaw offset, and locked YARM using AS55_Q and REFL55_I and found the demod phase that minimized the AS55_I and REFL55_Q. The newfound values were
      • C1:LSC-AS55_PHASE_R = -65.9586
      • C1:LSC-REFL55_PHASE_R = -78.6254
    • Repeating the above, but now misaligning YARM with ITMY yaw offset, locking XARM with AS55_Q and REFL55_I, we found the demod phases that minimized AS55_1 and REFL55_Q. The newfound values were
      • C1:LSC-AS55_PHASE_R = -61.4361
      • C1:LSC-REFL55_PHASE_R = -71.0434
  • The above demod phases difference, Schnupp asymmetry between X and Y were measured. We repeated the measurement three times to derive the error.
    • Optimal demod phase difference between X arm and Y arm for both AS55 and REFL55 were measured to be -4.5 +/- 0.1 deg, which means that lx-ly = 3.39 +/- 0.05 cm (Marconi frequency: 11.066195 MHz).
  • We measured the gain difference between AS55_Q and POX11/POY11 = -0.5
  • We measured the gain difference between REFL55_I and POX11/POY11 = -2.5

After this, we locked DARM, CARM and MICH using POX11_I, POY11_I and AS55 error signals respectively, and actuating on ETMX, MC2, and BS with NO TRIGGERS (but FM triggers were on for boosts as usual). Under this condition, FM5 is used for lock acquisition, and FM1, FM2, FM3, FM6 are turned on with FM triggers. No FM4 was on. We also noticed:

  • CARM FM6 "BounceRoll" is slightly different than "YARM" FM6 "Bounce". The absent roll resonant gain actually makes it easier to control the CARM, we just had to use YARM filter for locking it.
  • When CARM is controlled, we often just kick the ETMX to bring it near resonance, since the frequency noise drops and we otherwise have to wait long.
  17008   Fri Jul 15 22:36:04 2022 ranaSummaryLSCFPMI with REFL/AS55 demod phase adjust

Very nice!

DARM feedback should go to ETMY - ETMX, not just a single mirror: Differential ARM.

For it to work with 1 mirror the UGF of the CARM loop must be much larger than DARM UGF. But in our case, both have a UGF of ~150 Hz.

In principle, you could run the CARM loop with higher gain by using the CM servo board, but maybe that can wait until the X,Y -> CARM, DARM handoff.

 

ELOG V3.1.3-