40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 264 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  8276   Tue Mar 12 00:58:05 2013 ManasaUpdateAlignmentYarm - Spot positions centered

[Jenne, Manasa]


Spot centering on Y arm - DONE!

Alignment procedure
1. I went back to the IFO alignment slider positions from Friday. The Y arm was flashing in HOM because the earthquake this morning tripped all suspensions and the slider values were not real. X arm did not have any flashes.

2. Y arm aligned using TT1 and TT2. Spot centering measured using Jenne's A2L_Yarm script.

Spot positions:
           ITMY    ETMY
Pitch    6.48    4.39
Yaw     -7.42    -3.135

3. I started centering in pitch. I used the same in-vac alignment method (down on TT1 and up on TT2 in pitch) and measured spot positions.

4. When the spot positions were centered in pitch, I started with yaw alignment.

5. I had to use TT1 to center on ITMY and move TT2 and ITMY to center on ETMY.

6. Spot positions after centering:

                          ITMY    ETMY
Pitch    -1.22    -1.277
Yaw       0.42    -0.731


7. I wanted to go back and tweak the pitch cenetering; but framebuilder failed and dataviewer kept loosing connection to fb

Notes
AS seems clipped. Although it could be because of the misaligned BS.

IPANG was centered on the QPD, but it is so clipped, that I'm not sure we can trust it.  Max sum right now is -4, rather than the usual -8 or -9.

Tomorrow:

Once fb is fixed, we should align the X-arm which will be followed by green alignment.

Mystery
Over the last few weeks, it has been observed that there is some strong seismic activity that starts at around 9PM everyday and goes on for a couple of hours. It seems unlikely that it is our geologist neighbour (Jenne met with the grad student who works on the noisy experiment).
 

  6155   Fri Dec 30 02:16:48 2011 kiwamuUpdateGreen LockingYarm ALS : high frequency noise reduced

