40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 78 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  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. 

 

  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.

  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.

  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. 

  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.

  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) 

  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.

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

  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.

  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.

  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.

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

  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

  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.

 

  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.

  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.

 

  16968   Fri Jul 1 08:50:48 2022 yutaSummaryLSCFPMI with REFL/AS55 trial

[Anchal, Paco, Yuta]

We tried to lock FPMI with REFL55 and AS55 this week, but no success yet.
FPMI locks with POX11, POY11 and ASDC for MICH stably, but handing over to 55's couldn't be done yet.

What we did:
 - REFL55: Increased the whitening gain to 24dB. Demodulation phase tuned to minimize MICH signal in I when both arms are locked with POX and POY. REFL55 is noisier than AS55. Demodulation phase and amplitude of the signal seem to drift a lot also. Might need investigation.
 - AS55: Demodulation phase tuned to minimize MICH signal in I when both arms are locked with POX and POY. Whitening gain is 24dB.
 - Script for demodulation phase tuning lives in https://git.ligo.org/40m/scripts/-/blob/main/RFPD/getPhaseAngle.py
 - Locking MICH with REFL55 Q: Kicks BS much and not so stable probably because of noisy REFL55. Offtet also needs to be adjusted to lock MICH to dark fringe.
 - BS coil balancing: When MICH is "locked" with REFL55 Q, TRX drops rapidly and AS fringe gets worse, indicating BS coil balancing is not good. We balanced the coils by dithering POS with different coil output matrix gains to minimize oplev PIT and YAW output manually using LOCKINs.
 - Locking MICH with ASDC: Works nicely. Offset is set to -0.1 in MICH filter and reduced to -0.03 after lock acquisition.
 - ETMX/ETMY actuation balancing: We found that feedback signal to ETMX and ETMY at LSC output is unbalanced when locking with POX and POY. We dithered MC2 at 71 Hz, and checked feedback signals when Xarm/Yarm are locked to find out actuation efficiency imbalance. A gain of 2.9874 is put into C1:LSC-ETMX filter to balance ETMX/ETMY. I think we need to check this factor carefully again.
 - TRX and TRY: We normalized TRX and TRY to give 1 when arms are aligned. Before doing this, we also checked the alignment of TRX and TRY DC PDs (also reduced green scattering for TRY). Together with ETMX/ETMY balancing, this helped making filter gains the same for POX and POY lock to be 0.02 (See, also 40m/16888).
 - Single arm with REFL55/AS55: We checked that single arm locking with both REFL55_I and AS55_Q works. Single arm locking feeding back to MC2 also worked.
 - Handing over to REFL55/AS55: After locking Xarm and Yarm using POX to ETMX and POY to ETMY, MICH is locked with ASDC to BS. Handing over to REFL55_I for CARM using ETMX+ETMY and AS55_Q for DARM using -ETMX+ETMY was not successful. Changing an actuator for CARM to MC2 also didn't work. There might be an unstable point when turning off XARM/YARM filter modules and switching on DARM/CARM filter modules with a ramp time. We also need to re-investigate correct gains and signs for DARM and CARM. (Right now, gains are 0.02 for POX and POY, -0.02 for DARM with AS55_Q (-ETMX+ETMY), -0.02 for CARM with REFL55_I with MC2 are the best we found so far)
 
Next:
 - Measure ETMX and ETMY actuation efficiencies with Xarm/Yarm to balance the output matrix for DARM.
 - Measure optical gains of POX11, POY11, AS55 and REFL55 when FPMI is locked with POX/POY/ASDC to find out correct filter gains for them.
 - Make sure to measure OLTFs when doing above to correct for loop gains.
 - Lock CARM with POY11 to MC2, DARM with POX11 to ETMX. Use input matrix to hand over instead of changing filter modules from XARM/YARM to DARM/CARM.
 - Try using ALS to lock FPMI.

  17002   Thu Jul 14 00:10:08 2022 yutaSummaryLSCFPMI with REFL/AS55 trial continued

[Paco, Koji, Yuta]

