I fixed the broken slider to change the current of the PA.

The problem was that the EPICS database assigned a wrong channel of the DAC to the slider.

I found that the PA current adjustment signal lines are connected to the CH3 &CH4 of VMIC4116 #1. However in the database file (/cvs/cds/caltech/target/c1psl/psl.db), the slider channel (C1:PSL-126MOPA_DCAMP) was assigned to CH2. I fixed the database file and rebooted c1psl. Then the PA current started to follow the slider value.

I moved the slider back and forth by +/-0.3V while the ISS loop was on. I observed that the amount of the low frequency fluctuation of the MOPA power changed with the slider position. At some current levels, the ISS instability problem went away.

Kakeru is now taking open-loop TFs and current shunt responses at different slider settings.

 I have updated the PSL Diagram wiki page to include MOPA. As with the PSL diagram, clicking the photo on the main page takes you to a larger image. The inventory is pretty meager as I didn't have time to sit and read labels (if indeed there are any). I will look through the documentation at the 40m to see if there is a record of what is there. Again, if you know something, please amend the list!!

http://lhocds.ligo-wa.caltech.edu:8000/40m/PSL_Table_Diagram

Not dead. It just had a HT fault. You can tell by reading the front panel. Cycling the power usually fixes this.

MOPA is back onliine.  Rana found that the fuse in the AC power connector's fuse had blown.  This was evident by smelling all of the inputs and outputs of the MOPA controller. The power cord we were using for this was only rated for 10A and therefore was a safety hazard. The fuse should be rated to blow before the power cord catches on fire. The power cord end was slightly melted. I don't know why it hadn't failed in the last 12 years, but I guess the MOPA was drawing a lot of extra current for the DTEC or something due to the high temperature of the head.

We got some new fuses from Todd @ Downs. 

The ones we got however were fast-blow, and that's what we want  The fuses are 10A, 250V.  The fuses are ~.08 inches long, 0.2 inches in diameter. 

I found the laser dead this morning.

The crane people are here to unjam it.

Laser hazard mode is lifted and LASER SAFE MODE is in place. No safety glasses but CRANE HAZARD is still active.

Stay out of the 40m lab !

steve, rob, alberto

Steve installed two rotary flow meters into the MOPA chiller system--one at the chiller flow output and one in the NPRO cooling line.  After some hijinks, we discovered that the long, insulated chiller lines have the same labels at each end.  This means that if you match up the labels at the chiller end, at the MOPA end you need switch labels: out goes to in and vice-versa.  This means that, indubitably, we have at some point had the flow going backwards through the MOPA, though I'm not sure if that would make much of a difference. 

Steve also installed a new needle valve in the NPRO cooling line, which works as expected as confirmed by the flow meter. 

We also re-discovered that the 40m procedures manual contains an error.  To turn on the chiller in the MOPA start-up process, you have to press ON, then RS-232, then ENTER.  The proc man says ON, RS-232, RUN/STOP.

The laser power is at 1.5W and climbing.

 Rob, Alberto

The chiller HT alarm started blinking, as the water temperature had reached 40 degrees C, and was still rising.  We turned off the MOPA and the chiller.  Maybe we need to open the needle valve a bit more?  Or maybe the flow needs to be reversed?  The labels on the MOPA are backwards?

The MOPA is taking the long weekend off.

Steve went out to wipe off the condensation inside the MOPA and found beads of water inside the NPRO box, perilously close to the PCB board.  He then measured the water temperature at the chiller head, which is 6C.  We decided to "reboot" the MOPA/chiller combo, on the off chance that would get things synced up.  Upon turning off the MOPA, the neslab chiller display immediately started displaying the correct temperature--about 6C.  The 22C number must come from the MOPA controller.  We thus tentatively narrowed down the possible space of problems to: broken MOPA controller and/or clog in the cooling line going to the power amplifier.  We decided to leave the MOPA off for the weekend, and start plumbing on Tuesday.  It is of course possible that the controller is the problem, but we think leaving the laser off over the weekend is the best course of action.

MOPAs and their settings, powers of 7 years in the 40m

In today's ISC call, Kiwamu was comparing two ways to approach resonance: 

• "C-Type": The scheme we currently think about; zero DARM offset and slowly reduce the CARM offset
• "D-Type": Start with no CARM offset, but a DARM offset and reduce that. 

D-type might be interesting to check out, since things change a little less dramatically when you reduce the DARM offset. Maybe this makes signal hopping easier? Signal recycling may complicate things, though. 

