40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 137 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  9785   Fri Apr 4 18:51:29 2014 ericqSummaryLSCMORE CARM related modeling

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. 

 carm2REFL11.pdfcarm2REFL55.pdf

carm2REFLDC.pdfcarm2TRX.pdf

 

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. 

 darm2AS11.pdfdarm2AS55.pdf

darm2ASDC.pdfdarm2TRX.pdf

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. 

ASDemodAngles.pdf 

  11250   Sat Apr 25 22:17:49 2015 ranaUpdateCDSMXstream restart script working (beta)

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

This is a simple BASH scriptcool 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 successfullylaugh. 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.

  11312   Tue May 19 17:03:34 2015 KojiUpdateCDSMXstream restart script working (beta)

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.

  11314   Tue May 19 18:38:33 2015 ranaUpdateCDSMXstream restart script working (beta)

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.

  186   Mon Dec 10 19:08:03 2007 tobinConfigurationPSLMZ
The MZ seems finicky today--it keeps unlocking and relocking.

I've temporarily blocked one of the MZ arms while I work on the ISS.
  1925   Tue Aug 18 15:52:27 2009 JenneUpdatePSLMZ
I tweaked up the MZ alignment.  The reflection had been around 0.550, which kept the MEDM indicator green, but was still too high.  I fiddled with BS1, and a little bit with BS2.  When I had the doors of the PSL table open, I got as low as 0.320.  When I closed up and came back to the control room, the MZ refl had drifted up to 0.354.  But it's good again now.

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. 

  1926   Tue Aug 18 19:57:47 2009 rana, JenneUpdatePSLMZ

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

 

  2148   Tue Oct 27 01:45:02 2009 robUpdateLockingMZ

Quote:
Tonight we also encountered a large peak in the frequency noise around 485 Hz. Changing the MZ lock point (the spot in the PZT range) solved this.


This again tonight.

It hindered the initial acquisition, and made the DD signal handoff fail repeatedly.
  1853   Fri Aug 7 11:39:13 2009 AlbertoUpdatePSLMZ Alignment
For the last couple of days we've been trying to find the cause that is preventing us to get more than 0.85 for the arm power.
After re-aligning the reference caivity yesterdau, today I went for the MZ. I slightly changed the alignment of the mirror in pitch. I was able to inrease the MZ-TRANPD to 4.8 (from about 3).
Unfortunately the same increase didn't show up at the MC transmission (that is IFO input) becasue changing the MZ also changed alignment to the MC cavity changed. A little tune of the MZ periscope was necessary to adjust the beam to the MC.
 
After all this MC-TRANS read 7.2 vs 7.0 before: no big of an improvement.
 
The arm power is still below 0.85.
 
Next step: measuring the MC length. Maybe changed a lot after the MC satellite was recently it by the people that were installing sesimometers and accelerometers on it.

 

  1195   Fri Dec 19 11:29:16 2008 Alberto, YoichiConfigurationMZMZ Trans PD
Lately, it seems that the matching of the input beam to the Mode Cleaner has changed. Also, it is drifting such that it has become necessary to continuously adjust the MC cavity alignment for it to lock properly.

Looking for causes we stopped on the Mach Zehnder. We found that the monitor channel:
C1:PSL-MZ_MZTRANSPD

which supposedly reads the voltage from some photodiode measuring the transmitted power from the Mach Zehnder, is totally unreliable and actually not related to any beam at all.

Blocking either the MZ input or output beam does not change the channel's readout. The reflection channel readout responds well, so it seems ok.
  2035   Thu Oct 1 13:12:41 2009 KojiUpdateMZMZ Work from 13:00-

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

  1395   Thu Mar 12 18:44:02 2009 YoichiUpdatePSLMZ aligned
The MC lost the alignment somehow this afternoon.
So I thought it was good time to touch the MZ because I had to align the MC using the periscope anyway.

I mainly touched the mirror with a PZT. The MZ reflection went down from 0.5 to 0.3.
  604   Mon Jun 30 15:08:52 2008 JohnSummaryPSLMZ alignment
I adjusted the alignmnet of the Mach-Zehnder's two North mirrors (downstream of the EOMs).

MZ REFL is reduced from 0.54 to 0.43. The largest improvement was due to pitch on the PZT mirror.
  607   Mon Jun 30 18:36:01 2008 YoichiUpdatePSLMZ alignment again
John, Yoichi