We managed to lock MICH using REFL55_Q by setting the demodulation phases and offsets right.
The following is the current FPMI locking configuration we achieved so far.

DARM: POX11_I / gain 0.007 / 0.5*ETMX-0.5*ETMY (or 1*ETMX) / UGF of ~100 Hz
CARM: POY11_I / gain 0.018 / 1*MC2 / UGF of ~200 Hz
MICH: REFL55_Q / gain -10 / 0.5*BS / UGF of ~30 Hz

Transitioning DARM error signal from POX11_I to 0.5*POX11_I+0.5*POY11_I was possible with FM4 filter off in DARM filter bank, but not to AS55_Q yet.

REFL55 and AS55 demodulation phase tuning:
 - We found that both AS55 and REFL55 are contaminated by large non-MICH signal, by making a ASDC vs RF plot (see 40m/16929).
 - After both arms are locked with POX and POY, MICH was locked with AS55_Q. ASDC was minimized by putting an offset to MICH filter.
 - With this, REFL55 offsets were zeroed and demodulation phase was tuned to minimize REFL55_Q.
 - Locked MICH with REFL55_Q, and did the same thing for AS55_Q.
 - Resulting ASDC vs RF plots were attached. REFL55_Q now looks great, but REFL55_I and AS55 are noisy (due to signals from the arms?).

Jupyter notebook: https://git.ligo.org/40m/scripts/-/blob/main/CAL/MICH/MICHOpticalGainCalibration.ipynb

Sensing matrix:
 - With FPMI locked using POX/POY, DARM and CARM lines were injected at around 300 Hz to measure the sensing gains. For line injection, C1:CAL-SENSMAT was used, but for the demodulation we used a script. The following is the result.

 Sensors              DARM (ETMX)         CARM (MC2)        
C1:LSC-AS55_I_ERR    3.10e+00 (-34.1143 deg)    1.09e+01 (-14.907 deg)    
C1:LSC-AS55_Q_ERR    9.96e-01 (-33.9848 deg)    3.30e+00 (-27.9468 deg)    
C1:LSC-REFL55_I_ERR    6.75e+00 (-33.7723 deg)    2.92e+01 (-34.0958 deg)    
C1:LSC-REFL55_Q_ERR    7.07e-01 (-33.4296 deg)    3.08e+00 (-33.4437 deg)    
C1:LSC-POX11_I_ERR    3.97e+00 (-33.9164 deg)    1.51e+01 (-30.7586 deg)    
C1:LSC-POY11_I_ERR    6.25e-02 (-20.3946 deg)    3.59e+00 (38.4207 deg)

Jupyter notebook: https://git.ligo.org/40m/scripts/-/blob/main/CAL/SensingMatrix/MeasureSensMat.ipynb

 - By taking the ratios of POX11_I and AS55_Q for DARM, POY11_I and REFL55_I for CARM, we tried to find the correct gains for REFL55 and AS55 for DARM and CARM. x3.96 more gain for AS55_Q than POX11_I and x0.123 less gain for REFL55_I than POY11_I.

Next:
 - Try locking the arms with no triggering, and then try locking FPMI with REFL/AS without triggering. No FM4 for this, since FM4 kills gain margin.
 - Lock single arm with AS55_Q and make a noise budget. Make sure to misalign ITMX(Y) completely when locking Y(X)arm.
 - Lock single arm with REFL55_I and make a noise budget.
 - Repeat Xarm noise budget with Yarm locked with POY11_I and MC2 (40m/16975).
 - Check IMC to reduce frequency noise (40m/17001)

  11750   Tue Nov 10 19:25:42 2015 gautamUpdateGeneralFS725 Rubidium reference

In the last few days, with Koji's help, I have recovered both the FS725 Rubidium references from W. Bridge, one from the ATF lab, and one from the CTN lab. Both are back at the 40m at the moment.