So, I've simulated CARM and DARM offset effects on CARM and DARM signals. (As with the previous plots, this is for the PRFPMI configuration.) From moving both offsets around, it looks like the resonance peak is about 5x wider in DARM than in CARM, so I simulated a 50pm offset range for CARM and a 250pm offset range for DARM. 

Here are some CARM signal transfer functions subject to CARM offsets in the top plot, and DARM offsets in the bottom plot. 

It's looks like the DARM offset changes cause much less dramatic changes in the CARM plant features. It's conceivable that this would make CARM locking easier. 

Here are some DARM plant transfer functions. 

In these plots, I did something kind of artificial: when we move the CARM offset, it changes the proper demodulation phase to get DARM in the Q of the AS 1F RFPDS. So, at each CARM offset, I re-phased the AS 1F demodulators, to show the total DARM information available at the AS RFPDs at each offset, rather than what one would actually see in them with a static demod phase. 

Since python from crontab seemed intractable, I replaced autoMX.py with a soft link that points at autoMX.sh.

This is a simple BASH script that looks at the LSC FB stat (C1:DAQ-DC0_C1LSC_STATUS), and runs the restart mxstream script if its non-zero.

So far its run 5 times successfully. I guess this is good enough for now. Later on, someone ought to make it loop over other FE, but this ought to catch 99% of the FB issues.

AutoMX is resetting mx_stream every 5 minutes. Basically everytime AutoMX is called,
it resets mx_stream. Is the mx_stream stalling such often? Or the script is detecting false alerms?

> tail -200 /opt/rtcds/caltech/c1/scripts/cds/autoMX.log

Tue May 19 16:43:01 PDT 2015
LSC - FB bad. Runnning restart:
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1sus closed.
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1lsc closed.
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1ioo closed.
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1iscex closed.
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1iscey closed.
0
Tue May 19 16:48:02 PDT 2015
LSC - FB bad. Runnning restart:
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1sus closed.
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1lsc closed.
ssh_exchange_identification: read: Connection reset by peer
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1iscex closed.
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1iscey closed.
0
Tue May 19 16:53:01 PDT 2015
LSC - FB bad. Runnning restart:
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1sus closed.
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1lsc closed.
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1ioo closed.
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1iscex closed.
 * Stopping mx_stream ...                                                 [ ok ]
 * Starting mx_stream ...                                                 [ ok ]
Connection to c1iscey closed.

Good catch; that was some seriously bad programming on my part. I had some undeclared variable garbage going on. I fixed it and re-implemented the script in CRON on megatron. The log file shows that it has detected no problems for the last several checks. I'll check it again tomorrow to see if its doing good or bad.

In the future, mirrors shouldn't be so close together that you can't get at their knobs to adjust them No good.  I ended up blocking the beam coming out of the PMC to prevent sticking my hand in some beam, making the adjustment, then removing the dump.  It worked in a safe way, but it was obnoxious. 

- we finished the MZ alignment; the contrast is good.

- we did the RFAM tuning using a new technique: a bubble balanced analyzer cube and the StochMon RFPD. This techniques worked well and there's basically no 33 or 166 RFAM. The 133 and 199 are as expected.

- the MC locked right up and then we used the periscope to align to it; the transmission was ~75% of max before periscope tuning. So the beam pointing after the MC should be fine now.

- the Xarm locked up with TRX = 0.97 (no xarm alignment).

If Rob/Yoichi say the alignment is now good, the we absolutely must center the IOO QPDs and IP POS and IP ANG and MC TRANS  today so that we have good references.

-----------------------------------

The first photo is of our nifty new setup to get the beam to the StochMon PD.  The MZ transmitted beam enters the photo from the bottom right corner, and hits the PBS (which we leveled using a bubble level).  The P-polarization light is transmitted through the cube, and the S-polarization is reflected to the left.  The pure S-polarized light hits a Beam Splitter, which we are using as a pickoff to reduce the amount of light which gets to the PD.  Most of the light is dumped on an aluminum dump.  The remaining light hits a steering mirror (Y1 45-S), goes through a lens, and then hits the StochMon PD.  While aligning the MZ to maximize visibility, we look at the small amount of P-polarized light which passes through the PBS on an IR card, and minimize it (since we want to be sending purely S-polarized light through the EOMs and into the MC).

The second photo is of a spectrum analyzer which is directly connected to the RF out of the StochMon PD.  To minimize the 33MHz and 166MHz peaks, we adjust the waveplates before each of the EOMs, and also adjusted the tilt of the EOM holders.