We re-adjusted the MZ alignment. The reason behind this is to make sure that the MZ dark port is not falling at a strange fringe, where it is only dark at the dark port PD. It can happen when the two beams poorly overlap.
We tried both the minimization of the MZ dark PD and the maximization of the MZ transmission at the same time.
We also placed another PD in the MZ dark port at a different distance from the original dark PD and tried to minimize this too.
If the MZ dark port is at a strange fringe, one of the dark PD can be dark where the other one is still bright.
If both of the dark PD get dark, the overlap between the beams should be ok.
We tweaked only the two mirrors of the MZ after the EOMs (mainly the one with a PZT).

Right now, the MZ dark power is 0.432.
BTW, we should change the name of the MZ dark port on the medm screen (it is now MZ reflection, where it is not a reflection).
I will try to change it later.

We wanted to put the beam position on the IOO-QPD_POS_* back to the original (before John tweaked the MZ alignment earlier).
However, the trends of IOO-QPD_POS_* show a lot of fluctuation and jumps, of which we don't know the cause. So we could not find reasonable original values.
We suspect a circuit problem in IOO-QPD_POS, especially because the jumps are very strange.
We will do this investigation later too.
  1876   Mon Aug 10 16:37:27 2009 robUpdatePSLMZ alignment touched

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

  1099   Wed Oct 29 12:23:04 2008 YoichiConfigurationPSLMZ alignment touched and the alarm level changed
Since the MZ reflection is alarming all the time, I tried to improve the MZ alignment by touching the folding mirror.
I locked the X-arm and monitored the transmitted light power while tweaking the mirror alignment to ensure that the output beam pointing is not changed.
I changed the alignment only a little, almost like just touching the knob.
The reflected power monitor was around 0.6 this morning and now it is about 0.525. Still large.
I changed the alarm level (HIGH) from 0.5 to 0.55.
  1874   Mon Aug 10 15:24:17 2009 robSummaryPSLMZ bad

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.

  1875   Mon Aug 10 15:56:12 2009 robSummaryPSLMZ bad redux

Quote:

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.

 

 

  2349   Mon Nov 30 19:23:50 2009 JenneUpdateMZMZ down

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

  14547   Wed Apr 17 00:43:38 2019 gautamUpdateFrequency noise measurementMZ interferometer ---> DAQ
  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.

  14571   Thu Apr 25 03:32:25 2019 AnjaliUpdateFrequency noise measurementMZ interferometer ---> DAQ
  • 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.
Quote:
  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.

  2017   Tue Sep 29 10:44:29 2009 KojiUpdateMZMZ investigation

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.

  1012   Wed Oct 1 02:10:03 2008 ranaUpdateIOOMZ is going bad
Here's a 2 day trend of the MZ. You can see that there is something bad with ERR - it should really be going to zero.

Also LODET is dead. We need to rejuvinate LODET somehow.

The next plot is a 90 day hour-trend of the same signals. You can see that LODET came back to us between
September 10 and 19 ??? I looked at a 4 year trend and it seems that this signal has always been zero
(nice use of disk space) except for a few days in Nov of 06 and then whatever happend on Sep 10.
  931   Fri Sep 5 08:34:03 2008 steveUpdatePSLMZ locked
The MC is happy.
The MZ can be locked if you move the slider by hand.
  1884   Tue Aug 11 01:21:55 2009 robUpdatePSLMZ needs some attention

the servo needs some work. 

 

2 day trend

 

  639   Mon Jul 7 13:49:27 2008 YoichiHowToPSLMZ offset, gain tips
John, Yoichi

This morning John found that MZ servo is not working.
We were able to bring the MZ back by changing the output offset a bit. But we were not sure what was actually wrong.
So we pulled out the MZ board and checked several TPs to understand the behavior.
Here is the summary of what we learned this morning.

The MZ control board has the following stages:

[Mixer] -(error signal)-> [Sum amp for input offset] -(error + offset)-> [Variable Gain Amp] -> [Filter (x100 DC gain)] -(FB signal)-> [High Voltage Amp] -> output
(The HV amp also works as the sum amp for the output offset)

(1) We noticed that the Sum amp for the input offset has an output of -0.14V even when the offset input is 0V. This can be canceled by the input offset slider.
So for the moment, it is fine. But we might want to change the op-amp because the weird offset implies there might be something wrong with the chip.
The procedure to null the -0.14V offset is the following:
a) Enable Test 1 input on the MZ MEDM screen.
b) Move the input offset slider until the mixer monitor becomes 0V. Currently the input offset slider is at -7.5V to cancel the -0.14V offset.