However, the one that was recovered from the ATF lab is no longer locking to the Rubidium reference frequency, although it was locked at the time we disconnected it from the ATF lab. I emailed the support staff at SRS, who seem to think that either the internal oscillator has drifted too far, or the Rb lamp is dead. Either ways, it needs to be repaired. They suggested that I run a check by issuing some serial commands to the unit to determine which of these is actually the problem, but I've been having some trouble setting up the serial link - I will try this again tomorrow. I'm also having trouble generating an RMA number that is needed to start the repair/maintenance process, but I've emailed SRS support again and hope to hear back from them soon. 

The other FS725, recovered from the CTN lab earlier today, seems to work fine and is locked to the Rb reference at the moment. I plan to redo the calibration of the phase tracker with an 'absolute' frequency reference with the help of the FS725 and out GPS timing unit tomorrow. Once that is done, the working unit can be returned to the CTN lab. 

  11898   Tue Dec 22 16:44:03 2015 gautamUpdateGeneralFS725 Rubidium reference - REPAIRED
Quote:

However, the one that was recovered from the ATF lab is no longer locking to the Rubidium reference frequency, although it was locked at the time we disconnected it from the ATF lab. I emailed the support staff at SRS, who seem to think that either the internal oscillator has drifted too far, or the Rb lamp is dead. Either ways, it needs to be repaired. They suggested that I run a check by issuing some serial commands to the unit to determine which of these is actually the problem, but I've been having some trouble setting up the serial link - I will try this again tomorrow.

The Rubidium standard we had sent in for repair and recalibration has come back. I checked the following:

  • Powered the unit on - it was locked to the internal rubidium reference within a few minutes as prescribed in the manual.
  • After it had locked to the internal reference, I checked that it was able to lock to an external 1pps reference from our GPS timing unit- this too was achieved within a few minutes as prescribed in the manualyes

However, I am still having trouble setting up a serial communications link with the FS725 with a USB-serial adaptor - I've tried with a Raspberry Pi and my Mac (using screen to try and connect), and also using one of the old Windows laptops lying around on which I was able to install the native software supplied by SRS (still using the USB-serial adaptor to establish connection though). Could it be that the unit is incompatible with the USB-serial adaptor? I had specifically indicated in the repair request that this was also a problem. In any case, this doesn't seem to be crucial, though it would have been nice for diagnostics purposes in the future...

I've stored the repaired FS725 inside the electronics cabinet (marked "Eletronics Modules") for now (the other unit was returned to Antonio in W. Bridge some weeks ago). 

  13357   Wed Oct 4 17:38:25 2017 gautamUpdateLSCFS725 for Marconi stabilization

I've located the Stanford Research FS725 Rb reference unit. The question is where to put it. This afternoon Steve and I put it inside the little electronics rack next to 1X3, but in hindsight, this probably isn't such a great place for a timing reference as there are a bunch of Sorensen power supplies in there (and presumably the accompanying harmonics from these switching supplies). 

The unit itself was repaired in 2015, and powering it on, it locked to the internal reference within a few minutes as prescribed in the manual. 

  13362   Thu Oct 5 18:40:27 2017 gautamUpdateLSCFS725 for Marconi stabilization