The high frequency noise, which has been a dominant noise above 30 Hz in the Y arm ALS (#6133), decreased by a factor of 5.

This reduction was done by increasing the modulation depth at the Y end PDH locking. Now the noise floor at 100 Hz went to 0.2 pm/sqrtHz.

However the noise source is not yet identified and hence it needs a further investigation.

 

 The attached figure is the sensor noises, which were taken from the beat-note signal while the arm was locked by the IR-PDH.
The orange curve is the one before I changed the modulation depth and the red curve is the one taken after I increased the modulation depth.
The high frequency noise went down from 1 pm/sqrt Hz to 0.2 pm/sqr tHz at 100 Hz.
 
Yarm_ALS_2011Dec29.png

 (Increasing the modulation depth)

  Actually I was going to check the RAM noise at the Y end PDH locking as I planed (#6143).
During some preparation for it, I found that there had been a 20 dB attenuator in the modulation LO path.
The reason we have kept it is that somehow a big modulation depth made the reflected DC light noisier.
For curiosity I removed it to see what will happen and took the noise spectra. Then the noise decreased as shown in the plot above.
It means the noise source was like a kind of sensor noise, whose level depends on the responsivity of the sensor.
As far as I can tell, it is not the dark noise or shot noise according to some quick measurements.
  9258   Tue Oct 22 11:58:16 2013 MasayukiUpdateGreen LockingYarm ALS PDH

[Manasa, Masayuki]

Purpose

As this entry, Yarm ALS is not stable enough to lock PRMI + 2 arms. We tried to figure out what is the reason.

What we did

Check connection and alignment

1. Check the Green REFL PD.
Reflection is hitting the center of PD.

2. Check all the BNC connections
All connection are fine.

3. Check which power supply the PDH box is connected to.
PDH box is connected to 1Y4 AC power supply.

Check the control signal and error signal

4. Connected the PZT OUTMON to PC
Before the PZT output was not connected to the monitor channel. We connected that.

5. Saw the time series of the error signal and control signal (PZT output)
 When the Yarm lost end PDH lock, we found that control signal kicked the PZT of end green laser. And also we saw the saturation of control signal. We are not sure where this saturation comes from.

Discussion

With these check, we couldn't find any problem in connection or alignment. But the PDH control signal looks somehow strange. We tried to compare the Yarm signals with that of the Xarm, but we could not conclude anything meaningful.

We don't understand right now but we will continue to check that. We will add more details to the discussion once we have looked into the PDH box signals using oscilloscope.

 

  7002   Mon Jul 23 13:30:06 2012 JenneUpdateGreen LockingYarm ALS laser is funny / dying

Jamie and I were doing some locking, and we found that the Yarm green wasn't locking.  It would flash, but not really stay locked for more than a few seconds, and sometimes the green light would totally disappear.  If the end shutter is open, you can always see some green light on the arm transmission cameras.  So if the shutter is open but there is nothing on the camera, that means something is wrong.

I went down to the end, and indeed, sometimes the green light completely disappears from the end table.  At those times, the LED on the front of the laser goes off, then it comes back on, and the green light is back.  This also corresponds to the POWER display on the lcd on the laser driver going to ~0 (usually it reads ~680mW, but then it goes to ~40mW).  The laser stays off for 1-2 seconds, then comes back and stays on for 1-2 minutes, before turning off for a few seconds again.

Koji suggested turning the laser off for an hour or so to see if letting it cool down helps (I just turned it off ~10min ago), otherwise we may have to ship it somewhere for repairs :( 

  7004   Mon Jul 23 18:01:30 2012 JenneUpdateGreen LockingYarm ALS laser is funny / dying

 I turned the Yend laser back on....it hasn't turned itself off yet, but I'm watching it.  As long as we leave the shutter open, we can watch the C1:ALS-Y_REFL_DC value to see if there's light on the diode.

  8294   Thu Mar 14 16:41:48 2013 JenneUpdateGreen LockingYarm ALS laser is funny / dying

Quote (elog 7002, 23July2012):

Jamie and I were doing some locking, and we found that the Yarm green wasn't locking.  It would flash, but not really stay locked for more than a few seconds, and sometimes the green light would totally disappear.  If the end shutter is open, you can always see some green light on the arm transmission cameras.  So if the shutter is open but there is nothing on the camera, that means something is wrong.

I went down to the end, and indeed, sometimes the green light completely disappears from the end table.  At those times, the LED on the front of the laser goes off, then it comes back on, and the green light is back.  This also corresponds to the POWER display on the lcd on the laser driver going to ~0 (usually it reads ~680mW, but then it goes to ~40mW).  The laser stays off for 1-2 seconds, then comes back and stays on for 1-2 minutes, before turning off for a few seconds again.

Koji suggested turning the laser off for an hour or so to see if letting it cool down helps (I just turned it off ~10min ago), otherwise we may have to ship it somewhere for repairs :( 

 This is happening again to the Yend laser.  It's been fine for the afternoon, and I've been playing with the temperature.  First I have been making big sweeps, to figure out what offset values do to the actual temperature, and more recently was starting to do a finer sweep.  Using the 'max hold' function on the 8591, I have seen the beat appear during my big sweeps.  Currently, the laser temperature measurement is at the Yend, and the RF analyzer is here in the control room, so I don't know what temp it was at when the peaks appeared.

Anyhow, while trying to reaquire lock of the TEM00 mode after changing the temperature, I find that it is very difficult (the green seems misaligned in pitch), and every minute or so the light disappears, and I can no longer see the straight-through beam on the camera.  I went down to the end, and the same symptoms of LED on the laser head turning off, power out display goes to ~40mW, are happening.  I have turned off the laser as was the solution last time, in hopes that that will fix things.

Manasa has done some work to get the Xgreen aligned, so I'll switch to trying to find that beatnote for now.

  8300   Fri Mar 15 02:19:01 2013 JenneUpdateGreen LockingYarm ALS laser is funny / dying

I turned the laser back on around 1am.  This is still happening, although right now it is turning off more often than before, maybe every 15 seconds or so.  I am going to turn off the laser for the night.

The measured laser temperature is about 45C (I have a 25,000 count offset in the Y ALS Slow control right now....higher offset, lower temp), although the measured laser temp drops to ~43.5C when the power goes down.

  8301   Fri Mar 15 15:26:13 2013 KojiUpdateGreen LockingYarm ALS laser is funny / dying

I took a look at the laser. It is probably the LD TEC (DTEC) failure.
As the temperature of the LD (DTMP) gradually deviated from 25degCish,
the DTEC voltage also went up from 2Vish to 2.1, 2.2... 

When DTEC reaches 3V, it stopped lasing. This cools the diode a bit, and
it start lasing but repeat the above process.

I am not sure which of the head and controller has the issue.

The situation did not improve much by reducing the pumping current (ADJ: -15).

BTW, Turning on/off the noise eater did not change the situation.

I think the head/controller set should be sent out to JDSU and find how they will say.

  16909   Fri Jun 10 20:11:46 2022 yutaUpdateASCYarm ASS re-tuning in progress

[Anchal, Yuta]

We tried to re-tune Yarm ASS today. It cannot be fully closed as of now. I think we need to play with signs.

Motivation:
 - We want to make sure Yarm ASS work with current ITMY coil matrix (40m/16899).
 - ASS makes the beam positions on test masses to be the same every day.

What we did:
 - Adjusted A2L paths of C1:ASS-YARM_OUT_MTRX based on cavity geometry. For the paths to maximize the transmission using TT1 and TT2, we just assumed they are correctly calculated by someone in the past.
 - Adjusted OSC_CLKGAINs so that ITMY and ETMY will be shaken in the same amplitude in terms of radians. The ratio of the excitation was determined to take into account for the oscillator frequency difference between DOFs.
 - Checked the time constant of A2L paths by turning on A2L paths only, and checked that of max-transmission paths by turining on them only.
 - Adjusted DEMOD_SIG_GAINs so that their time constants will be roughly the same, with C1:ASS-YARM_SEN_MTRX fully identity matrix and all servo GAINs to be +1.
 - Re-tuned DEMOD_PHASEs to minimize Q signal. C1:ASS-YARM_ITM_PIT_L_DEMOD_PHASE and C1:ASS-YARM_ITM_YAW_T_DEMOD_PHASE were re-tuned within +/- 5 deg.
 - These changes are recorded in /opt/rtcds/caltech/c1/Git/40m/scripts/ASS/ASS_DITHER_ON.snap now.

Result:
 - A2L loops seems to be working, but max-transmission paths seems to diverge at some point. I think we need to play with the signs/gains of max-transmission paths for C1:ASS-YARM_OUT_MTRX.
 - Attached is the current configuration we achieved so far.

Attachment 1: Screenshot_2022-06-10_20-10-52.png
Screenshot_2022-06-10_20-10-52.png
  16911   Mon Jun 13 20:26:09 2022 yutaUpdateASCYarm ASS re-tuning in progress -part 2-

[Anchal, Yuta]

We are still in the progress of re-commissioning Yarm ASS.
Today, we tried to adjust output matrix by measuring the sensing matrix at DC.
Turning on yaw loops kind of works, but pitch does not. It seems like there is too much coupling in pitch to yaw.
We might need to adjust the coil output matrix of ITMY and ETMY to go further, and/or try measuring the sensing matrix including pitch - yaw coupling.

What we did:
 - Confirmed that turning on TT1 and TT2 loops (max-transmission loops) work fine. When we intentionally misalign TT1/2, the ASS loops correct it. So, we moved on to measure the sensing matrix of A2L paths, instead of using theoretical matrix caluclated from cavity geometry we used last week (40m/16909).
 - Instead of +/-1's, we put +/-2's in the ITMY coil output matrix to balance the actuation between ETMY and ITMY to take into account that ITMY is now using only two coils for actuating pitch and yaw (40m/16899).
 - Measured the change in C1:ASS-YARM_(E|I)TM_(PIT|YAW)_L_DEMOD_I_OUT16 error signals when offset was added to C1:SUS-(E|I)TMY_ASC(PIT|YAW)_OFFSET. We assumed pitch-yaw coupling is small enough here. Below was the result.

                            ETM PIT error  ITM PIT error
ETM PIT OFFSET of +100cnts: -3.0cnts       -2.99cnts
ITM PIT OFFSET of +100cnts
: -11.94cnts      -5.38cnts

                            ETM PIT error  ITM PIT error
ETM YAW OFFSET of +100cnts:
-3.42cnts      -16.93cnts
ITM YAW OFFSET of +10 cnts: +1.41cnts      +0.543cnts


 - Inverted the matrix to get A2L part of C1:ASS-YARM_OUT_MTRX. Attachment #1 is the current configuration so far.
 - With this, we could close all yaw loops when pitch loops were not on. But vise versa didn't work.
 - Anyway, we aligned the IFO by centering the beams on test masses by our eyes and centered all the oplevs (Attachment #2).

Next:
 - Do coil balancing to reduce pitch-yaw coupling
 - Measure sensing matrix also for pitch-yaw coupling
 - Xarm ASS is also not working now. We need to do similar steps also for Xarm

Attachment 1: Screenshot_2022-06-13_20-47-12.png
Screenshot_2022-06-13_20-47-12.png
Attachment 2: Screenshot_2022-06-13_20-44-43.png
Screenshot_2022-06-13_20-44-43.png
  16915   Tue Jun 14 20:57:15 2022 AnchalUpdateASCYarm ASS working now

I finally got YARM AS to work today. It is hard to describe what worked, I did a lot of monkey business and some dirty offset measurements to create the ASS output matrix that gave results. Note that I still had to leave out ITMY PIT L error signal, but transmission was maximizing without it. The beam does not center fully on ITMY in Pit direction right now, but we'll mvoe on from this problem for now. Future people are welcome to try to make it work for this last remaining error signal as well.

commit

 

  10407   Mon Aug 18 18:33:57 2014 ericqUpdateGreen LockingYarm Green PDH

So far today, I've been working with the Y-end green PDH locking. Using a SR560 to roll off the AG4395A output to take a loop measurement at the servo output, I measured the following OLG, and inferred the CLG from it. The SR560 really helped it getting good coherence without introducing a big offset that changes the optical gain, thus distorting the loop shape, etc. etc. 

yLoop.pdf

You would think this loop looks pretty good, 10k UGF, and 45 degrees of phase margin, gain peaking is sane, and pretty smooth slope. But, the thing still was flipping out of lock while I measured this. 

I suspect shenanigans at >100k. This is motivated by the fact that I've seen some big noise in the error signal around 150k. I don't have a good noise plot right now, because I'm trying to get a scheme going where I stitch together a bunch of 1 decade spectra from the 4395, but the noise floor isn't consistent across each patch (even though the attenuation stays the same, and I confirmed I'm in "noise" mode). I'm working on a loop measurement up there, too, but I haven't been able to get the right filter/amplitude settings yet. 

So, even though this plot is not totally correct (read: wrong and bad), I include it just for the sake of showing the big honking spike of noise at ~150K.  

crap.pdf

 

  10408   Tue Aug 19 01:01:36 2014 Jenne, RanaUpdateGreen LockingYarm Green PDH

[ Rana, Jenne]

We remeasured the Yend PDH box.

When we first started, the green couldn't hold lock to the arm - it kept flickering between modes.  Changing the gain of the PDH box (from 7.5 to 6.0) helped.

We measured a calibration, from our injection point to our measurement point.

The concept was that we'd take the mixer output, and put that into an SR560, and put the swept sine injection into the other input port of the '560, and use A-B.  So, for this calibration, we left A unplugged, and just had the RF out of the 4395 going to input B of the '560.  The 600 Ohm output of the '560 went to the error point input on the PDH box (during normal operation the mixer output is connected directly to the error point input).  The SR560 was set to gain of 1, no filtering.  I don't recall if we were using high range or low noise, but we tried both and didn't really see a difference between them.

We had the 4395 take that calibration out, and then we measured the closed loop gain up to 1 MHz. (Same measurement setup as above, but we connected the mixer out to the input of the SR560 to close the loop, and made sure we were locked on a TEM00 green mode.) Rana used an ipython notebook to infer the open loop gain from our measurement.  Our conclusion is that we don't have nearly enough gain margin in our loop.  We found the PDH box gain knob at 7.5, and we turned it down to 6.0, but the loop is still pretty borderline. We used the high impedance active probe to measure the error point monitor, since we aren't sure that that point can drive a 50 Ohm load.

YPDH_OLG.pdf

We also measured the error point spectra and the control point spectra.  Unfortunately, the saved data from the analyzer (no matter what is on the screen) comes out in spectrum, not spectral density.  So, we need to check our conversion, but right now to get from Watts power to Volts, we do sqrt(50 ohm * data).  We then need to get to spectral density, and right now we're just dividing by the square root of the bandwith that is reported in the .par file. This last step is the one we want to especially check, by perhaps putting some known amount of noise (from an SR785?) into the 4395, and checking that our calibration math returns the expected noise spectrum.

What still needs to be done is to calibrate this into Hz/rtHz.  To do this, we were thinking that we should look at the error point on a 'scope while the cavity is flashing.

Anyhow, here is the uncalibrated error point spectrum.  Purple is a measurement up to 30kHz, with 30Hz bandwidth.  Blue is a measurement up to 300kHz with 300Hz bandwidth.  The gain peaking schmutz above 10kHz sucks, and we'd like to get rid of it.  We also see the same peak at ~150kHz that Q saw earlier today.  We were using the high impedance probe here too.

YPDH_noise.pdf

 We have the data for the control point (all the data files are in /users/jenne/ALS/PDHloops/Yend_18Aug2014), but we haven't plotted it yet.

Things that need doing:

* (JCD) Think about this box's purpose in life.  What kind of gain do we need?  Do we need more / less than we're currently getting? NPRO freq noise is 1/f and is 10kHz/rtHz at 1Hz (this is from a plot of an iLIGO NPRO from Rana's thesis, but it's probably similar). Talk to Kiwamu; the noise budget in the paper seems to indicate that we had some kind of boost on or something.  Also, if we need much more gain than we already have, we'll definitely need a different box, maybe the PDH2 box that they have over in WBridge.

* (EQ, priority 1) Measure and calibrate error point noise down to lower freq for both arms.  What could we win by putting in a boost? If the residual noise is high, maybe the laser isn't good at following arm, so beatnote isn't good length info for the arm, and we can't succeed.

* (EQ, priority 2) Measure TF of PDH box, and a separate measurement of the Pomona box that is between the mixer and the error point - is that eating a bunch of phase?  It's already an LC circuit which is good, but do we really want a 120kHz lowpass when our modulation frequency is roughly 200kHz?  Ask ChrisW - he worked on one of these with Dmass.

* (EQ, priority 2ish) Measure TF of Xend PDH loop (unless you already have one, up to ~1MHz).

* (JCD) Make DCC tree leaf for PDH box #17.  Take photos of box.

  10409   Tue Aug 19 18:32:40 2014 ericqUpdateGreen LockingYarm Green PDH

Heading to dinner, going to come back for more green fun, but here's a quick update:

Xarm Peak-to-Peak of the PDH signal in the mixer output is about 70mV when GTRX was about 0.4. The sideband-generating function generator has an output of 2V (forgot to note rms or pp)

Yarm Peak-to-Peak of the PDH signal in the mixer output is about 640uV when GTRX was about 0.71. The sideband-generating function generator has an output of 0.091V (forgot to note rms or pp)

The Yarm signal thus correspondingly has a waaay noisier trace. I would've had scope plots to show here, but the scope freaked out about how large my USB drive capacity was and refused to talk to it >:|

This suggests to me that our modulation depth for the Yarm may be much too small, and may be part of our problems with it. 

  10411   Tue Aug 19 23:11:15 2014 JenneUpdateGreen LockingYarm Green PDH

 

 Here is a plot of last night's data with both the control and the error point on the same plot, in Volts.  Q is still working, so I don't have a calibration number yet to get these to Hz.

Note in the control spectrum that we have very significant 60Hz lines.  

ErrAndCtrlSpectra_VoltsPerRtHz.png

EDIT:  I also added a new branch to the DCC Document Tree, and 2 leafs (one for each end).  Here's the ALS PDH servo branch: E1400350

  10412   Wed Aug 20 02:38:41 2014 JenneUpdateGreen LockingYarm Green PDH - requirement

Quote:

* (JCD) Think about this box's purpose in life.  What kind of gain do we need?  Do we need more / less than we're currently getting? NPRO freq noise is 1/f and is 10kHz/rtHz at 1Hz (this is from a plot of an iLIGO NPRO from Rana's thesis, but it's probably similar). Talk to Kiwamu; the noise budget in the paper seems to indicate that we had some kind of boost on or something.  Also, if we need much more gain than we already have, we'll definitely need a different box, maybe the PDH2 box that they have over in WBridge.

It's not so impressive yet, but here's a plot that shows (a) Rana's guess for laser frequency noise, (b) The inferred in-loop version of that noise, (c) The CARM linewidth FWHM, translated to Hz.

For (b), I take the loop that Rana and I measured last night, and I assumed that it continued on forever as 1/f toward low frequency.  Then I do 1/(1+G) to get the closed loop version of the loop (which is a measurement with an artificial line tacked on the end), and multiply this with the laser freq noise, which is also totally artificial.

For (c), I do df/f = dL/L, with f = c/lambda_green, since the rest of the plot is meant to be in green frequency units.

This is my beginnings of trying to come up with a requirement for our green PDH boxes.  We weren't very clear in the MultiColor paper about the nitty-gritty details (obviously), but then Kiwamu didn't expand on those details in his thesis either.  He talks a lot more about the design considerations for the digital ALS loop, which isn't what I want today.  I will send him an email to see if he had any notes that didn't make it into his thesis.

NoiseConsideration.pdf

  10416   Wed Aug 20 18:05:18 2014 JenneUpdateGreen LockingYarm Green PDH - requirement

 

 I calibrated the control signal from Volts to Hz using the rough PZT calibration of 5MHz/V for the Yend NPRO.  

For the error signal, Q said that the Yarm PDH peak-to-peak height was about a factor of 100 smaller than the Xarm, so I used a calibration of 1.9e7 Hz / V.

Then, from Q's Mist simulation including the high Xarm loss, and the plot that he posted in the control room, the CARM linewidth looks like it is about 2pm.  This is the number that I have included on today's plot.  Note though that yesterday I was using a linewidth of about 30pm, which I got from an Optical simulation about a year ago.  I do not know why these numbers come out an order of magnitude different!      The CARM linewidth is actually about 20 pm.  Both Q and I failed at reading log-x plots yesterday.  I have corrected this, and replotted.

Anyhow, here's the Yarm noise spectra calibrated plot:

YPDH_noise.pdf

I have emailed Kiwamu, but haven't heard back from him yet on what the original design considerations were, if he remembered us ever using a boost, etc.  What this looks like to me is that we need to do some serious work to get the noise down.  Maybe fixing the gain peaking and triggering the boost will get us most of the way there?

  14236   Sun Oct 7 22:30:42 2018 yukiConfigurationLSCYarm Green locking was recovered

I finished installation of optics in the Y-end and recovered green locking. Current ALS-TRY_OUTPUT is about 0.25, which is lower than before. So I still continue the alignment of the beam. The simulation code was attached. (Sorry. The optic shown as QWP2 is NOT QWP. It's HWP.)

Attachment 1: Pic_NewLayout1007.jpg
Pic_NewLayout1007.jpg
Attachment 2: YendGreenModeMatching.zip
  14240   Tue Oct 9 23:03:43 2018 yukiConfigurationLSCYarm Green locking was recovered

[ Yuki, Gautam, Steve ]

To align the green beam in Y-end these hardware were installed:

  • PZT mirrors in Y-end table
  • PZT driver in 1Y4 rack
  • Anti-Imaging board in 1Y4 rack
  • cables (DAC - AIboard - PZTdriver - PZT)
  • high voltage supplier 

I made sure that DAC CH9~16 and cable to AI-board worked correctly. 

When we applied +100V to PZT driver and connected DAC, AI-board and PZT drive, the output voltage of the driver was not correct. I'll check it tomorrow.

Attachment 1: Pic_1Y4.jpg
Pic_1Y4.jpg
Attachment 2: Pic_PZTcable.jpg
Pic_PZTcable.jpg
  7346   Wed Sep 5 19:29:45 2012 JenneUpdateGeneralYarm aligned to IR incident beam

[EricQ, Jenne, brains of other people]

Checked at ETMY that the pointing hadn't changed a whole lot.  Jamie and Koji pointed out that we were half falling off of the IPANG QPD.  Adjusted PZT2 sliders so that we were again centered on IPANG's QPD.  Before we close up, we'll want to put the sliders back to their nominal positions, and use the knobs to hit IPANG, but this is equivalent and fine for now.  The tip tilts don't seem to have moved much overnight, since the beam drift on both IPANG and ETMY was fixed simultaneously with PZT2 (recall, IPANG picked off before tip tilts exist in the beam path).  This left us hitting the center of ETMY.  We moved ETMY sliders to make the reflected beam hit the center of ITMY (same spot position as transmitted beam from BS).  Then moved ITMY to get prompt reflection to hit same spot on ETMY as original primary beam from BS.  Checked at ITMY that we didn't need to move ETMY anymore.  (Actually, I forget how many iterations we did, but in the end, all of the reflections that we can find are co-located on the test masses.)

Next up:

Align BS so we're hitting the center of ETMX

Tap / readjust ITMX OSEM which is at 0.3 to get it back to the center of its range

Align ITMX to lock MICH

Check no clipping on POX / POY optics, no clipping around BS

Check PRM, SRM alignment (what exactly do we want to do here? Try to lock PRMI / SRMI?)

Get IPPOS out of vac

Fix clipped ITMY / SRM oplev

Install 'black' glass beam dumps - forward-going POP beam, 2 places in BS chamber (check old elog from Jenne/Yuta for the places).

Get green spots co-located with IR spots on ETMs, ITMs, check path of leakage through the arms, make sure both greens get out to PSL table

  8235   Tue Mar 5 23:00:08 2013 yutaUpdateLSCYarm and PRC g-factor from misalignment measurement

I fitted intra-cavity power dependance on mirror misalignment plot with parabola to get the g-factor.

  Y arm (tangential) g = 0.44 +0.01 -0.01  (measured value before was 0.3765 +/- 0.003 elog #6938)
  PRC (sagittal)       g = 0.97 +0.01 -0.04 (expected value is 0.939 elog #8068)
  PRC (tangential)   g = 0.96 +0.02 -0.05 (expected value is 0.966 elog #8068)

Error bars are just statistical errors from the fitting. Estimated systematic error is ~0.04 (or more).
Here, I assumed PR2/PR3 to be flat to make the calculation simple. I assumed PRC to be curved PRM - flat ITM cavity, and Y arm to be curved ETMY - flat ITMY cavity.

g-factor calculation:
  Intra-cavity power decrease can be written as

dP/P = (dx/w0)**2 + (dt/a0)**2

where dx and dt are translation and tilt of the beam axis introduced by mirror misalignment. w0 is waist size and a0 is divergence angle (= lamb/(pi*w0)).

  When considering a flat-curved cavity with cavity length L, dx and dt can be expressed as;

(dx)    1  ( L*g     L ) (a2)
(  ) = --- (           )*(  )
(dt)   1-g ( -(1-g)  0 ) (a1)


using misalignments of mirrors(a1,a2). Here, mirror1 is curved, and mirror2 is flat. See Kakeru document /users/OLD/kakeru/oplev_calibration/oplev.pdf for derivation.

  So, power decrease by flat mirror misalignment can be expressed as

dP/P = pi*L/lamb * g/(1-g)/sqrt(g*(1-g)) * a2**2

  For curved mirror is

dP/P = pi*L/lamb * 1/(1-g)/sqrt(g*(1-g)) * a1**2

  We can derive g-factor by measuring dP dependance on a1/a2.


Script:
  My script lives in /opt/rtcds/caltech/c1/scripts/dither/gfactormeasurement/plotgfactor.py.
  It least fitts data with parabola (scipy.optimize.leastsq) and gets g-factor value from bisection (scipy.optimize.bisect).


Result:
  Below are the plots of fitted curves.

ITMY_YAW_20130305_DC.pngPRM_PIT_20130305a_DC.pngPRM_YAW_20130305b_DC.png


Systematic effect:
  [oplev calibration] We noticed QPD rotation when calibration oplevs (elog #8232). ~5 deg of rotation makes 10% of systematic error to the oplev calibration and this introduces ~0.04 of error to g-factor values. This

  [oplev linear range] Oplev linear range is ~100 urad, so this is OK.

  [assumption of flat PR2/PR3] Result here doesn't tell you g-factor of PRM itself, but some "effective g-factor" of PRM/PR2/PR3 combination. We can compare with FINESSE result.

  [intra-cavity power drift] If there's significant intra-cavity power drift during the measurement, if effects parabola fitting. We can make this affect small by sweeping the mirror alignment in both direction and take average.


By the way:
  I kept getting PRC g-factor of something like 0.999999 because I had power normalization mistake in my calculation. My script worked for Yarm because TRY is already normalized.
  Also, I was multiplying the oplev calibration factor wrong last night (see elog #8230).

Next:
  - Compare with FINESSE result.
  - Is this g-factor enough? Is this presicion enough? Calculate from mirror angluar motion.
  - More stable lock of PRMI.
  - Try dithering method to measure g-factor to check consistency and also to study systematic effect.

  6711   Tue May 29 21:50:21 2012 JenneUpdateLockingYarm error spectra

The ~16Hz bounce mode of some optic is showing up in the Yarm error signal. 

MC is kind of 'windy' looking, so maybe it's from that? (Yuta's guess).

We need to make sure that the SUS damping and oplev paths both have notches at the correct bounce mode, not the old, old MOS frequency.  If that doesn't work, may need to put a resgain in Yarm path.

Attachment 1: LSC_POY_11_I_ERR_29May2012.pdf
LSC_POY_11_I_ERR_29May2012.pdf
  6714   Wed May 30 13:24:08 2012 JenneUpdateLockingYarm error spectra

Quote:

The ~16Hz bounce mode of some optic is showing up in the Yarm error signal. 

MC is kind of 'windy' looking, so maybe it's from that? (Yuta's guess).

We need to make sure that the SUS damping and oplev paths both have notches at the correct bounce mode, not the old, old MOS frequency.  If that doesn't work, may need to put a resgain in Yarm path.

 Made the Bounce notch in the BounceRoll filter (ITMY OLPIT, ITMY OLYAW)  wider, so it actually spans the peak we see in the error spectra.  When we next lock the arm later today, I'll retake this spectra to see if the ETMY oplev fix (Koji, Yuta) and this notch fix both helped.

  6279   Tue Feb 14 15:52:11 2012 JenneUpdateAuxiliary lockingYarm fiber returned to ATF

[Frank, Jenne]

We extracted the fiber that Suresh and Sonali laid over the summer, for the IR beat for the Ygreen laser, and Frank took it back to Bridge to be used in the new fiber distributed reference laser setup.

  5051   Thu Jul 28 02:33:04 2011 JenneUpdateLockingYarm flashing, but not yet locked

Because I'm too lazy to write a cohenrent elog right now, here's my notes that I wrote while working tonight:

Elog notes, 27July2011

Aligned Xarm, just to check on it.  Had to flip sign of TRX in DCPD filter bank (to gain of -1) to make the signal positive.

Restored Yarm, see some slight flashing, but no lock yet.
Adjusted phase rotation of AS55 from 56.5deg to 60deg, just by-eye trying to maximize AS55I, my arm error signal. AS55I goes from ~ -40 to +60 counts

Tried fitzing with Yarm gain, flipping sign, incr gain. No real change in signals, or flashing.


Incr. ETMY oplev gains to -0.4 from -0.2
Engaged ELP35's on Pit and Yaw, to be more similar to other optics.  However, right now all of the optics have different things in their filter banks.  Why??

Arm is flashing pretty reliably now, but still not locking.  The trigger threshold is always satisfied, so that's not it.

  7030   Wed Jul 25 16:31:01 2012 JenneUpdateLSCYarm green locking to arm - PDH box saturating

Quote:

... it was not possible to get the cavity locked in green. So we decided to do the first measurement with infrared locked only. 

 When we sat down to align the Yarm to the green, the green light was happy to flash in the cavity, but wouldn't lock, even after Jan had tweaked the mirrors such that we were flashing the TEM00 mode.  When we went down to the end to investigate, the Universal PDH box was saturating both negative and positive.  Turning down the gain knob all the way to zero didn't change anything, so I put it back to 52.5.  Curiously, when we unplugged the Servo OUT monitor cable (which was presumably going to the rack to be acquired), the saturation happened much less frequently.  I think (but I need to look at the PDH box schematic) that that's just a monitor, so I don't know why that had to do with anything, but it was repeatable - plug cable in, almost constant saturation....unplug cable, almost no saturation.

Also, even with the cable unplugged, the light wouldn't flash in the cavity.  When I blocked the beam going to the green REFL PD (used for the PDH signal), the light would flash.

Moral of the story - I'm confused.  I'm going to look up the PDH box schematic before going back down there to investigate.

  8825   Thu Jul 11 03:14:19 2013 JenneUpdateLSCYarm held nicely on IR resonance with ALS, PRMI+arm attempt

[Annalisa, Jenne, Nic]

After having troubles with the Xarm earlier (maybe Manasa can write/say something about this?  Something about perhaps seeing the phase tracker jump, and cause it to lose lock?), we moved on to the Y arm. 

Annalisa locked the Yarm green, and closed the ALS loop.  I believe that earlier today, she tuned the gain such that we don't start getting gain peaking at a few hundred Hz.  We would like to get a script going, so that it's not so labor intensive to reclose the ALS loop after an MC lockloss....but that's a daytime task.

We then found the IR resonance, using only the Yarm ALS system.  After Manasa's work yesterday, the Yarm was very stable while locked with the ALS.  We took a power spectrum of POY11_I_ERR, which I have calibrated using the number in elog 6834 of 1.4e12 cts/m, or 7.14e-13 m/ct.  See the figure below.

After that, we changed the offsetter2 offset such that the arm was off resonance, but not so far off that we crossed any significant resonances (in particular, we wanted to not go as far as the 55MHz resonance). 

Then, I tried to lock the PRMI for a while, but the alignment wasn't very good.  We knew that the Yarm was well aligned, since our IR resonance was > 0.98, but it had been a while since we had aligned the X arm.  I tweaked the ITMX position to make the Michelson dark, and then tried acquiring PRMI lock.  At first, I tried with REFL165 I and Q, but with the non-ideal alignment and the offset in the 165 diode (LSC offsets was not run this evening), I wasn't catching any locks.  I then switched to AS55Q and REFL33I, but wasn't able to catch lock there either. 

The MC lost lock, which made us lose the ALS loop, but the ALS had been locked for more than 30 minutes, at least.  I tried locking the PRMI with the current alignment (after having misaligned ETMY), but was only able to get lock stretches of 1 second at maximum.

We are calling it a great success for the night, since we have confirmed that, at least for the Yarm, Manasa's beatbox work has improved things.  Also, we have a pretty solid plan for trying the PRMI+arm tomorrow, even though it didn't work out tonight.

Attachment 1: Yarm_onIRresonance_noPRMIyet_POYcalibrated.pdf
Yarm_onIRresonance_noPRMIyet_POYcalibrated.pdf
  8826   Thu Jul 11 07:34:42 2013 manasaUpdateLSCYarm held nicely on IR resonance with ALS, PRMI+arm attempt

Quote:

We knew that the Yarm was well aligned, since our IR resonance was > 0.98, but it had been a while since we had aligned the X arm. 

 The X arm was locked with TRX>0.98 earlier last night while I was measuring the out of loop noise of the phase tracker.

  14403   Wed Jan 16 16:25:25 2019 gautamUpdateSUSYarm locked

[chub, gautam]

Summary:

Y arm was locked at low power in air.

Details:

  1. ITMY chamber door was removed at ~10am with Bob's help.
  2. ETMY table leveling was found to have drifted significantly (3 ticks on the spirit level, while it was more or less level yesterday, should look up the calib of the spirit level into mrad). Chub moved some weights around on the table, we will check the leveling again tomorrow.
  3. IMC was locked.
  4. TT2 and brass alignemnt tool was used to center beam on ETMY.
  5. TT1 and brass alignment tool was used to center beam on ITMY. We had to do a c1susaux reboot to be able to move ITMY. Usual precautions were taken to avoid ITMX getting stuck.
  6. ETMY was used to make return beam from the ETM overlap with the in-going beam near ITMY, using a holey IR card.
  7. At this point, I was confident we would see IR flashes so I decided to do the fine alignment in the control room.

We are operating with 1/10th the input power we normally have, so we expect the IR transmission of the Y arm to max out at 1 when well aligned. However, it is hovering around 0.05 right now, and the dominant source of instability is the angular motion of ETMY due to the Oplev loop being non-functional. I am hesitant to do in-chamber work without an extra pair of eyes/hands around, so I'll defer that for tomorrow morning when Chub gets in. With the cavity axis well defined, I plan to align the green beam to this axis, and use the two to confirm that we are well clear of the Parabola.

* Paola, our vertex laptop, and indeed, most of the laptops inside the VEA, are not ideal to work on this kind of alignmment procedure, it would be good to set up some workstations on which we can easily interact with multiple MEDM screens,

Attachment 1: Yarm_locked.png
Yarm_locked.png
  7723   Mon Nov 19 15:12:52 2012 JenneUpdateAlignmentYarm locked IR

Quote:

Quote:

POY11 does not go out of the vacuum

 It does but slighty low and does not get on mirrors. We need to change optic mounts to adjust the height. Red is flashing in yarm at 00 and 10 modes. TRY is ~0.4-0.5.

I've adjusted BS angle, camera and TRX PD at ETMX table so I can see red flashing at 03 mode while green is locked to 00 and its transmission is maximized. I thought that by adjusting BS angle, I will be able to align red to 00 not disturbing green, but this was not the case. Maximum TRX I could get was 0.1. I've adjusted POX to get into PD and I can see PDH signal though I can't lock as cavity is still misaligned for red.

 [Ayaka, Jenne]

We put the POY beam onto the POY PD.  The Yarm is currently locked on IR with ~0.65 transmission.

 

  9888   Thu May 1 03:15:03 2014 JenneUpdateLSCYarm locking with CM board

[Rana, EricQ, Jenne]

We locked the Yarm by using the CM board this evening. 

POY is going from its demod board to the CM board, and then the slow output of that is going to the POY channel of the whitening, and then on to the ADC.  So, with no AO path engaged, this is basically like regular Yarm locking. 

First of all, Den and Koji back in December were concerned that they were seeing some EOM saturation in the fast path, but we don't think that's an issue.  We looked at the FSS PCDRIVE while we increased the AO gain.  In fact, it looks like the offset is coming from the MC board's IN2 slider.  Even with no input on that slider, increasing its value puts an offset into the MC.  To fix this, I am going to put a 6.8uF cap in series with R30 in the MC board, which is part of the crossbar switch where the IN1 and IN2 get summed.  This should AC-couple the output of the IN2 slider before the summing node.

We aren't sure which sign to use for the AO path of the CM board...Eric is doing some modelling to see if he can figure it out.  He's going to try to see which spectra (below) his model matches.

For the spectra, we have a reference trace with no AO path, a trace with "Plus" polarity on the CM board which started to show a peak when the value of the MC IN2 slider was at about -6 dB, and a trace with "Minus" polarity, which started to show a peak when the value of the MC IN2 slider was at about -16 dB. 

Yarm_CMlocking_spectra_30Apr2014_copy.pdf

We took loop measurements for each of the Plus and Minus cases. Something that seems a little weird is how shallow of a slope we have in both cases near our UGF.

Yarm_CMlocking_TFs_30Apr2014_copy.pdf

 

  9889   Thu May 1 03:23:07 2014 ericqUpdateLSCYarm locking with CM board

Quote:

POY is going from its demod board to the CM board, and then the slow output of that is going to the POY channel of the whitening, and then on to the ADC.  So, with no AO path engaged, this is basically like regular Yarm locking.  

Just to be clear, the normal POY signals are not currently present, so the restore POY script will not result in the arm locking. POY11_I is turned off, POY11_Q is the output of the CM board, which can be used to lock the arm, as we did tonight. 

The POY digital demos angle went -56 -> 90, to get all of POY11_Q_IN1 to POY11_I_ERR

Miscellaneous things:

  • Right now, the cable from CM board ->MC board is a BNC. There appeared to be a differential 2-pin lemo hanging around for this purpose, but it didn't seem to be transmitting the signal. However, we will want something better than a BNC to keep this signal clean. 
  • I took SR785 TFs of the CM board from IN to the slow and fast outs. They looked reasonable, and will be posted in time. 
  • We enabled the 79:1.6k filter in the CM screen (though it is unclear if these are the actual values...), and put in its inverse in the digital path. I.e. we only want this shape in the AO path, to give it 1/f shape in the vicinity of the crossover. This is only necessary in the uncoupled cavity case. 
  9893   Thu May 1 16:41:35 2014 ericqUpdateLSCYarm locking with CM board

 (Edited this post; Forgot to account for the FMs other than 4 and 5... it now agrees better!)

I did some quick MATLAB simulation of the relevant loops to try and understand what was going on. I put the digital UGF around 200Hz, and then brought in the AO path with both signs. 

In these plots, blue is digital only, green is AO+digital with the crossover happening at the UGF, and red is the AO gain set to five times of what it was in the green curve. 

 AOsignsSame.pdfAOsignsOpposite.pdf

Based on the phase curves in the loop measurements, I would be inclined to say the pink -AO case corresponds to the opposite sign plot, and the +AO case to the same sign plot. 

This correspondence also holds for the appearance of the peaks in the noise curves, the Opposite sign case has a dip in loop gain at ~50Hz (pink curve, -AO), same sign around ~30Hz (brown curve, +AO). 

However, both of these look like they become unstable at some point in the transition! This agrees with our experience last night...

I'll fiddle around and try to come up with some compensating digital filter that will make the Opposite sign scenario work. 

The MATLAB code I used to make these plots is attached. 

Attachment 3: loopModeling.m
clear all

cycleT = 60e-6;

% AI, AA shapes from http://nodus.ligo.caltech.edu:8080/40m/8555
[z,p,k] = ellip(4,4,60,2*pi*7570,'s');
AI = zpk(z,p,k*10^(4/20)) * zpk([],-2*pi*13e3,2*pi*13e3);
AI.OutputDelay = 1*cycleT;

[z,p,k] = ellip(8,0.001,80,2*pi*7570,'s');
... 58 more lines ...
  9894   Thu May 1 17:00:05 2014 ranaUpdateLSCYarm locking with CM board

 I think that's about halfway there. Since this needs to be a precise comparison, we cannot use so many approximations.

We've got to include the digital AA and AI filters as well as the true, measured, time delay in the system. Also the measured/fitted TF of the CM board with the 79:1.6k filter engaged. We want an overall phase accuracy between Jenne's measured TF from last night and this model (i.e. on the same plot with the residual plotted).

Is there a cavity pole in the model? Should be at ~1.6 kHz.

  7073   Wed Aug 1 18:20:58 2012 JamieUpdateLSCYarm recovered

[Jenne, Jamie]

We recovered lock and alignment of the Y arm.  TRY_OUT is now at ~0.9, after tweaking {I,E}TMY pit/yaw and PZT2.  YARM_GAIN is 0.1.

I saved ITMY, ETMY, and PZT2 alignments in the IFO_ALIGN screen with the new alignment save/restore stuff I got working.

Working on getting Yarm ASS working now...

  14235   Sun Oct 7 16:51:03 2018 gautamConfigurationLSCYarm triggering changed

To facilitate Yuki's alignment of the EY green beam into the Yarm cavity, I have changed the LSC triggering and PowNorm settings to use only the reflected light from the cavity to do the locking of Arm Cavity length to PSL. Running the configure script should restore the usual TRY triggering settings. Also, the X arm optics were macroscopically misaligned in order to be able to lock in this configuration.

  3362   Wed Aug 4 20:15:07 2010 JenneUpdatePEMYay! Guralps work again!

After much hassle, the Guralp cable from the ADC Out of the breakout box to the ADC is fixed, and everything is plugged in and working again.  The seismometers are back in their regular positions at the ends of the MC, ready for some excellent seis/MC combo data. 

I solidified the change of putting the Gur2Z channel into a different BNC input on the ADC.  The C1ADCU_PEM.ini file has been changed so that what used to be the Ranger's channel is now recognized as Gur2Z. 

Also, I changed the same .ini file to reflect Koji's move of ACC_MC1_Z to the old AUDIO_MIC2 channel, so now all 6 Accelerometer channels have the same calibrations again.

Another big change is the change from old-left-handed convention to new-right-handed convention.  The seismometers are aligned the same way they always have been (with the North-South markers aligned with the MC), but now the North-South output is plugged into the BNC on the ADC that is associated with Gur*_X, and the East-West output is plugged into the ADC channel associated with Gur*_Y.  This is true for both Guralp Seismometers. 

So, now we have:

Gur1_X = Gur1_NS = ADC#10

Gur1_Y = Gur1_EW = ADC#11

Gur1_Z = Gur1_Vert = ADC#12

Gur2_X = Gur2_NS = ADC#2

Gur2_Y = Gur2_EW = ADC#3

Gur2_Z = Gur2_Vert = ADC#24

SEIS_Ranger_Y = no longer in the .ini file

  8291   Thu Mar 14 04:20:54 2013 JenneUpdateGreen LockingYbeat attempt

I dedicated my evening to trying to get the Ygreen beatnote (the idea being to then get the Xgreen beatnote).

First up was tweaking up the green alignment.  Per Yuta's suggestion, elog 8283, I increased the refl PD gain by 2 clicks (20dB) to keep the lock super stable while improving the alignment.  After I finished, I turned it back to its nominal value.  I discovered that I need lenses in front of the DC PD (for Ygreen, and I'm sure Xgreen will be the same).  The beam is just barely taking up the whole 2mm diode, so beam jitter translates directly to DC power change measured by the diode.  I ended up going just by the green transmission camera for the night, and achieved 225uW of Ygreen on the PSL table.  This was ~2,000 counts, but some of the beam is always falling off the diode, so my actual counts value should be higher after installing a lens. 

I then opened up the PSL green shutter, which is controlled by the button labeled "SPS" on the shutter screen - I will fix the label during some coffee break tomorrow.  Using my convenient new PSL green setup, removing the DC PD allows the beam to reflect all the way to the fuse box on the wall, so you can check beam overlap between the PSL green and the arm green at a range of distances.  I did this for Ygreen, and overlapped the Ygreen and PSL green. 

I checked the situation of the beat cabling, since Jamie has the beatbox out for whitening filter modifications tonight.  In order to get some signal into the control room, I connected the output of the BBPD amplifier (mounted on the front of the 1X2 rack) directly to the cable that goes to the control room.  (As part of my cleanup, I put all the cables back the way I found them, so that Jamie can hook everything back up like normal when he finishes the beatbox.) 

I then started watching the signal on the 8591E analyzer, but didn't magically see a peak (one can always hope....).

I decided that I should put the offset in the Y AUX laser slow servo back to the value that we had been using for a long time, ~29,000 counts.  This is where things started going south.  After letting that go for a minute or two, I thought to go check the actual temperature of the laser head.  The "T+" temperature on the controller read something like 42C, but the voltmeter which reads a voltage proportional to the temp (10C/V) was reading 5.6V.  I immediately turned off the offset, but it's going to take a while for it to cool down, so I'll come back in the morning.  I want the AUX laser to be something like 34C, so I just have to wait.  Ooops.

Still to do (for the short-term FPMI):

* Find Y beatnote.

* Align Xgreen to the arm - it's still off in pitch.

* Align Xgreen and PSL green to be overlapped, hitting the BBPD.

* Find the X beatnote.

* Reinstall the beatbox.

* Use ALS to stabilize both arms' lengths.

* Lock MICH with AS.

* Look at the noise spectrum of AS - is there more noise than we expect (Yuta and Koji saw extra noise last summer), and if so, where does it come from?  Yuta calculated (elog 6931) that the noise is much more than expected from just residual arm motion.

* Write a talk.

  15122   Wed Jan 15 08:55:14 2020 gautamUpdateCDSYearly DAQD fix

Summary:

Every new year (on Dec 31 or Jan 1), all of the realtime models will report a "0x4000" error. This happens due to an offset to the GPStime driver not being updated. Here is how this can be fixed (slightly modified version of what was done at LASTI).

Steps to fix the DC errors:

  1. ssh into FB machine. 
  2. Edit the file /opt/rtcds/rtscore/release/src/include/drv/spectracomGPS.c:
    • Look for the code block with a text string that reads something like
      /* 2019 had 365 days and no leap seconds */
                   pHardware->gpsOffset += 31536000;
    • Copy and paste the above string for the appropriate number of years of offset you are adding, and edit the comment string appropriately!.
  3. Navigate to /opt/rtcds/rtscore/release/src/drv/symmetricom. Run the following commands:
    sudo make
    sudo make install
  4. Stop all the daqd processes and reload symmetricom:
    sudo systemctl daqd_* stop
    sudo modprobe -r symmetricom
    sudo modprobe symmetricom
  5. Re-start the daqd processes:
    sudo service daqd_* start

Independent of this, there is a 1 second offset between the gpstimes reported by /proc/gps and gpstime. However, this doesn't seem to drift. We had effected a static offset to correct for this in the daqd config files, and it looks like these do not need to be updated on a yearly basis. All the daqd indicators are now green, see Attachment #1.

Attachment 1: DCerrors_fixed.png
DCerrors_fixed.png
  16546   Thu Jan 6 12:52:49 2022 AnchalUpdateCDSYearly DAQD fix 2022!

Just as predicted, all realtime models reported "0x4000" error. Read the parent post for more details. I fixed this by following the instructions. I add folowing lines to the file /opt/rtcds/rtscore/release/src/include/drv/spectracomGPS.c in fb1:

/* 2020 had 366 days and no leap second */
       pHardware->gpsOffset += 31622400;
/* 2021 had no leap seconds or leap days, so adjust for that */
       pHardware->gpsOffset += 31536000;

Then is made the package and reloaded it after stoping the daqd services. This brought back all the fast models except C1SUS2 models which are in red due to some other reason that I'll investigate further.

 

  16547   Thu Jan 6 13:54:28 2022 KojiUpdateCDSYearly DAQD fix 2022!

Just restarting all the c1sus2 models fixed the issue. (Attachment 1)

SUS2 ADC1 CH21 is saturated. I'm not yet sure if this is the electronics issue or the ADC issue.
SUS2 ADC1 CH10 also has large offset. This should also be investiagted.

Attachment 1: Screenshot_2022-01-06_13-57-40.png
Screenshot_2022-01-06_13-57-40.png
  10799   Mon Dec 15 22:30:50 2014 JenneUpdateElectronicsYend QPD modified

Details later - empty entry for a reply.

Short story - Yend is now same as Xend filters-wise and lack of gain sliders -wise.  Both ends have 13.7k resistors around the AD620 to give them gains of ~4.5.

Xend seems fine.

Yend seems not fine.  Even the dark noise spectrum sees giganto peaks.  See Diego's elog 10801 for details on this investigation.

  10801   Mon Dec 15 22:45:59 2014 JenneUpdateElectronicsYend QPD modified

 

 [Jenne, Rana, Diego]

We did some test on the modified QPD board for the Yend; we saw some weird oscillations at high frequencies, so we went and check more closely directly within the rack. The oscillations disappear when the cable from the QPD is disconnected, so it seems something is happening within the board itself; however, looking closely at the board with an oscilloscope in several locations, with the QPD cable connected or disconnected, there is nothing strange and definitely nothing changing if the cable is connected or not. In the plots there are the usual channels we monitor, and the 64kHz original channels before they are downsampled.

Overall it doesn't seem being a huge factor, as the RMS shows at high frequencies, maybe it could be some random noise coming up, but anyway this will be investigated further in the future.

Attachment 1: QPD_Ytrans_oscillating_15Dec2014.pdf
QPD_Ytrans_oscillating_15Dec2014.pdf
Attachment 2: QPD_IOPchannels_Ytrans_oscillating_15Dec2014.pdf
QPD_IOPchannels_Ytrans_oscillating_15Dec2014.pdf
  9845   Thu Apr 24 00:11:35 2014 JenneUpdateLSCYend shutter back.

Quote:

To see if perhaps the shutter was the problem, I turned off the power to the Yend green shutter, and unplugged the cable.  The cable is laying on the table, with the connector sitting on a piece of plastic to isolate it.  Removing the shutter from the system did not change anything.

 I re-plugged in the Yend shutter, and turned it on.

  8437   Wed Apr 10 15:49:22 2013 AnnalisaConfigurationCOMSOL TipsYend table eigenfrequency simulation with COMSOL

 I made a Simulation with COMSOL for the Yend table. Mainly, I tried to see how the lower eigenmode changes with the number and the size of the posts inside.

The lateral frame is just sitting on the table, it is fixed by its weight. I also put a couple of screws to fix it better, but the resulting eigenfrequency didn't change so much (less than 1 Hz). 

In Fig. 1 I didn't put any post. Of course, the lowest eigenfrequency is very low (around 80 Hz).

Then I added 2 posts, one per side (Fig. 2 and Fig. 3), with different diameter.

In some cases posts don't have a base, but they are fixed to the table only by a screw. It is just a condition to keep them fixed to the table

Eventually I put 4 posts, 2 per side. 

The lowest eigenfrequency is always increasing.

At the end I also put a simulation for 4 1.6 inch diameter posts without base, and the eigenfrequency is slightly higher. I want to check it again, because I would expect that the configuration shown in Fig.5a could be more stable.

P.S.: All the post are stainless steel.

 

Attachment 1: Pics_end_table.pdf
Pics_end_table.pdf Pics_end_table.pdf Pics_end_table.pdf
  8302   Fri Mar 15 16:46:52 2013 JenneBureaucracyAuxiliary lockingYend table upgrade - fast track?

In light of the Yend auxiliary laser's ill health, I think we should reconsider the possibility of changing out the Yend laser table next week.

My thinking here is that if whatever the new mode matching solution is for a replacement laser (Tara has borrowed our spare NPRO that used to sit on top of the fridge, or we could take Annalisa's) requires a rework of the table layout, we might as well put the new layout onto the new table.  So, we need to figure out what laser we will put in as the new Ygreen, and what it's waist looks like.  If it just requires a small movement of existing lenses or new lenses in similar positions to the current ones, we can keep living with our current table.  But, if the mode matching solution requires enough changes to distances / lens placement / whatever, we should think seriously about putting in the new table next week.

Here's what I would like to see happen on / before Monday:

Annalisa - Mode matching solution for new laser.  If we get the laser back from Tara, this will involve first measuring the waist, otherwise we already know the waist of the ABSL laser that Annalisa is currently using.

Annalisa and Steve - Find optics for new mode matching in the lab, or order them by Monday afternoon.

Manasa - List of every screw, washer, optic, mount, etc. that will go on the new Y end table, with a notation as to whether or not we have it in-hand, and if not, what needs to happen before we do.  Also, for things that we don't have, I'd like to see a summary of temporary solutions (e.g. keep using current mount for doubling crystal while new one is being machined).

Manasa / Annalisa / Koji - will the new mode matching solution fit within the existing layout, or do we need to redo the table layout?

  8304   Mon Mar 18 12:23:25 2013 JenneBureaucracyAuxiliary lockingYend table upgrade - go fetch NPRO from ATF

Zach has just replied, and said that we should feel free to take the laser from his iodine setup in the West Bridge subbasement, in the ATF lab. 

Annalisa, please ask Koji or Tara to show you where it is, and help you bring it to the 40m.  You should install it (temporarily) on the PSL table, measure the waist, and find the beat in IR.  Elog 3755 and elog 3759 have some of the details on how it has been done in the past.

  8305   Mon Mar 18 12:35:29 2013 AnnalisaBureaucracyAuxiliary lockingYend table upgrade - go fetch NPRO from ATF

Quote:

Zach has just replied, and said that we should feel free to take the laser from his iodine setup in the West Bridge subbasement, in the ATF lab. 

Annalisa, please ask Koji or Tara to show you where it is, and help you bring it to the 40m.  You should install it (temporarily) on the PSL table, measure the waist, and find the beat in IR.  Elog 3755 and elog 3759 have some of the details on how it has been done in the past.

 Ok, I'm going to contact Koji.

  8306   Mon Mar 18 13:10:19 2013 KojiBureaucracyAuxiliary lockingYend table upgrade - go fetch NPRO from ATF

1) Annalisa is going to start  working on mode profiling and beat note search for the old MOPA NPRO.

2) In the meantime, Manasa is working on the end table items. This will be reviewed by KA in the afternoon.

The laser at ATF is moved to the 40m when the status of 1) and 2) is determined by KA to be reasonable.

We also make the beat note measurement for the ATF laser too.
 

  8308   Mon Mar 18 20:13:18 2013 AnnalisaBureaucracyAuxiliary lockingYend table upgrade - go fetch NPRO from ATF

Quote:

1) Annalisa is going to start  working on mode profiling and beat note search for the old MOPA NPRO.

2) In the meantime, Manasa is working on the end table items. This will be reviewed by KA in the afternoon.

The laser at ATF is moved to the 40m when the status of 1) and 2) is determined by KA to be reasonable.

We also make the beat note measurement for the ATF laser too.
 

Today I installed mirrors to steer the pick-off from the main laser beam in a more free part of the PSL table and make the beat note measurement between it and the NPRO.

At the beginning I took the beam from the harmonic separator after the doubling crystal, and I was going to bring it in a less full part of the table . At the end I realized that there was already a beam steered up to a more free part of the table, and the beam is taken from the transmission of the PMC.

Tomorrow I'm going to use that beam to find the beat note with the NPRO.

I also removed almost all the steering  optics that I used on the ITMY table to send the auxiliary beam for ABSL through the window parallel to the POY beam. The most important thing is that I removed the BS, which was on the same path of the POY beam (see elog 8257).

 

ELOG V3.1.3-