(2) Because the gain of the Variable Gain Amp and the Filter combined is large, the Filter can be easily saturated if the output offset is not right.
This was the cause of the MZ problem this morning. The output offset slider was at a wrong position making the error signal slightly off centered from zero.
This residual DC error signal was amplified by the large gain chain and saturated the filter amp.
Our experience is that the output offset cannot go below -3V. We set it at 0V for now.
  2032   Thu Oct 1 09:36:09 2009 KojiUpdateMZMZ relocked (Re:suspention damping restored and MZ HV stuck)

MZ stayed unlocked. Now It was relocked.

Quote:

Earthquake  of magnitude 5.0  shakes ETMY loose.

MC2 lost it's damping later.

 

  221   Thu Jan 3 09:12:59 2008 steveUpdatePSLMZ servo
Here is MZ trend for one year and 40 days.
Now days it runs out of range on the low side.
This is the weakest link in the psl today.
  611   Tue Jul 1 11:57:24 2008 YoichiConfigurationPSLMZ servo switch problem again
C1:PSL-MZ_BLANK switch (to turn on/off the servo) is not working again. The switch is always off regardless of the epics state.
I pushed the cables into the xycom card, but it did not fix the problem.
  616   Tue Jul 1 16:48:42 2008 rob, johnConfigurationPSLMZ servo switch problem resolved forever

Quote:
C1:PSL-MZ_BLANK switch (to turn on/off the servo) is not working again. The switch is always off regardless of the epics state.
I pushed the cables into the xycom card, but it did not fix the problem.


We have fixed this problem forever, by totally disabling this switch. Looking at the schematic for the MZ servo and the datasheet of the AD602, we found that a HI TTL on pin 4 disables the output of the AD602. Since the MZ servo was stuck in the off position, this seemed to indicate that it may be the XYCOM220 itself which is broken, constantly putting out a +5V signal regardless of the EPICS controls. We thought we might be able to get around this by disconnecting this signal at the cross-connect, but ultimately we couldn't find it because there is no wiring diagram for the Mach-Zehnder (!). So, we pulled the board and wired pin 9A of P1 to ground, permanently NORMALizing the MZ_BLANK switch. John has marked up the schematic, and someone should modify the MEDM screen and check the new screen into svn.

We can still the turn the MZ servo on and off by using the test input 1 switch.

Someone also will need to modify the MZ autolocker to use the test input 1 (MZ_SW1) instead of the old MZ_BLANK.
  2018   Tue Sep 29 12:47:08 2009 KojiUpdateMZMZ unlocked

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!

  1149   Thu Nov 20 09:37:39 2008 steveUpdatePSLMZ vs temp
This 12 days plot shows that it can hold lock if the daily temp variation is not more than 3/4 of a degree C
The MZ is happy if it's HV is above 100V
  2006   Sat Sep 26 13:55:20 2009 JenneUpdateMZMZ was locked in a bad place

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. 

  2020   Tue Sep 29 18:21:41 2009 KojiUpdateMZMZ work done

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")
}

Quote:

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

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

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

 

  2038   Thu Oct 1 19:04:05 2009 KojiUpdateMZMZ work done (Re: MZ Work from 13:00-)

MZ work has been done. I did not change anything on the circuit.

Recently we observed that the MZ PZT output was sticking at a certain voltage. I found the reason.
Shortly to say "we must return the PZT Ramp offset to 0, after the lock"

I am going to write a MZ auto lock script someday, to do it automatically.


According to the resister values used in the circuit, the PZT HV output voltage is determined by the following formula:

V_PZT = 150 - 12 V_ctrl - 24 Vramp

Here the ramp voltage Vramp moves from -10V to +10V, the feedback control voltage V_ctrl moves from -13V to +13V.
The baseline offset of 150V is provided in the circuit board.

When V_ramp is 0, V_PZT runs from 0 to 300. This is just enough for the full scale of the actual V_PZT range,
that is 0V~280V.

If any Vramp offset is given, V_PZT rails at either side of the edges. This limits the actual range of the PZT out.

This is not nice, but is what happened recently.

Quote:

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

 

  2021   Tue Sep 29 21:37:09 2009 ranaUpdateMZMZ work done : some noise checking