[steve, gautam]

  1. We installed the FS725 on the shelf inside the PSL enclosure - see Attachment #1.
  2. We ran a long BNC cable (labelled "GPS 1pps" on both ends) from 1X7 to the PSL enclosure - this was to pipe the 1PPS signal from the GPS timing unit (EndRun Technologies Tempus LX) rear panel (50 ohm output according to the datasheet) to the 1PPS input of the FS725 (high impedance). See Attachments #2. Note that the 1pps output was already tee'd on the rear panel. One port of the tee was unused (this now goes to the FS725) while the other was going to the 1PPS input of the Master Timing Sequencer (D050239), so I decided that there was no need to tee the 1pps input of the FS725 with a 50ohm terminator. In a few minutes, the Rb standard indicated that it was locked to its internal reference, and also to the external 1pps input (see Attachment #1). 
  3. We ran a long BNC cable (labelled "Rb 10MHz" on both ends) from the 10MHz output of the FS725 (50 ohm output impedance),  in the PSL enclosure to the rear BNC "FREQ_STD IN/OUT" BNC connector of the Marconi (1kohm input impedance). Changed the frequency reference setting on the Marconi to "External Direct". The FS725 datasheet recommends terminating the load with a 50ohm inline terminator, I have not yet done this (see Attachment #3). Is it appropriate to use a Balun (FTB-1-1) here? This would avoid ground loops between the Marconi and the FS725, and also make the load seen by the FS725 50ohms
  4. Found that there was an unused long cable from the PSL enclosure to the 1X2 electronics rack. We re-purposed this to drive the AOM driver via the DAC output in 1Y2. The cable is labelled "AOM driver" on both ends. This was to facilitate measurement of the coupling of laser intensity noise to AS55_Q in a DRMI lock.
  5. Removed 2 long cables between 1X7 and 1X2 that weren't connected to anything.
  6. Re-arranged the DC bench supply on the shelf in the PSL enclosure, whose only purpose seems to be to supply 12V to a fan attached to the rear of the PSL NPRO controller. Seems to be a waste of space! The fan was momentarily disconnected but has since been reconnected and is spinning again.
  7. Removed a couple of unused power cables from the mess on the shelf in the PSL enclosure. Also removed an unused Sony Video Squential Switcher YS-S6 from the PSL enclosure. 
Quote:

I've located the Stanford Research FS725 Rb reference unit. The question is where to put it. This afternoon Steve and I put it inside the little electronics rack next to 1X3, but in hindsight, this probably isn't such a great place for a timing reference as there are a bunch of Sorensen power supplies in there (and presumably the accompanying harmonics from these switching supplies). 

The unit itself was repaired in 2015, and powering it on, it locked to the internal reference within a few minutes as prescribed in the manual. 

 

  13363   Fri Oct 6 00:25:45 2017 ranaUpdateLSCFS725 for Marconi stabilization

Steve, can you please connect this fan to the rack power and remove this extra power supply?

Quote:

Re-arranged the DC bench supply on the shelf in the PSL enclosure, whose only purpose seems to be to supply 12V to a fan attached to the rear of the PSL NPRO controller. Seems to be a waste of space! The fan was momentarily disconnected but has since been reconnected and is spinning again.

  11735   Thu Nov 5 02:18:32 2015 gautamUpdateLSCFSR and linewidth measurements with phase tracker

While the ETMx issues are being investigated - with Eric's help, I took some data from arm scans of the Y arm through ~2FSRs using ALS. I've also collected the data from the frequency counter readout during these scans but since they were done rather fast (over 60seconds), I am not sure how accurate this data will be. The idea however is to use the frequency readout from the phase tracker - this has to be linearized though, which I will do during the daytime tomorrow. The plan is to use our GPS timing unit to synchronize the following chain :

GPS timing unit 1PPS out --> FS725 Rb Clock 1PPS in (I recovered one which was borrowed from the 40m some time ago from the ATF lab yesterday evening, waiting for it to lock to the Rb clock now)

FS725 Rb Clock 10 MHz out --> Fluke 6061A 10MHz reference in

FS725 Rb Clock 10 MHz out-->agilent network analyzer 10MHz reference in (for measurement of the frequency of the signal output from the Fluke RF signal generator independent of its front panel display)

Then I plan to look at the phase tracker output as a function of the driving frequency (which will also be measured, offline, using the digital frequency counter setup) over a range of 20 MHz - 50 MHz in steps of 1 MHz. Results to follow.

Earlier tonight, Eric and I tweaked the PMC alignment (the mode cleaner was not staying locked for more than a couple of minutes, for almost an hour). 

  11738   Fri Nov 6 15:56:00 2015 gautamUpdateLSCFSR and linewidth measurements with phase tracker

Summary:

I performed a preliminary calibration of the X and Y phase trackers, and found that the slopes of a linear fit of phase tracker output as a function of driven frequency (as measured with digital frequency counter) are 0.7886 +/- 0.0016 and 0.9630 +/- 0.0012 respectively (see Attachments #1 and #2). Based on this, the EPICS calibration constants have been updated. The data used for calibration has also been uploaded (Attachment #4).

Details:

I found that by adopting the approach I suggested as a fix in elog 11736, and setting a gate time of 1second, I could eliminate the systematic bias in measured frequency I had been seeing, the origin of which is also discussed in elog 11736. This was verified by using a digital oscillator to supply the input to the frequency counting block, and verifying that I could recover the driving frequency without any systematic bias. Therefore, I used this as a measure of the driving frequency independent of the front panel display of the Fluke 6061A. 

The actual calibration was done as follows:

  1. Close PSL green and end green shutters. Turned off the power to the green transmission PDs on the PSL table and disconnected the couplers from their outputs.
  2. Connected the output of the Fluke 6061A RF signal generator to a splitter, and to the inputs of the couplers for the X and Y signal chains.
  3. Adjusted the amplitude of the RF signal output until the Q readout of the rotated X and Y outputs were between 1000 and 3000. The final value used was -17dBm. As a qualitative check, I also looked at the beat signal on the spectrum analyzer in the control room and judged the peak height to be roughly the same as that seen when a real beat note was being measured. The phase tracker gains after setting the UGF were ~83 and 40 for the X and Y arms respectively.
  4. Step through the frequency from 20MHz to 70MHz in steps of 1MHz, and record the outputs of (i) Digital frequency counter readout, and (ii) Phase tracker phase readout for the X and Y arms. I used the z avg -s utility to take an average for 10 seconds, and the standard deviation thus obtained correspond to the errorbars plotted. 
  5. Restore the connections to the green beat PDs and power them on again.

Y-arm transmission scan

I used the information from Attachment #2 to calibrate the X-axis of the Y-arm transmission data I collected on Wednesday evening. Looking at the beat frequency on the analyzer in the control room, between 24 and 47 MHz (green beat frequency, within the range the calibration was done over), we saw three IR resonances. I've marked these peaks, and also the 11MHz sideband resonances, in Attachment #3. It remains to fit the various peaks. I did a quick calculation of the FSR, and the number I got using these 3 peaks is 3.9703 +/- 0.0049 MHz. This value is ~23 kHz greater than that reported in elog 9804, but the error is also ~4 times greater (6 IR resonances were scanned in elog 9804) so I think these measurements are consistent.

Rubidium clock

I had brought an FS725 Rubidium clock back from W Bridge - the idea was to hook this up to the GPS 1PPS output, and use the 10MHz output from the FS725 as the reference for the fluke 6061A. However, the FS725 has not locked to the Rb frequency even though it has been left powered on for ~2days now. Do I have to do something else to get it to lock? The manual says that it should lock within 7 minutes of being powered on. Once this is locked, I can repeat the calibration with an 'absolute' frequency source...

  11740   Mon Nov 9 11:34:51 2015 yutaroUpdateLSCFSR and linewidth measurements with phase tracker

I fitted the data obtained with the FSR and linewidth measurements and I've got FSR and finesse of y-arm by fitting.

The fitted data and the fitting results are attached.

 

Summary:

FSR = 3.9704 MHz (ave. of two FSRs, 3.9727 MHz and 3.9681 MHz)

finesse = 401 +/- 11

estimated loss = 1812 (+456 / - 431) ppm

 

Detail:

I found peaks from the data and fitted each peak by Lorentzian, automatically with Python (the sourse code I used is attached).

3 parameters of Lorentzian for each peak and their fitting errors are attached.

Then, using 3 peaks of carrier resonance, I calculated FSR, finesse, and loss.

The error of finesse came from that of linewidth.

When calculating the loss, I used the value of 1.384 % for transmission of ITMY. 

 

Note:

Since the finesse is mostly determined by the transmission of ITM, the relative error of loss estimation is larger (about 25 % ) though the relative error of finesse is about 3 %. Therefor we have to find the reason why each estimated linewidth varies that largely, and measure finesse more accurately.

 

ELOG V3.1.3-