The final photo is of the EOMs themselves with the Olympus camera.

Once we finished all of our MZ aligning, we noticed that the beam input to the MC wasn't perfect, so Rana adjusted the lower periscope mirror to get the pointing a little better.  

The MZ refl is now at 0.300 when locked.  When Rana reduced the modulation depth, the MZ refl was about 0.050 .  Awesome!

C1:PSL-MZ_MZTRANSPD

I will investigate the MZ board. I will unlock MZ (and MC).

I aligned the MZ.  The reflection went from .86 to .374

I think the MZ pzt is broken/failing.  I'm not sure how else to explain this behavior.

The first bit of the time series is a triangle wave into the DC offset (output) field, over approximately the whole range (0-250V).   You can see the fringe visbility is quite small.  The triangle wave is stopped, and I then maxed out the offset slider to get to the "high" power point from the triangle wave sweep. Then for a little while with the PZT is held still, and the power still increases.  The MZ is then locked, and you can see the PZT voltage stay about the same but the power continues to rise over the next ~10 minutes or so.

This plot answers the previous question, and raises a new one--what the heck is MZTRANSPD?  I'd guess the pins are unconnected--it's just floating, and somehow picking up the MZ_PZT signal.

Came back from dinner to find the Mach Zehnder unlocked.  The poor IFO is kind of having a crappy day (computers, MZ, and I think the Mode Cleaner alignment might be bad too).

1. Delay fiber was replaced with 5m (~30 nsec delay)
   • The fringing of the MZ was way too large even with the free running NPRO (~3 fringes / sec)
   • Since the V/Hz is proportional to the delay, I borrowed a 5m patch cable from Andrew/ATF lab, wrapped it around a spool, and hooked it up to the setup
   • Much more satisfactory fringing rate (~1 wrap every 20 sec) was observed with no control to the NPRO
2. MZ readout PDs hooked up to ALS channels
   • To facilitate further quantitative study, I hooked up the two PDs monitoring the two ports of the MZ to the channels normally used for ALS X.
   • ZHL3-A amps inputs were disconnected and were turned off. Then cables to their outputs were highjacked to pipe the DC PD signals to the 1Y3 rack
   • Unfortunately there isn't a DQ-ed fast version of this data (would require a model restart of c1lsc which can be tricky), but we can already infer the low freq fringing rate from overnight EPICS data and also use short segments of 16k data downloaded "live" for the frequency noise measurement.
   • Channels are C1:ALS-BEATX_FINE_I_IN1 and C1:ALS-BEATX_FINE_Q_IN1 for 16k data, and C1:ALS-BEATX_FINE_I_INMON and C1:ALS-BEATX_FINE_I_INMON for 16 Hz.

At some point I'd like to reclaim this setup for ALS, but meantime, Anjali can work on characterization/noise budgeting. Since we have some CDS signals, we can even think of temperature control of the NPRO using pythonPID to keep the fringe in the linear regime for an extended period of time.

• Attachment #1 shows the time domain output from this measurement. The contrast between the maximum and minimum is better in this case compared to the previous trials.
• We also tried to extract the frequency noise of the laser from this measurement. Attachment #2 shows the frequency noise spectrum. The experimental result is compared with the theoretical value of frequency noise. Above 10 Hz, the trend is comparable to the expected 1/f characteristics, but there are other peak also appearing. Similarly, below 10 Hz, the experimentally observed value is higher compared to the theory.
• One of the uncertainties in this result is because of the length fluctuation of the fiber. The phase fluctuation in the system could be either because of the frequency noise of the laser or because of the length fluctuation of the fiber.  So,one of the reasons for the discrepancy between the experimental result and theory could be because of  fiber length fluctuation. Also, there were no locking method been applied to operate the MZI in the linear range.
• The next step would be to do a heterodyne measurement. Attachment #3 shows the schematic for the heterodyne measurement. A free space AOM can be inserted in one of the arms to do the frequency shift. At the output of photodiode, a RF heterodyne method as shown in attachment #3 can be applied to separate the inphase and quadrature component. These components need to be saved with a deep memory system. Then the phase and thus the frequency noise can be extracted.
• Attachment #4 shows the noise budget prepared for the heterodyne setup. The length of the fiber considered is 60 m and the photodiode is PDA255. I also have to add the frequency noise of the RF driver and the intensity noise of the laser in the noise budget.

Rana, Jenne, Koji