Since we used to run with a gain slider setting of +15 dB on the MZ, I wanted to check that the new setting of +30dB was OK. It is.

To check it I turned it up and looked for some excess noise in the ISS or in the MC. There was none. I also set the input offset slider by unlocking the PMC and zeroing the mixer monitor readback. The new slider setting is -6.5V.

I don't know why we would need more gain on the MZ loop, but we can have some if we want it by turning up the gain before the servo (optical or RF). The attached plot shows the MC_F and ISS signals with the ISS loop on and off. There was no change in either of these spectra with the MZ gain high or low.

  2022   Tue Sep 29 21:51:32 2009 KojiUpdateMZMZ work done : some noise checking

The previous "+15" was Vctrl = 0.25 [V]. Which was +18 dB.

Quote:

Since we used to run with a gain slider setting of +15 dB on the MZ, I wanted to check that the new setting of +30dB was OK.

 

  1244   Thu Jan 22 11:54:09 2009 AlbertoConfigurationPSLMach Zehnder Output Beam QPD
I rotated by 180 degrees the 10% beam splitter that it is used to fold the beam coming from the Mach Zehnder (directed to the MC) on to the QPD.

The alignment of the beam with that QPD has so been lost. I'll adjust it later on.

The rotation of the BS had the (surprising) effect of amplifying the Absolute Length experiment's beat by 9 times. Maybe because of a polarizing effect of the Beam Splitter which could have increased the beating efficiency between the PSL and the NPRO beams?
  1922   Tue Aug 18 01:16:01 2009 JenneUpdatePSLMach Zehnder is realigned

The Mach Zehnder and I got to know each other today.  The reason for redoing the alignment was to improve pointing from the PSL table into the MC/IFO in hopes that this would solve the MC unlocking problems that we've been having lately.  Since Rana had aligned the IOO QPDs a few weeks ago when all of the alignments and things were good, I used them as a reference for my Mach Zehnder alignment activities. 

 
The order of operations were approximately as follows:

1. Block the secondary (west) arm of the Mach Zehnder using either an aluminum or razor dump.

2. Use SM1 in the MZ to align the beam to the IOO_QPDs (Pos and Ang).  I unfortunately also touched BS2 at this juncture, which made the refl path no longer a reference.

3.  Make sure that the QPD Sum on both Pos and Ang was sensible.  Since there are 2 beamsplitters in a Mach Zehnder, the power on the QPDs should be a quarter when only one beam is on them.  Be careful not to allow the beam no clip on anything.  The biggest problem was the bottom periscope mirror - if you hit it too high or too low, since it is a very thick optic, you end up coming out its side!  This is the frosty part on the edges, totally inappropriate for beams to go through!  Since the side of the periscope mirror isn't HR coated, when going through it like this, I was able to saturate the QPDs.  Not so good. 

4. Also, make sure that this first beam is on the MZ Refl PD.  Do this using the steering optics after the beam has left the MZ.  Use a viewer to look at the PD, and see the small spot of the beam on the diode.  We closed the iris which is present and was standing fully open to remove a spurious beam which was a parallel split-off of the main beam.  Since it was very weak, it is fine.

5.  Unblock the west arm, and block the east arm of the MZ.

6. Align this arm to both the IOO QPDs and the MZ refl diode using the adjustments on BS1, the PZT mirror and if necessary, BS2.  Note that the adjust knobs on the PZT mirror have lock screws.  Make sure to unlock them before adjusting, and relock afterward, to avoid slipping while the PZT is moving.

7.  Unblock all the beams, and make sure there is only one spot both on the transmission side and the reflection side, i.e. the 2 spots from the 2 arms are completely overlapping.  For the Trans side, make sure to look both in the near field and the far field (even after the periscope) to ensure that you really have one spot, instead of just the 2 spots crossing at a single location.

8.  Look at the MZ refl DC out and the PD out from the ISS box (which is essentially MZ trans, looking at Morag and Siobhan) on a 'scope.

9.  Touch / gently wiggle BS1 or another optic, and watch the 'scope.  At the same time, adjust BS1, the PZT mirror and BS2 to maximize the contrast between light and dark fringes.  Ideally, the refl PD should go almost to zero at the dark fringes.

10.  Check that you still have only one overlapping beam everywhere, and that you're actually hitting the MZ refl PD.

