40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 238 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  10749   Wed Dec 3 02:01:57 2014 KojiUpdateLSCIR Resonance Script Status

The other night (before the holidays), I tried ALS offset tuning  with IR POX/POY signals and it worked pretty good.
I didn't need to tune the offset after the scanning script stopped.

Once we are at the foot hill of the main resonance, I ran something like

ezcaservo -r C1:LSC-POX11_I_MON C1:LSC-ALSX_OFFSET -g -0.003 &
ezcaservo -r C1:LSC-POY11_I_MON C1:LSC-ALSY_OFFSET -g -0.003 &

(... I am writing this with my memory. I could be wrong but conceptually the commands looked like these)

  3225   Wed Jul 14 20:15:04 2010 DmassBureaucracyCamerasIR Olympus

I borrowed the Olympus and forgot to leave a note - I should have it for at most a day. dmassey@ligo if you need it urgently

  14811   Thu Jul 25 12:25:56 2019 gautamUpdateALSIR ALSX noise

Summary:

  1. There are some broad peaks in the ALS out-of-loop noise, centered at ~145 Hz, ~245 Hz and ~570 Hz which are absent in both the POX in-lock error signal and in the green PDH error signals (see Attachment #1). So I conclude they originate in the IR ALS beat chain somewhere. Needs more investigation, in the general quest to improve the ALS noise.
  2. This measurement also shows that the ALS noise is limited by unsuppressed EX green PDH frequency noise above ~400 Hz (100 Hz if you ignore the unexplained broad humps).

These spectra were taken with the arm cavity length locked to the PSL frequency using POX as an error signal, and the EX laser frequency locked to the XARM cavity length by the analog PDH servo at EX, so there is no feedback control with the ALS beat signal as an error signal.

Other details:

  • The transition of arm resonance control from POX to ALS error signal is more robust now - I am able to do this during daytime, and also maintain the lock for >20 minutes at a time.
  • Rana encouraged me not to spend too much time on this - so my next goal here will be to get the Y arm IR ALS working, and then we can control the two arms using ALS error signals in the CARM/DARM basis instead of the X/Y basis.
  • I still think it's worth getting the ALS good enough that the locking becomes repeatable and reliable.
    • The main task here is going to be re-doing the EY green layout to match the EX layout, get good MM into the cavity etc.
    • The IR light also has to be coupled into the fiber at EY.
Attachment 1: ALS_broadPeaks.pdf
ALS_broadPeaks.pdf
  13796   Fri Apr 27 01:36:02 2018 gautamConfigurationALSIR ALS noise performance

Summary:

My goal was to do some further characterization of the IR ALS system tonight. With POX as an OOL sensor, I measured an RMS displacement noise of  8 pm with the arm under ALS control. I calculated the CARM linewidth to be 77 Hz (=10.3 pm) for the 40m parameters, assuming 30ppm arm loss. Fuurthermore, this number is 3x better than the 24 pm RMS quoted in the Izumi et. al. paper. Of course I am quoting the best results from my efforts tonight. Conclusions:

  1. [Attachment #1] --- With XARM locked using POX, the ALS beat noise (i.e. Phase Tracker output noise) lines up well with the reference we have been using for some time now (and indeed, is better in some places).
  2. [Attachment #2] --- With the arm locked on ALS and POX as an OOL sensor, I measured performance comparable to this measurement we did sometime last year. Anomalies in this measurement and the one above were what precipitated the IMC noise investigation.
  3. [Attachment #3] --- The above two attachments are not the whole story. During the day, I get significantly worse performance (so much so that I couldn't even do the handoff to ALS control). But in 5 minutes of measurement, the ALS noise seems quite stationary.
  4. [Attachment #4] --- This is really the same as Attachment #2, but I wanted to overlay some vlines. Maybe this is a clue to some 60 Hz / ground loop issues, but the RMS has significant contribution from these harmonics. Tmrw, I will add the old measurement overlaid to this plot (and for what its worth, the Izumi et. al. spectrum as well).
  5. [Attachment #5] --- With the arm under ALS control, I was able to maintain the lock for a solid hour (and more as I write up this elog). Somehow inkscape screwed up the fonts, but main point here is that TRX is stable to within 10% throughout the observation time.

Since the stability and noise seemed quite good, I decided to collect some arm scan data to give to our modeSpec SURFs to practice fitting (which is the short dip in TRX in Attachment #4). Although after the discussion with Rana today, I think it may be that we want to do this measurement in reflection and not transmission, and look for a zero crossing in the PDH signal. In any case, I was able to scan 7 FSRs without any issues. I will upload the data to some git repo. GPS start time is 1208850775, sweep was 3mins long.

I think the next step here is to noise-budget this curve. At least the DFD noises

Attachment 1: 2018_04_BeatMouth_POX.pdf
2018_04_BeatMouth_POX.pdf
Attachment 2: 2018_04_BeatMouth.pdf
2018_04_BeatMouth.pdf
Attachment 3: ALSSpecgram.pdf
ALSSpecgram.pdf
Attachment 4: ALS_ASD.pdf
ALS_ASD.pdf
Attachment 5: ALSstab.pdf
ALSstab.pdf
  14521   Mon Apr 8 00:04:08 2019 gautamUpdateALSIR ALS noise budget

To start the noise budgeting, I decided to measure the "DFD noise", which is really the quadrature sum of the following terms:

  • ZHL-3A (RF amplifier) noise, NF ~ 6dB per spec (~ 1nV/rtHz)
  • Delay line demod board noise, ~30nV/rtHz [measurement]
  • AA board noise [measurement]
  • ADC noise

According to past characterizations of these noises, the ADC noise level, which is expected to be at the level of a few uV/rtHz, is expected to be the dominant noise source.

The measurement was made by disconnecting the NF 1611 free space photodiode from the input to the RF amplifier on the PSL table, and connecting a Marconi (f_carrier = 40 MHz, signal level=-5dBm) instead. The phase tracked output was then monitored, and the resulting digital spectrum is the red curve in Attachment #1. The blue curve is the ASD of fluctuations of the beatnote between the PSL and EX IR beams, as monitored by the DFD system, with the X arm cavity length locked to the PSL frequency via the LSC servo, and the EX green frequency locked to the X arm cavity length by the analog PDH servo. 

Conclusions:

Assuming the Marconi frquency noise is lower than the ones being budgeted:

  1. the measured frequency noise is above the DFD noise - this needs to be budgeted.
  2. The DFD noise level is consistent with a frequency discriminant of 15 uV/rtHz and an ADC noise level of 3 uV/rtHz at high frequencies.

Next noises to budget:

  1. In-loop X arm length noise
  2. In-lop EX laser frequency noise
Attachment 1: DFDnoise.pdf
DFDnoise.pdf
  14528   Tue Apr 9 19:07:12 2019 gautamUpdateALSIR ALS noise budget

Updated the noise budget to include the unsuppressed frequency noise from the EX laser. It does not explain the noise between 10-100 Hz, although the 1-3 Hz noise is close.

Actually, I think the curve that should go on the budget is when the X arm length is locked to the PSL frequency, whereas this is when the X arm is just locally damped. I will update it later tonight.

Update 1010pm: I've uploaded the relevant plot as Attachment #2. Predictably, the unsuppressed frequency noise of the EX laser is now higher, because the MC length is a noisier frequency reference than the arm cavity. But still it is a factor of 10 below the measured ALS noise.

Quote:

Next noises to budget:

  1. In-loop X arm length noise
  2. In-lop EX laser frequency noise
Attachment 1: ALS_noiseBudget.pdf
ALS_noiseBudget.pdf
Attachment 2: ALS_noiseBudget.pdf
ALS_noiseBudget.pdf
  14800   Mon Jul 22 23:53:16 2019 gautamUpdateALSIR ALS locking attempt

Summary:

My goal tonight was to lock the PSL frequency to be resonant in the XARM cavity, using the PSL+EX beat as the error signal. I was not successful - mainly, I was plagued by huge BR mode coupling in the error signal, and I could not enable the BR notch filter in the control loop without breaking the lock. Need to think about next steps.

Details:

  • POX and POY locking was easily restored.
  • EX green alignment was tweaked at the end-table. A large YAW correction was required, which I opted to apply on the mechanical mirror mounts rather than the PZTs. GTRX ~0.4 was recovered.
  • The arm cavity length was first locked using POX as an error signal 
    • Then I looked at the out-of-loop ALS noise, trusting the DFD's V/Hz calibration (red-trace in Attachment #1).
    • I judged it to be close enough to the benchmark reference (green-trace in Attachment #1), and so decided that I could go ahead and try locking.
  • A modified version of the script /opt/rtcds/caltech/c1/scripts/XARM/Lock_ALS_XARM.py was used to transition control from POX to the ALS error signal
    • I found that I had to change the sign of the CARM loop gain for the servo to remain stable (in this config, CARM-->MC2 length, thereby modifying the IMC frequency to keep the PSL resonant in the XARM cavity).
    • I don't know why this sign change was required - we are still sticking to the same convention that the beat frequency increases when the temperature slider for the EX laser is incremented in counts.
    • The script failed multiple times at the BOOST/BR notch filter enabling step.
    • Doing these steps manually, I found that turning the BR notch, FM6, ON destroyed the lock immediately.
    • Motivated by this observation, I looked at the in-loop error signal spectrum, see Attachment #2. Here, the PSL frequency is servoed by the ALS error signal, but the BR notch filter isn't enabled.
    • The Bounce-mode peak is huge - where is this coming from? It is absent in the ALS spectrum when the XARM is locked with POX. So it is somehow connected with actuating on the MC2 suspension? Or is it that the FM6=BounceRoll filter of the XARM loop is squishing the noise when looking at the ALS spectrum in POX lock, i.e. Attachment #1? In which case, why can't I engage FM6 for the CARM loop???

Anyway, now that I have a workable set of settings that gets me close to the ALS lock of the XARM, I expect debugging to proceed faster.


Update 2019 July 23: I looked at the control loop shape today, see Attachment #3. I'm not sure I understand why the "BounceRoll" filter  in this filter bank looks like a resonant gain rather than a notch, as it does for the Oplev or SUSPOS loops for example - don't we want to not actuate at these frequencies because the reason the signal exists is because of the imperfect OSEM/magnet positioning? This does not explain the spectrum shown in Attachment #2 however, as that filter was disabled.

Attachment 1: ALS_X_outOfLoopnoise.pdf
ALS_X_outOfLoopnoise.pdf
Attachment 2: ALS_X_inLoopnoise.pdf
ALS_X_inLoopnoise.pdf
Attachment 3: CARM_loopShape.pdf
CARM_loopShape.pdf
  13807   Wed May 2 21:39:33 2018 gautamConfigurationALSIR ALS for EY

The new K6XS mounts I ordered have arrived. I want to install one of them at the Y-end. I can't find a picture of the current layout but it exists as there is a hardcopy affixed to the ETMY chamber door, Steve, can we dig this up and put it in the wiki? In any case, the current beam going into the fiber is the pickoff from the post-SHG harmonic separator. I'd like to change the layout a bit, and use a pickoff before the doubling oven, but looking at the optical table, this seems like a pretty involved task and would probably require large scale optical hardware rearrangement. In any case, the MM of the green beam into the Y-arm is <50%, so I would like to redo that as well. Does anyone know of a measurement of the mode from the Lightwave NPRO that is installed at EY? I think Annalisa is the one who installed this stuff, but I can't find an actual NPRO mode measurement in her elog thread.


Found it: elog4874, elog8436. I updated the laser inventory page to link the lasers in use to the most recent mode measurements I could find on the elog. I guess ideally we should also link the AM/PM response measurements.

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

SV  ETMY optical table layout  

     as of 3-31-2016

The oplev path was optimized with AR coated lenses and new He/Ne laser Jan 24, 2017

  4699   Thu May 12 05:25:26 2011 kiwamuUpdateIOOIP_POS disconnected

A cable for IP_POS has been disconnected at the LSC rack, 1Y2. Due to it currently no IP_POS signal shows up on the digital side.

It looks like we disconnected the cable together with some unused cables when we were cleaning up the wiring of the LSC rack.

The cable, a shielded flat-cable, is supposed to send DC power to the QPD and send the signals from the QPD to an interface board on the LSC rack.

I will check how it used to be and reconnect it.

  4700   Thu May 12 08:54:11 2011 steveUpdateIOOIP_POS cable found

Quote:

A cable for IP_POS has been disconnected at the LSC rack, 1Y2. Due to it currently no IP_POS signal shows up on the digital side.

It looks like we disconnected the cable together with some unused cables when we were cleaning up the wiring of the LSC rack.

The cable, a shielded flat-cable, is supposed to send DC power to the QPD and send the signals from the QPD to an interface board on the LSC rack.

I will check how it used to be and reconnect it.

 I found the disconnected cable, but I do not see the interface board at the LSC rack

  4280   Sun Feb 13 16:50:17 2011 kiwamuUpdateASCIP_ANG was at wrong ADC

I found that the ADC channels for IP_ANG had been assigned to a wrong machine.

IP_ANG is supposed to be acquired at c1auxey (east end), but actually it had been at c1auxex (south end).

This is the reason why we couldn't see any signals from IP_ANG.

So I fixed it by editing the db files (i.e. ETMXaux.db and ETMYaux.db). Now it seems working fine.

 

This mistake obviously came from the X-Y name swapping business. Something else might be still wrong.

xmen.jpg

 

  14467   Wed Feb 20 18:26:05 2019 gautamUpdateIOOIPPOS recommissioned

I've suspected that the TTs are drifting significantly over the course of the last couple of days, because despite repeated alignment efforts, the AS beam spot has drifted off the center of the camera view. I tried looking at IPPOS, but found that there was no data. Looking at the table, the QPD was turned backwards, and the DAQ cable wasn't connected (neither at the PD end, nor at 1Y2, where instead, a cable labelled "Spare QPD" was plugged in). Fortunately, the beam was making it out of the vacuum. So as to have a quantitative diagnostic, I reconnected the QPD, turned it the right way round, and adjusted the steering onto it such that with the AS spot on the center of the CCD monitor, the beam is also centered on the QPD. The calibration is uncertain, but at least we will be able to see how much the spot drifts on the QPD over some days. Also, we only have 16 Hz readback of this stuff.

I leave it to Chub to take the high-res photo and update the wiki, which was last done in 2012.


Already, in the last ~1 hour, there has been considerable drift - see Attachment #2. The spot, which started at the center of the CCD monitor, has now nearly drifted off the top end. The ITMX and BS Oplev spots have been pretty constant over the same timescale, so it has to be the TTs?

Attachment 1: IMG_7330.JPG
IMG_7330.JPG
Attachment 2: Screenshot_from_2019-02-20_19-43-27.png
Screenshot_from_2019-02-20_19-43-27.png
  5605   Mon Oct 3 17:57:12 2011 kiwamuUpdateASCIPPOS fixed

The input matrix of IPPOS were fixed so that the horizaontal motion correctly shows up in X and the vertial is Y.

 

(what I did)

 + The data base file, QPD.db, were edited.

  QPD.db is a part of the c1isxaux slow machine and it determines the input matrix for deriving the X/Y signals from each quadrant element.

 + The previous input matrix was :

      X = (SEG1 + SEG4) - (SEG2 + SEG3)

      Y = (SEG1 + SEG2) - (SEG3 + SEG4)

 + The new matrix which I set is :

     X = (SEG1 + SEG2) - (SEG3 + SEG4)

     Y = (SEG1 + SEG4) - (SEG2 + SEG3)

    The new matrix is a just swap of the previous X and Y.

 + Then c1isxaux was rebooted by :

     telnet  c1iscaux

     reboot          

 + The I did the burt restore it to this morning.

Quote from #5574

The channels for IPPOS had been assigned in a wrong way.

 

  7840   Mon Dec 17 18:39:02 2012 JenneUpdateIOOIPPOS centered, no IPANG beam

I centered IPPOS.  I do not find any IPANG beam on the ETMY table, even waving the IR card in the black beam tube.

I took photos of the PZT2 HV supplies with the new camera, but I can't figure out how to get the pictures off the camera.  I guess the camera is smarter than I am.

  12950   Tue Apr 25 19:35:41 2017 gautamUpdateGeneralIPCS -q

Dataviewer wouldn't launch on pianosa - it seemed to work fine on Donatella though. Rana suggested using the ipcs -q command. The complete fix can be found in this elog. This did the trick, dataviewer runs fine on Pianosa now...

  7177   Tue Aug 14 13:21:34 2012 JenneUpdateCDSIPC senders no nothing about rates of IPC receivers, we need to filter signals appropriately

Quote:

Quote:

When signals are transmitted between the models running at different rates, no AI or AA filters are automatically applied. We need to fix our models.

This is known, but we just haven't fully groked it yet.  We need to look closely at every place we have IPCs between models running at different rates.  The sender has no information about receivers, so it can't reasonably do anything to pre-filter the signal on it's own.

So for transmission from:

  • faster -> slower models: add anti-aliasing on the sender side
  • slower -> faster models: add anti-imaging on the receiver side

 *sigh* This is one of those things that I meant to take care of months ago, but haven't yet.  I agree that it needs doing.  It's been on my whiteboard to-do list for a long time now.  Bad Jenne for not taking care of it.

  7175   Tue Aug 14 11:46:22 2012 JamieUpdateCDSIPC senders know nothing about rates of IPC receivers, we need to filter signals appropriately

Quote:

When signals are transmitted between the models running at different rates, no AI or AA filters are automatically applied. We need to fix our models.

ai.png

This is known, but we just haven't fully groked it yet.  We need to look closely at every place we have IPCs between models running at different rates.  The sender has no information about receivers, so it can't reasonably do anything to pre-filter the signal on it's own.

So for transmission from:

  • faster -> slower models: add anti-aliasing on the sender side
  • slower -> faster models: add anti-imaging on the receiver side
  11890   Thu Dec 17 14:02:05 2015 gautamUpdateCDSIPC channels for beat frequency control set up

I've set up two IPC channels that take the output from the digital frequency counters and send them to the end front-ends (via the RFM model). A summary of the steps I followed:

  1. Set up two Dolphin channels in C1ALS to send the output of the frequency counter blocks to C1RFM (I initially used RFM blocks for these, but eric suggested using Dolphin IPC for the ALS->RFM branch, as they're faster.. Eric's removed the redundant channel names)
  2. Set up two RFM channels in C1RFM to send the out put of the frequency counter blocks to C1SCX/Y (along with CDS monitor points to monitor the error rate and a filter module between the ALS->RFM and RFM->SCX/Y IPC blocks - I just followed what seemed to be the convention in the RFM model).
  3. Set up the receiving channels in C1SCX and C1SCY
  4. Re-compiled and re-started the models in the order C1ALS, C1RFM, C1SCX and C1SCY.

I've set things up such that we can select either the "PZT IN" or the frequency counter as the input to the slow servo, via means of a EPICS variable called "FC_SWITCH" (so C1:ALS-X_FC_SWITCH or C1:ALS-Y_FC_SWITCH). If this is 0, we use the default "PZT IN" signal, while setting it to 1 will change the input to the slow servo to be the frequency readout from the digital frequency counter. I've not updated the MEDM screens to reflect the two new paths yet, but will do so soon. It also remains to install appropriate filters for the servo path that takes the frequency readout as the input.

Tangentially related to this work: I've modified the FC library block so that it outputs frequency in MHz as opposed to Hz, just for convenience..

  7349   Thu Sep 6 13:07:02 2012 JenneUpdateIOOIPANG no longer a reference :(

I was having trouble centering IPANG using the PZTs, and I suspected something funny was going on at the end.  I went down there, and the beam was focused right on the PD, and the spot was very very small.  I think this means that when I was trying to center the beam, I was falling into the gap between the pieces of the diode.  Also, as Koji pointed out to me the other day, if the PD is at the focal point of the beam, any parallel rays hitting the lens just before the PD will all go to the same place, no matter how the input beam has moved.  This means we're not getting as much info out as we'd like.

So.  I moved the lens a little bit farther from the PD such that we are just beyond the focal point of the beam.  The beam size is now ~1mm on the QPD.

This means, however, that I moved the beam on the QPD such that IPANG is no longer a reference of the input pointing. Ooops. I think this adjustment needed to be done though.  Right now, the PZTs are set to where we had them yesterday, when we moved them slightly to center the IPANG QPD, and I've recentered IPANG.

  7439   Tue Sep 25 22:40:55 2012 JenneUpdateIOOIPANG ND filter installed

[Jenne, Evan Hall]

Both IPPOS and IPANG beams are (after turning on the input and output PZTs) hitting their QPDs.  However IPANG was saturating.  We went down to take a look, and we had ~2.8mW incident on the QPD.  There was an ND filter sitting unmounted, next to the diode, and an empty fork directly in front of the diode.  Since IPPOS also has an ND filter in front, we stuck this ND filter back in.  Now we are no longer saturating.

We're not hitting (yet) the center of these 2 PDs, but we're at least hitting the diodes, so it shouldn't be too hard to steer the input PZTs.

Whomever took away this ND filter without elogging it was BAD!!!  (Jamie, when we first found IPANG coming out of the vacuum during this vent, we moved some of the mirrors on the out-of-vac table in the IPANG path.  Was the ND filter removed at that time?  Or has it been out for much longer, and we never noticed because IPANG wasn't coming nicely out of the vacuum / was clipping on the oplev lens?)

  7442   Wed Sep 26 16:59:30 2012 jamieUpdateIOOIPANG ND filter installed

Quote:

[Whomever took away this ND filter without elogging it was BAD!!!  (Jamie, when we first found IPANG coming out of the vacuum during this vent, we moved some of the mirrors on the out-of-vac table in the IPANG path.  Was the ND filter removed at that time?  Or has it been out for much longer, and we never noticed because IPANG wasn't coming nicely out of the vacuum / was clipping on the oplev lens?)

I do not remember removing anything from that setup.  We just moved some mirrors and lenses around

  8216   Mon Mar 4 09:51:26 2013 SteveUpdateASSIP-ANG is still not real

 IP-ANG  is coming out of ETMY without clipping. The beam is very high on the pick off mirror at the end table but it is still missing the qpd .

 

Attachment 1: IP-ANG.png
IP-ANG.png
  6288   Thu Feb 16 09:59:16 2012 steveUpdateASCIP- ANG

Initial pointing or IP-ANG is a pointing monitor of the MC. This beam is launched after the second  pzt  steering mirror.

IP-ANG  is missing the pick up mirror by a few inches at ETMYchamber

1000 days plot show last appearance in Feb 2010

Attachment 1: lastIPang.png
lastIPang.png
  2102   Fri Oct 16 10:15:02 2009 steveUpdateIOOIP ang & pos recentered

Pointing stability of 4 days. Initial pointing does not go through suspended optics. It is launched  right after the Piezo Jena steering mirrors in the BS chamber.

IP-ANG on epics screen is  C1:ASC-IBQPD_X and Y in dataviewer  were recentered. This beam is clipping a bit in ETMX chamber  pick off mirror.

IP-POS pick  off is in the BS chamber and it's qpd on the BS_ISCT This beam is also clipping just a little bit. This is easy to fix. We'll have to remove an iris from the BS optical levers table.

note: arms were not locked when I recentered

Attachment 1: ip4d.jpg
ip4d.jpg
  2132   Thu Oct 22 08:45:58 2009 steveUpdateIOOIP ang & pos recentered

Quote:

Pointing stability of 4 days. Initial pointing does not go through suspended optics. It is launched  right after the Piezo Jena steering mirrors in the BS chamber.

IP-ANG on epics screen is  C1:ASC-IBQPD_X and Y in dataviewer  were recentered. This beam is clipping a bit in ETMX chamber  pick off mirror.

IP-POS pick  off is in the BS chamber and it's qpd on the BS_ISCT This beam is also clipping just a little bit. This is easy to fix. We'll have to remove an iris from the BS optical levers table.

note: arms were not locked when I recentered

 IP-ANG clipping can be traced back to our last vent of Aug. 18, 2008  See elog entry #845

This was an after earth quake - sus repair vent

Attachment 1: pointing1000.jpg
pointing1000.jpg
  9529   Tue Jan 7 21:00:02 2014 JenneUpdateIOOIP POS, IP ANG aligned

After locking the arms (after the MC alignment work), Manasa and I aligned IP POS, IP ANG, and both end transmission QPDs. 

We noticed that IP ANG is clipping in yaw as it comes onto the end table.  It looks to me like it's clipping on the edge of the plastic box's aperture, but I can't guarantee that it's not also clipping elsewhere. 

  2110   Sun Oct 18 19:55:45 2009 ranaConfigurationElectronicsIP POS is back: ND filter gone, new resistors in

Its back in and re-centered. Our next move on IPPOS should be to replace its steering mirror with something bigger and more rigid.

Electronics changes:

20K -> 3.65 K  (R6, R20, R42, R31) (unused)

20K -> 3.65 K  (R7, R21, R32, R43, R11, R24, R35, R46)

If you look in the schematic (D990272), you see that its an AD797 transimpedance stage with a couple of LT1125 stages set to give some switchable gain. It looks like some of these

switches are on and some are not, but I am not sure where it would be controlled from. I've attached a snapshot of one quadrant of the schematic below.

The schematic shows the switches in the so-called 'normally closed' configuration. This is what the switches do with zero volts applied to the control inputs. As the schematic also shows,

just disconnecting the 'switch' inputs cause the switch's control inputs to go high (normally open configuration, i.e. pins 2-3 connected, pin4 open). For the record, the default positions of the IPPOS switches are:

switch1   high

switch2   low

switch3   low

switch4   high

 


** EDIT (Nov 2, 2009): I forgot to attach the before and after images; here they are:

IMG_0068.JPGIMG_0072.JPG

  2112   Sun Oct 18 22:06:15 2009 ranaConfigurationElectronicsIP POS is back: ND filter gone, new resistors in

I tried to compare the IP_POS time series with the IPANG and MC_TRANS but was foiled at first:

1) The IPANG scan rate was set to 0.5 second, so it doesn't resolve the pendulum motions well. Fixed in the .db file.

2) Someone had used a Windows/DOS editor to edit the .db file and it was filled with "^M" characters. I have removed them all using this command:   tr -d "\r" <ETMXaux.db > new.db

3) The MC_TRANS P/Y channels were on the MC Lock screen but had never been added to the DAQ. Remember, if there's a useful readback on an EPICS screen. its not necessarily in the frames unless you add it to the C0EDCU file. I have done that now and restarted the fb daqd. Channels now exist.

4) Changed the PREC of the IPPOS channels to 3 from 2.

5) changed the sign for the IBQPD (aka IPANG) so that bigger signal is positive on the EPICS screen.

Attachment 1: Untitled.png
Untitled.png
  5459   Mon Sep 19 14:57:36 2011 kiwamuSummaryIOOIP POS is back

IPPOS is back. A cable had been disconnected at the 1Y2 rack. So I put it back to place.

The cartoon below shows the current wiring diagram. I think this configuration is exactly the same as it it used to be.

wiring.png

Quote from #5455

  + Fixing IPPOS (volunteers) 

  7069   Wed Aug 1 15:02:29 2012 JenneUpdateIOOIP POS QPD centered

Jamie went out to look at IP POS, and the beam was *way* off.  Even though our alignment is still rough, we're kind of close right now, so Jamie put the beam back on the QPD, but we need to recenter IPPOS after we get good alignment.

  600   Mon Jun 30 08:59:23 2008 steveUpdateIOOIOO-MC_DEMOD_LO is low
The alarm handler is beeping relentlessly: asking for help in high partical count and low demod signal
Attachment 1: demlo.jpg_____
demlo.jpg_____
  9678   Wed Feb 26 10:08:14 2014 SteveUpdateIOOIOO trend

 

 The MC is happy (but only for this tiny snapshot in time and most probably will go dysfunctional again as it has been for several months, as of this writing)

Attachment 1: IOOtrend3&24h.png
IOOtrend3&24h.png
  11079   Thu Feb 26 16:46:37 2015 manasaUpdateGeneralIOO rack power supply

I shutdown the +/-15V and the +/-24V sorensons on the IOO rack to connect the FOL RF PDs to the rack power supply.

They were turned back ON after the work. PMC and MC were relocked.

Quote:

[Steve, Manasa]

We ran power cables and sma cables for the FOL fiber module from the PSL table to the IOO rack.

 

  939   Wed Sep 10 13:28:25 2008 YoichiSummaryElectronicsIOO rack lost -24V (recovered)
Alberto, Yoichi

This morning, the MC suddenly started to be unwilling to lock.
I found a large offset in the MC servo board.
It turned out that -24V was not supplied to the Eurocard crate of the IOO rack.
We found two loose cables (violet, that means -24V) around the cross connects with fuses.
We connected them back, and the -24V was back.
The MC locks fine now, and Alberto can continue his arm length experiment.
  10954   Thu Jan 29 09:50:47 2015 manasaUpdateElectronicsIOO rack amplifier panel

The RF amplifier panel on the IOO rack (Attachment 1) will be used to also hold the RF amplfiers for the frequency counters. The amplifiers mounted on it right now are getting +15 (orange wire) and GND (black wire) from the rack power supply (Attachment 2).

Proposed plan to install RF amplifiers:

1. Disconnect the D sub connector that powers the amplifiers and pull out the panel. The rack power supplies will NOT be shut down for this. 

2. Mount the RF amplifiers with bypass capacitors. There will be 4 amplifiers ZFL-500LN mounted on the same panel (2 for each frequency counter).

3. While putting back the panel on the IOO rack, we will need to shut down the +15V and -15V sources to connect the amplifiers to the rack power supply.

I will do this over this weekend so that we dont lose any locking time. If anybody has any concerns, let me know

Attachment 1: panel_front.jpg
panel_front.jpg
Attachment 2: panel_back.jpg
panel_back.jpg
  9350   Tue Nov 5 19:50:07 2013 manasaUpdateElectronicsIOO rack +/-5V power supplies

The power supply to the ADC box on the IOO rack (that reads the beat I & Q signals) was pulled out because it did not run through any fuse and was connected directly to the power supply. 

There were already connections running from the +/-5 V power supply. They were powering the mode cleaner demod board rack. In order to remove the ADC power connectors from the power supply, I notified Jenne in the control room because turning off the power supply would affect the MC. I switched off the +/-5V power supplies at the same time. The ADC power connectors were removed. The +/-5V power supplies were then turned ON again at the same time. Jenne relocked the MC after this.

I have still not connected the ADC to the fuse rack power supply because this requires the +/-5V power supplies to be turned OFF again in order to pull out new connections from the fuse rack and I need to make a new ADC power connector with thicker wires.

  9356   Wed Nov 6 15:59:41 2013 manasaUpdateElectronicsIOO rack +/-5V power supplies

Quote:

The power supply to the ADC box on the IOO rack (that reads the beat I & Q signals) was pulled out because it did not run through any fuse and was connected directly to the power supply. 

There were already connections running from the +/-5 V power supply. They were powering the mode cleaner demod board rack. In order to remove the ADC power connectors from the power supply, I notified Jenne in the control room because turning off the power supply would affect the MC. I switched off the +/-5V power supplies at the same time. The ADC power connectors were removed. The +/-5V power supplies were then turned ON again at the same time. Jenne relocked the MC after this.

I have still not connected the ADC to the fuse rack power supply because this requires the +/-5V power supplies to be turned OFF again in order to pull out new connections from the fuse rack and I need to make a new ADC power connector with thicker wires.

I switched OFF the +/-5V power supplies on the IOO rack to hook up the ADC power connectors through 250mA fuses to +/-5V. Since these power supplies were powering the MC demod boards, MC remained unlocked during the process. I turned the power supplies back ON and MC relocked itself after this.

  9704   Fri Mar 7 16:56:17 2014 steveUpdateIOOIOO qpds centered

Quote:

Quote:

The IMC has not been behaving well since this morning and totally not happy when Q was finishing his measurements. The WFS servo had large offsets in pitch. Looking back at the trend and using ezcaservo to restore the suspensions did not help.

I realigned the IMC and brought TRANS SUM to ~18000 and MCREFL to < 0.5. The spot positions are not very good; nearly 2 mm off in pitch on MC1 and MC3. But after the alignment of MC, the WFS servo offsets were below +/-20.

The MC has been locked stably with WFS servo ON for the last few hours.

P.S. I did not touch the WFS pointing or reset the WFS offsets.

MC remained locked with WFS enabled all through last night and this morning. Koji dropped by and looked at the MC. The MC WFS servo, though stable, was at the edge of becoming unstable. This was because I did not touch the WFS pointing on the QPDs yesterday after realigning. So I recentered the WFS, reset the WFS filterbank offsets and reenabled the servo.

I measured the spot positions on MC mirrors for reference.

Spot positions in mm (MC1,2,3 pit MC1,2,3 yaw): [1.405767579680834, 0.79369009503571208, 1.3220430681427462, -1.2937873599406551, -1.1704264340968924, -1.2518046122798692]

 

Attachment 1: IOOqpdCentered.png
IOOqpdCentered.png
  9705   Mon Mar 10 09:28:48 2014 steveUpdateIOOIOO pointing 2 days

 Morning seconds without adjustment.

 

Attachment 1: IOOpointing2d.png
IOOpointing2d.png
Attachment 2: morningseconds.png
morningseconds.png
  5912   Wed Nov 16 14:34:18 2011 steveUpdatePSLIOO beam moves in pitch

C1:IOO-QPD_ANG_VERT beam movement  in 1 degree C temp change in 3 hrs

 

Attachment 1: iooqpds.png
iooqpds.png
  5898   Tue Nov 15 16:25:38 2011 steveUpdatePSLIOO angle qpd centered

This moring I centered the IOO Angle QPD. The IOO Pos QPD was not centered. The existing layout does not allow the beam centering of the Pos qpd without misaligning the MC

input. We have to add an aditional steering mirror. I will do that tomorrow morning.

  5907   Wed Nov 16 10:11:20 2011 steveUpdatePSLIOO angle & pos qpd centered

Quote:

This moring I centered the IOO Angle QPD. The IOO Pos QPD was not centered. The existing layout does not allow the beam centering of the Pos qpd without misaligning the MC

input. We have to add an aditional steering mirror. I will do that tomorrow morning.

 I added the steering mirror for Pos  and centered both qpds

Attachment 1: iooqpds.png
iooqpds.png
  10526   Tue Sep 23 09:37:12 2014 SteveUpdateSUSIOO and temp changes
Attachment 1: IOO.png
IOO.png
  9577   Mon Jan 27 12:26:00 2014 KojiUpdateIOOIOO Slow Actuator Servo threshold changed

In order to activate the slow actuator servo for the MC locking,
the threshold level for this servo (C1:PSL-FSS_LOCKEDLEVEL) was changed from 10000 to 700.

Now the servo started to move the PZT fast out to be controlled to 5V.

  1443   Mon Mar 30 12:46:36 2009 YoichiConfigurationIOOIOO QPDs were missing the beam
When I re-locked the MC, I wanted to check the trend of the IOO QPDs to see if the input beam pointing has changed.
Then I found that the QPDs were not receiving light.
The attached trend plots show that the QPDs missed the beam on March 23rd.
The IOO-QPD_ANG was installed on Mar 11th by Kiwamu and Kakeru. Since then, they were serving as a reference of the PSL beam pointing.
But there is no record of the past week. This is very bad because then I cannot tell if I should relieve the MC WFS to make the mirrors follow the input beam or not.
I found that someone has moved the beam splitter which picks up the beam going to those QPDs. But there is no elog entry on this around March 23rd.
I re-centered the beam on the QPDs.

Since the X-arm locked to TEM00 with the MC WFS on (i.e. the MC beam axis is following the input beam axis), I guessed that the input beam has not drifted that much. So I relieved the WFS and centered the WFS QPDs.
Attachment 1: IOO-QPDs.pdf
IOO-QPDs.pdf
  11360   Mon Jun 15 20:36:48 2015 ranaUpdateIOOIOO QPDs centred

after re-aligning the beam into the PMC, I touched up the steering mirros into the IOO QPDs so that the beams are now centered again. Please don't adjust these references without prior authorization and training.

This plot shows the 10-minute trends for these QPDs over the last 400 days.

Attachment 1: Untitled.png
Untitled.png
  11296   Sun May 17 23:46:25 2015 ranaUpdateASCIOO / Arm trends

Looking at the summary page trends from today, you can see that the MC transmission is pretty flat after I zeroed the MCWFS offsets. In addition, the transmission from both arms is also flat, indicating that our previous observation of long term drift in the Y arm transmission probably had more to do with bad Y-arm initial alignment than unbalanced ETMY coil-magnets.

Much like checking the N2 pressure, amount of coffee beans, frames backups, etc. we should put MC WFS offset adjustment into our periodic checklist. Would be good to have a reminder system that pings us to check these items and wait for confirmation that we have done so.

  6676   Thu May 24 15:10:43 2012 SureshSummaryGeneralIOO (MC) health check webpage layout

   Here is the suggested layout of the MC health check web page layout. I will update the Omnigraffle file as people comment and suggest changes.  If you want the file let me know.

 

MC_Health_Check.pdf

  3797   Wed Oct 27 15:38:19 2010 josephb, yutaUpdateCDSIO chassis with bad timing was taken back to Downs

Problem:

The front end timing was not working properly for 2 of the IO chassis.  They were not being synced to the 1 PPS signal. 

This prevented the use of RFM for communication between front ends because time stamps on the transmitted data did not match the cycle on the receiving machine.

Action:

We took one of the incorrectly working chassis over to Downs.  Rolf said he would take a look at it tomorrow morning.

Joe will be going over tomorrow morning to talk with Rolf and see what needs to be done to fix it.

 

  12875   Thu Mar 9 15:25:12 2017 KojiUpdateGeneralIMC/XYarms aligned/locked

As per Steve's request, I've checked the alignment of the IMC and the arms. These three cavities are locked and aligned.

ELOG V3.1.3-