Last night we checked MZ. The apparent thing we found was the gain slider does not work.
The slider actually changes the voltage at the cross connection of 1Y2 (31 pin4?), the gain does not change.
The error spectrum didn't change at all even when the slider was moved.

Rana poked the flat cable at the bottom of 1Y2, we had no imporvement.

We coudn't find the VME extender board, so we just replaced AD602 (=VGA) and LT1125 (=Buffer for the ctrl voltage).
Even after the replacement, the gain slider is not working yet.

Today, I will put a lead or probe to the board to see whether the slider changes the voltage on the board or not.

Somehow the gain is sitting at a intermediate place that is not to low not to high. So I still don't know the gain slider
is the cause of the MZ instability or not.

the servo needs some work. 

2 day trend

MZ stayed unlocked. Now It was relocked.

12:45 I started the work on MZ. Thus the MZ was unlocked.

Found the bad connection on the FLKM 64pin cross connection board. We need a replacement.

I went to Wilson and got the replacement, two VME extender boards, three 7815, and three 7915. Thanks, Ben!

I found the MZ locked in a bad place earlier today.  It was locked in a similarly bad spot yesterday after we fixed the cable situation for 126MOPA_126MON, with reflection of ~0.8, rather than the nominal 0.305.  It's good now though. 

The MZ work completed. I replaced the bad cross connection terminal. The gain slider is working now.

I looked at the error spectrum on an FFT analyzer. I could see the lock was more tight.

Then I proceeded to the MZ epics panel.

1) C1:PSL-MZ_MZTRANSPD has no meaning (not connected). So I put  C1:PSL-ISS_INMONPD as the MZ trans monitor.

2) The EPICS setting for the MZ gain slider was totaly wrong.
    Today I learned from the circuit, the full scale of the gain slider C1:PSL-MZ_GAIN gave us +/-10V at the DAC.
    This yield +/-1V to V_ctrl of the AD602 after the internal 1/10 attenuation stage.
    This +/-1V didn't correspond to -10dB~+30dB, but does -22dB~+42dB and is beyond the spec of the chip.

    The gain of AD602 is calculated by

G [dB] = 32 V_crtl + 10,  for -0.625 [V]< V_ctrl < +0.625 [V].

    In order to fix this I used the following commands which overrode the EPICS parameters.
    The tip of EGUF/EGUL is to know how much the gain (virtually) goes for the full scale of the DAC output. 

ezcawrite C1:PSL-MZ_GAIN.EGUF 42
ezcawrite C1:PSL-MZ_GAIN.EGUL -22
ezcawrite C1:PSL-MZ_GAIN.DRVH 30
ezcawrite C1:PSL-MZ_GAIN.DRVL -10
ezcawrite C1:PSL-MZ_GAIN.HOPR 30
ezcawrite C1:PSL-MZ_GAIN.LOPR -10

   and for the permanent change I modified the db file /cvs/cds/caltech/target/c1iool0/c1iooMZservo.db
   This will be active when cliool0 is rebooted.

# This yields the output limited to -6.25V ~ +6.25V, which corresponds to -10dB ~ +30dB
# modified by Koji Arai (29-Sept-2009)
grecord(ao,"C1:PSL-MZ_GAIN")
{
        field(DESC,"GAIN- overall pre-modecleaner servo loop gain")
        field(SCAN,"Passive")
        field(PINI,"YES")
        field(DISV,"1")
        field(DTYP,"VMIVME-4116")
        field(OUT,"#C3 S5 @")
        field(EGUF,"42")
        field(EGUL,"-22")
        field(PREC,"1")
        field(EGU,"dB")
        field(HOPR,"30")
        field(LOPR,"-10")
        field(DRVH,"30")
        field(DRVL,"-10")
        field(LINR,"LINEAR")
        field(OROC,"0")
        field(DOL,"0")
}

# previous code
grecord(ao,"C1:PSL-MZ_GAIN")
{
        field(DESC,"GAIN- overall pre-modecleaner servo loop gain")
        field(SCAN,"Passive")
        field(PINI,"YES")
        field(DISV,"1")
        field(DTYP,"VMIVME-4116")
        field(OUT,"#C3 S5 @")
        field(EGUF,"30")
        field(EGUL,"-10")
        field(PREC,"4")
        field(EGU,"Volts")
        field(HOPR,"30")
        field(LOPR,"-10")
        field(LINR,"LINEAR")
        field(OROC,"0")
        field(DOL,"0")
}