11. Because I was concerned about clipping while still figuring out the status of the lower periscope mirror, I removed the beam pipe holders between the last optic before the periscope, and the lower periscope mirror.  The beam pipe had already been removed, this was just the pedestals and the snap-in clamps.

All done for now!  Still to be done:  Optimize the position of the EOMs.  There is a waveplate out front and the EOMs are mounted in such a way that they can be moved in several directions, so that we can optimize the alignment into them.  They ideally only should see a single polarization, in order to apply solely a phase modulation on the beam.  If the input polarization isn't correct, then we'll get a bit of amplitude modulation as well, which on PDs looks like a cavity length change.  Also, the little blue pomona-type box which has the RF signals for the EOMs needs to be clamped to the table with a dog clamp, or better yet needs to be moved underneath the PSL table, with just the cables coming up to the EOMs.  The SMA connections and the SMA cable kept interfering with the MZ refl beam...it's a wonder anyone ever made the beam snake around those cables the way they were in the first place. Right now, the box is sitting just off the side of the table, just inside the doors.

 
Something else that Rana and I did while on the table:  We moved the PMC trans optics just a teensy bit toward the PSL door (to the east) to avoid coming so unbelievably close to the MZ refl optics.  The PMC trans beam shown in the lowest part of my sketch was very nearly clipping on the MZ refl steering optic just near it.  This situation isn't totally ideal, since (as it has been in the past), the first optic which is dedicated to the PMC trans isn't fully sitting on the PSL table.  The pedestal needs to hang off the edge of the table a bit to keep this beam from clipping.  Unfortunately there really isn't space to make a better beam path.  Since we're planning on getting rid of the MZ when the upgrade happens, and this isn't causing us noticeable trouble right now, we're going to let it stay the way it is.

Also, we dumped the reflection from the PMC RFPD onto a razor blade dump. And we noticed that the PZT mirror and BS2 in the MZ are badly vibrationally sensitive. BS2 has a ~400 Hz resonance (which is OK) but a ~150 ms ringdown time!! PZT mirror is similar.

Q = pi * f * tau = 200!  Needs some damping.

  618   Tue Jul 1 21:45:48 2008 JohnUpdatePSLMach Zehnder script and screen
I've edited C1: PSL_MACH_ZEHNDER.adl and /cvs/cds/caltech/scripts/PSL/MZ/lockMZ
to reflect the changes described in entry #616.
  2406   Sun Dec 13 20:50:45 2009 ranaSummaryIOOMach Zender Calibration

I ramped the MZ PZT (with the loop disabled on the input switch) to calibrate it. Since the transmission has been blocked, I used the so-called "REFL" port of the MZ to do this.

The dark-to-dark distance for the MZ corresponds to 2 consecutive destructive interferences. Therefore, that's 2 pi in phase or 1 full wavelength of length change in the arm with the moving mirror.

Eyeballing it on the DTT plot (after lowpassing at 0.1 Hz) and using its cursors, I find that the dark-to-dark distance corresponds to 47.4 +/- 5 seconds.

So the calibration of the MZ PZT is 88 +/- 8 Volts/micron.

Inversely, that's a mean of 12 nm / V.

why am I calibrating the MZ? Maybe because Rob may want it later, but mainly because Koji won't let me lock the IFO.

Apparently, we haven't had a fast channel for any of the MZ board. So I have temporarily hooked it up to MC_DRUM at 21:13 and also turned down the HEPA. Now, let's see how stable the MZ and PMC really are overnight.

EDIT: it railed the +/- 2V ADCwe have so I put in a 1:4 attenuator via Pomona box. The calibration of MC_DRUM in terms of MZ_PZT volts is 31.8 cts/V.

So the calibration of MC_DRUM1 in meters is: 0.38 nm / count


  1151   Fri Nov 21 16:11:26 2008 rana, alberto, robUpdatePSLMach Zender alignment
The Mach Zender's dark port DC voltage had gone up too high (~0.5 V)and was turning yellow
on the screen. I re-aligned by touching the knobs on the 166 MHz path. Doing alignment after the
166 EOM had very little effect. The main improvement came from doing yaw on the turning mirror
just ahead of the 166 MHz EOM; this is the one which as no adjustment knobs (duh).

During this procedure, I had the MC off, the ISS off, and the MC autolocker off. After finishing
the alignment, the power on the ISS PDs had railed and the dark port power was ~0.29 V. So we
put in a ND0.2 on the ISS path and now the voltages are OK (~2 V on each PD). We have to remove the
ND filters and change the first ISS turning mirror into a ~10-20% reflector.


So now the MZ alignment seems good; Alberto is on the MC periscope alignment like a cheap suit.
  1155   Fri Nov 21 20:29:43 2008 rana, alberto, robUpdatePSLMach Zender alignment

Quote:
So now the MZ alignment seems good; Alberto is on the MC periscope alignment like a cheap suit.


And alignment is now mostly done - MC locks on the TEM00.
                 REFL_DC

Unlocked           4.50  V
Locked noWFS       1.30  V
Locked + WFS       0.42  V
and the 29.5 MHz modulation depth is really small.

We should be able to rerun the Wiener analysis on this weekends MC data.

I don't know what our nominal StochMon numbers now are, but after Alberto tweaks up the alignment he can tell us if the RFAM has gotten any better.
  1160   Mon Nov 24 17:14:44 2008 ranaUpdatePSLMach Zender trends
It looks like the MZ has gotten less drifty after the alignment on Friday.
  293   Fri Feb 1 17:17:05 2008 JohnSummaryPSLMach-Zender tweaking
I helped Rob adjust the alignment of the Mach-Zender to try and reduce any AM on the laser light. Our goal was to reduce the large offsets in the DD signals.

We reduced the MZ refl from 0.54 to 0.39. We were able to re-lock the mode cleaner without problems. We then centred the WFS heads.

No change in the DD signal offsets.
  7418   Thu Sep 20 08:50:14 2012 MashaUpdateMachineLearningMachine Learning Update

 Hi everyone,

I've been working a bit on neural network code for a controller, and thus far I have code that creates a reference plant neural network. This is necessary to perform a gradient-descent learning algorithm on a controller neural network (one that reads an error signal and outputs actuation force). Because the error signal is read after the previous output of the controller neural network has passed through the plant, in order to calculate the gradient, either the inverse of the plant needs to be calculated, or the plant can be simulated through a neural network, and the error signal can thus be back-propagated through the plant neural network to find the gradient with respect to the output (as opposed to with respect to the plant), and thus back-propagated through the controller network in order to learn. 

I have uploaded to my directory a directory neural_plant. The most important file is reference_plant.c, which compiles with the command

 gcc reference_plant.c -o reference_plant -lfann -lm

The code runs on a file called reference_plant.data, which consists of a series of delayed inputs i_1, i_2, i_3 ... i_{n - 1} of the plant signals and then an output that is i_{n}, the subsequent signal. Parallel streams may also be used, if more than one signal is to be read. The top of the file must contain the number of total training packets (input-output groups), followed by the number of inputs, and the number of outputs. reference_plant.c also has constant variables which specify the number of hidden neurons, which can be changed. 

 
All of this code runs on the FANN library. If the code doesn't seem to be compiling, then it means the library might have to be downloaded and built from source.
 
Thus far, I have created my own plant in simulink (the driven, damped harmonic oscillator, as before), and obtained results of 0.0002929292 training MSE after 5 epochs (subsequently lowered to 0.000)  and 0.000 training error. This, however, is due to the fact that my plant is overly simple, and seems only to need 3 time-delayed plant signals, rather 31 to specify it (since all motion is second-order). 
 
It should be fairly easy to use interferometer signals as input to this plant by just reading some signals and parsing them into time-delayed groups. (I tried this over the summer with my previous code, and it seemed to work, although I haven't accessed any of the channels to obtain data lately). 
 
In terms of LIGO stuff this week, I'm going to be finishing up (writing) my final report, but please let me know if you have any comments or concerns. 
 
Thanks!
  14164   Wed Aug 15 12:15:24 2018 gautamUpdateCOCMacroscopic SRC length for SR tuning

Summary:

It looks like we can have a stable SRC of length 4.044 m without getting any new mirrors, so this is an option to consider in the short-term.

Details:

  • The detailed calculations are in the git repo
  • The optical configuration is:
    • A single folding mirror approximately at the current SR3 location.
    • An SRM that is ~1.5m away from the above folding mirror. Which table the SRM goes on is still an open question, per the previous elog in this thread. 
  • The SRC length is chosen to be 4.044 m, which is what the modeling tells us we need for operating in the SR tuning instead of RSE.
  • Using this macroscopic length, I found that we could use a single folding mirror in the SRC, and that the existing (convex) G&H folding mirrors, which have a curvature of -700m, happily combine with our existing SRM (concave with a curvature of 142m) to give reasonable TMS and mode-matching to the arm cavity.
  • The existing SRM transmission of 10% may not be optimal but Kevin's calculations say we should still be able to see some squeezing (~0.8 dB) with this SRM.
  • Attachment #1 - corner plot of the distribution of TMS for the vertical and horizontal modes, as well as the mode-matching (averaged between the two modes) between the SRC and arm cavity.
  • Attachment #2 - histograms of the distributions of RoCs and lengths used to generate Attachment #1. The distributions were drawn from i.i.d Gaussian pdfs.

gautam 245pm: Koji pointed out that the G&H mirrors are coated for normal incidence, but looking at the measurement, it looks like the optic has T~75ppm at 45 degree incidence, which is maybe still okay. Alternatively, we could use the -600m SR3 as the single folding mirror in the SRC, at the expense of slightly reduced mode-matching between the arm cavity and SRC.

  6991   Thu Jul 19 02:14:37 2012 JenneUpdateVIDEOMade a video gui

I learned a little bit of python scripting while looking at the videoswitch script, and I made a video medm screen. 

Each monitor has a dropdown menu for all the common cameras we use (medm only lets you put a limited # of lines on a dropdown menu...when we want to add things like OMCR or RCT, we'll need to add another dropdown set)

Each monitor also has a readback to tell you what is on the TV.  So far, the quads only say "QUAD#", not what the 4 components are. 

I put a set of epics inputs in the PEM model, under a subsystem with top-names VID to represent the different monitors.  The readbacks on the video screen look at these, with the names corresponding to the numbers listed in the videoswitch script.  The videoswitch script now does an ezcawrite to these epics inputs so that even if you change the monitors via command line, the screen stays updated.

For example, since MC2F's camera is plugged in to Input #1 of the video matrix, if you type "./videoswitch MON1 MC2F", the script will write a "1" to the channel "C1:VID-MON1", and the screen will show "MC2F" in the Mon1 cartoon.

This required a quick recompile of the PEM model, but not the framebuilder since these were just epics channels.

There is also a dropdown menu for "Presets", which right now only include my 2 arm locking settings.

All of the dropdowns just call an iteration of the videoswitch script.

  1497   Sun Apr 19 11:51:05 2009 josephbUpdateCamerasMafalda may need an update

I tried installing libusb-dev on mafalda in order to try getting the usb frame grabber to work on it, but could not as it could not download the package.

I then tried to do a sudo apt-get update, which failed completely, as the repository seems to have ceased existing.  Basically I had all 404 Not Found errors.

Turns out Mafalda is still running Ubuntu 7.04, whose support ended late 2008.  So there's a couple things that can be done:

1) Ignore it, and simply not update Mafalda anymore.  This also means some newer software and hardware simply won't work with it (like the usb frame grabber)

2) Try to find another, unofficial repository which still has all of the Ubuntu 7.04 packages.

3) Upgrade to a newer, still supported Ubuntu, such as 7.10, 8.04, or 8.10.

I'd personally lean towards the 3rd option, and go to the 8.04 long term support version.  If people agree with it, I could do the upgrade sometime Monday or Tuesday.

 

 

  1499   Mon Apr 20 11:57:27 2009 robUpdateCamerasMafalda may need an update

Quote:

I tried installing libusb-dev on mafalda in order to try getting the usb frame grabber to work on it, but could not as it could not download the package.

I then tried to do a sudo apt-get update, which failed completely, as the repository seems to have ceased existing.  Basically I had all 404 Not Found errors.

Turns out Mafalda is still running Ubuntu 7.04, whose support ended late 2008.  So there's a couple things that can be done:

1) Ignore it, and simply not update Mafalda anymore.  This also means some newer software and hardware simply won't work with it (like the usb frame grabber)

2) Try to find another, unofficial repository which still has all of the Ubuntu 7.04 packages.

3) Upgrade to a newer, still supported Ubuntu, such as 7.10, 8.04, or 8.10.

I'd personally lean towards the 3rd option, and go to the 8.04 long term support version.  If people agree with it, I could do the upgrade sometime Monday or Tuesday.

 

 

 

I don't see a reason to proliferate operating systems.  Is there any reason we actually need Ubuntu? Can we put CentOS on it?

ELOG V3.1.3-