40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 216 of 355  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  9237   Mon Oct 14 17:40:15 2013 JenneUpdateLSCNew lockin / sensing matrix screens

 Hmmmm, yup.  I forgot to pay attention to what the UGFs of our LSC loops are when I was picking a low-noise region.  Since they're (currently, at least) around 100Hz, I want to find a frequency in the few hundred Hz region.  Masayuki has the IFO right now for ALS diagnostics, so I'll pick new frequencies later.   If we decide to omit the bandpass filters, it's even easier to change frequencies on the fly (although we'll always still have to make the servo notch filters match).

  9238   Mon Oct 14 17:51:40 2013 JenneUpdateIOOinput beam to PMC drifted again

Quote:

I wonder what's drifting between the laser and the PMC? And why is it getting worse lately?

 The PMC refl is bad in pitch today, and the transmission is only 0.76, rather than our usual 0.83ish.

I did a quick, rough tweak-up of the alignment, and now we're at 0.825 in transmission.

  9239   Mon Oct 14 21:12:35 2013 JenneUpdateLSCNew lockin / sensing matrix screens

After staring and thinking, I remembered that there is a limit to the number of characters that a channel name can have.  So, I removed the "_LOCKIN" part of the names, and recompiled, and everything seems to work.  I modified the screens that I had made, and they show all the appropriate things now.  

The symptoms were that the numbers in the filter banks (for example, INMON) were white with the usual black background.  The numbers are supposed to be green with a black background.  After I recompiled, all the numbers were green.

This also means I need to re-put in the low pass filters. 

  9240   Tue Oct 15 01:39:07 2013 MasayukiUpdateGreen LockingY-arm ALS

 

 - Motivation

We found that we need to look into the entire end PDH loop to figure out what causes the worse noise level of the Y-arm than before.(entry)
Today, I measured in-loop noise of the end PDH loop and the ALS loop with different end PDH servo gain of Y-arm to make sure the PDH servo gain change the noise level of the ALS control loop.

- What I did

Measuring the OLTF of the end PDH loop:
1. Measured the OLTF of the PDH loop with the end PDH servo gain 6 and 7.

The UGF and  phase margine: 16 kHz and 53 degree(gain 7) 

                                             7.8 kHz and 86 degree(gain 6)

I couldn't measure the OLTF with higher servo gain than 7 because the loop was not stable enough. I guess that is because of the noise of the SR560, which I used for node of the excitation signal.

Calibration of the end PDH error signal
2. Locked the cavity using IR and turn on the notch filter at 580 Hz of the C1:LSC-XARM. Excited the ETMY using awg with sinusoidal signal at 580 Hz. Set the end PDH servo gain to 6 and measured error signal of the end PDH. The calibration factor of the end PDH error signal H is calculated by

H = abs(G + 1) / A * Verr / Vin

where G is the OLTF of the end PDH, A is the actuator response of the ETMY, Vin is the amplitude of the excitation signal and Verr is the error signal at 580 Hz. This H convert the  error signal to the fluctuation of the cavity length, so it has the unit of V/m. We can change that unit to V/Hz by multiplying f/L, where f is the laser frequency of IR and L is the length of the arm. In this case the H convert the error signal to the fluctuation of the resonant frequency of the cavity.
 The actual number was

H = 1.4e7 [V/m]  (2.0e-6 [V/Hz])

In-loop noise of the end PDH loop
3. Measured the error signal of the PDH loop with the end PDH servo gain of 6.0, 7.0, 8.0 and 9.0. I calibrated these signals with above H, so  these unit is Hz/rHz. I attached the result of these in-loop noise. When the end PDH servo gain is 9.0, the end PDH loop looks unstable. And 8.0 looks to be the optimal gain in terms of the in-loop noise of end PDH loop.

ALS in-loop noise:
4. Stabilized the Y-arm with ALS control loop with different end PDH servo gain, and measured in-loop noise of the ALS control loop. I attached these results and discussed about this results below.

- Discussion

 Now we can say that too high PDH servo gain makes ALS loop very noisy. Compare to when the PDH servo gain is 7 or 8, the ALS in-loop noise is roughly 4 times higher when the PDH servo gain is 9.0, which means the PDH loop is not stable. However between 100 Hz and the end PDH in-loop noise has no big difference between when the servo gain is 6 and 9. If this high frequency noise comes from the end PDH control and this effect is linear, these noises should be same level. Also the PDH servo gain of 7.0 looks optimal gain in terms of the in-loop noise of ALS control loop, although the 8.0 has smallest end PDH in-loop noise. Actually PDH in-loop noise are smaller than ALS in-loop noise.

 I'm wondering what causes the 60 Hz peak in black curve. When the gain become higher, the peak at 60 Hz looks to become larger. The UGF of the ALS loop is above 100Hz, so  it's not because of that. I feel there is some hint for understanding this result in this peak.

From this observation, I could make sure that the end PDH servo gain change the ALS in-loop noise, but that effect doesn't look so simple.

 

By the way
 We should take care about 60 Hz comb peaks.  You can see huge peaks in PDH in-loop noise and also in ALS in-loop noise.

Attachment 1: PDHinloop.pdf
PDHinloop.pdf
Attachment 2: ALSinloop.pdf
ALSinloop.pdf
  9241   Tue Oct 15 15:25:13 2013 SteveUpdateSUSOplev power spectrums bandwidths

  Atm1 bandwidth 0.01 Hz ETMY plot is different from

Atm2 bandwidth 0.1 Hz  normal ???????    They should be the same !!!!

Attachment 1: BW0.01oplevPS.png
BW0.01oplevPS.png
Attachment 2: oplevPSetmXYclosed.png
oplevPSetmXYclosed.png
  9242   Wed Oct 16 02:08:05 2013 MasayukiUpdateGreen LockingScript for scan cavity.

I wrote the script to scan the cavity using ALS until it finds IR resonance . This script is  (script)/ALS/ALSfindIRresonance.py I attached the time series of the C1:ALS-OFFSETTER and IR transmission of XARM when the script was working.

When you start this script, it start rough scan. It steps the offset of the C1:ALS-OFFSETER with ramp time, and for each step it checks the value of C1:LSC-TR. At rough scan, one step is 0.1 count. When IR transmission become larger than threshold, this script start fine scan. In fine scan, this script steps the offset by 0.01 for the range of 2. For each step, C1:LSC_TR value is measured, and after fine scan it set the offset to the value which had the maximal C1:LSC-TR.

I put new button 'Scan %ARM'  to the ALS screen. You can run this script by pushing that button.

 

Attachment 1: scan-cavity.png
scan-cavity.png
Attachment 2: Scan_ARMs.png
Scan_ARMs.png
  9243   Wed Oct 16 02:27:56 2013 JenneUpdateLSCPRMI + 2 arm attempt
[Masayuki, Jenne]
 
Masayuki informed me that the Xarm ALS was feeling pretty good today, so we quickly (<20 minutes, including 2 open loop transfer functions) locked the PRMI+Xarm
We then tried PRMI + 2 arms, but while trying to bring the arms into IR resonance, the PRMI lost lock.
 
What we did (procedure-wise):
 
I locked and aligned both arms in IR.  I misaligned the ETMs, locked MICH to tweak BS pointing.  I locked PRMI with REFL 165 I&Q, and used the ASS to tweak up the PRM pointing.  I then moved PRM -0.5 units in pitch (after turning off the LSC). 
Masayuki then restored ETMX, locked the Xarm ALS, used his nice new script to find the IR resonance, then we stepped ~5 offset counts away from the resonance.  This is just barely off the IR resonance, since we don't want to cross any sideband cavity resonances.  I then brought the PRM back, and turned on the LSC.  PRMI immediately acquired lock.  Then Masayuki, with a 30 second ramp time, moved us back the ~5 counts until we had Xarm IR resonance! 
After that,
we took 2 open loop transfer functions, one of PRCL and one of MICH.

It was smooth like butter.  Seriously, we decided to give it a try around 12:50am, and by 1:08am we had saved both OLTF .xml files.  During this lock, Xarm ALS beatnote was -14.5 dBm, at 68.9 MHz.
 
After that success, we decided to be bold, and see if we could do PRMI + 2 arms.  I turned off the PRMI's LSC, and misaligned the PRM by -0.5 slider units.  We restored ETMY, and Masayuki got both arms locked with ALS, found the resonances, and then stepped ~5 offset counts away from each resonance.  I restored the PRM, and enabled the LSC.  Once again, the PRMI acquired lock immediately.  However, when I tried to turn on the ASS, I lost lock of the PRMI (but not the arms' ALS).  PRMI did seem noticeably noisier this time than either without any arms, or even with just Xarm.  The POP spot on the camera was wiggling about the same amount that it normally does when the ETMs are misaligned, PRMI is locked, and the ASS is on.  However, the ASS was off, and we were still seeing this angular motion.  Anyhow, I relocked the PRMI, and left the ASS off.  Then, we tried bringing the arms back into resonance for IR.  We should probably automate this process, or do it with a CARM-type loop, so that both come in at the same time.  As it was, Masayuki typed the offset for resonance into one arm (with a 30 second ramp time), then quickly typed in the number for the other arm (again with a 30 second ramp time).  So, the arms weren't exactly in common.  We lost PRMI lock during the scan toward resonance. 
Here is some time series data.  While it's tricky to see much in this plot, here's the command to get it:  ./getdata -s 1065947469 -d 40 -c C1:LSC-POP22_I_ERR_DQ C1:LSC-TRX_OUT_DQ C1:LSC-TRY_OUT_DQ C1:ALS-OFFSETTER1_OUT_DQ C1:ALS-OFFSETTER2_OUT_DQ C1:LSC-MICH_IN1_DQ C1:LSC-PRCL_IN1_DQ   Also, the text files for these traces are in my directory: /users/jenne/PRCL/PRMI_Xarm_ALS_16Oct2013/  During this trial (at least before the lockloss), Xarm was still on the same lock stretch with ALS as before, so -14.5 dBm at 68.9 MHz, and the Yarm was -21.7 dBm at 82.9 MHz.
 
To-do:
To take a step back, we should try bringing in only one arm to IR resonance, then the other, to see if we can isolate what the cause of the lockloss was. 
I need to finish setting up the new sensing matrix measurement stuff, so we can take sensing matrix data throughout this process.
 
 

Plots:

PRCL Open Loop Transfer Function.  PRMI locked on REFL 165 I&Q, Xarm held on IR resonance using ALS, ETMY misaligned:

PRCL_OLTF_PRMIir_XARMgreen_16Oct2013.pdf

MICH Open Loop Transfer Function.  PRMI locked on REFL 165 I&Q, Xarm held on IR resonance using ALS, ETMY misaligned:

MICH_OLTF_PRMIir_XARMgreen_16Oct2013.pdf

 Time series data during our PRMI + 2 arm attempt:

TimeSeries_PRMI_2arms_16Oct2013.png

  9244   Wed Oct 16 02:39:24 2013 ranaUpdateLSCPRMI + 2 arm attempt

 

 that's some hot stuff

its time to get the CM servo hardware turned back on. We're going to want to switch it on when we're about ~1/50th of the way up the CARM fringe.

A good way to re-commission it is to lock it to the single arm, using a Pomona box filter to move the arm pole down to the coupled cavity pole frequency.

 

  9245   Wed Oct 16 03:04:37 2013 JenneUpdateLSCNew lockin / sensing matrix model parts

Quote:

Still to do:

* Put a little more stuff into the front end so that we get total mag and phase of the sensing matrix element, not just uncalibrated lockin outputs.

 I worked today some more on the new Sensing Matrix situation.  I have added stuff to the CAL model, so that the sensing matrix elements come out calibrated to W/m, with phase in degrees.  The idea is that we can see time series of the calibrated lockin outputs, so that we have minimal post-processing to do, since these are things that will be interesting to look at live.

 

The first step is to go from I and Q to magnitude and phase.  Each "sensor" (ex. REFL55Q) is demodulated with a lockin part, which outputs sub I and Q channels (so, something like REFL55Q_I and REFL55Q_Q).  We are only interested in the _I component of the lockin.  But, REFL55I also has a _I and _Q.  Again, we only take the _I part.  Now, we have REFL55I_I and REFL55Q_I.  We call these the I and Q components of the sensors (this is exactly what we normally call them, but it can get confusing since the lockins also have _I and _Q before we discard the _Q part).  Now, we want to take these I and Q components, and transform them to a magnitude and phase. After we do that, we want to calibrate the magnitude to "Watts per meter" from "counts sensed per counts driven".  I also converted the phase to degrees, since that's the unit we usually use when talking about the sensing matrices. 

To go from the I and Q components to Mag and Phase, I wrote a little block of c-code, which is in /opt/rtcds/caltech/c1/userapps/release/isc/c1/src/MagPhaseFromIQ.c . Since we can't use the arctan function, I approximated it using equation 17 from Full Quadrant Approximations for the Arctangent Function [Tips and Tricks] from IEEE.  (I used x -> y/x in equation 17, so that I had a 2D situation).  I also have an "if / else if" cascade to determine what quadrant I'm in.  Since the formula in the paper is from [0,pi/2), I just needed to add pi, subtract the answer from pi, or negate the answer to get to the other quadrants.  Also, note that they are using a "normalized" arctan function, so equation 17 is really from [0,1), and you have to remember to multiply by pi/2 on your own.

To get from drive counts to drive meters, I put in an EPICS variable for the optic's actuation constant (ex, PRM's constant can be found in elog 8255).  Right now, we have to transfer the oscillation frequency from the oscillator part's _FREQ variable to a new EPICS variable, but Zach and Joe just today made a new oscillator part that makes it easier to access the frequency and amplitude of the drive within the front end.  See LLO aLog 9139 for details on this new part.  I had trouble compiling with their new part, but once I get that figured out, I won't need to do this transfer of information.  Anyhow, the drive calibration is (optic actuation constant)/[(drive frequency)^2]. 

Then the total calibration of the magnitude is Mag in cts/m = 2 * mag / [(drive amplitude) * (drive calibration)] .  The factor of 2 comes from the fact that the lockin output is a factor of 2 smaller than the true sensing matrix element.  The lower case "mag" in the formula is the output of the c-code. 

After this, there is yet another EPICS variable, to hold the calibration for the photodiode, to get from counts sensed to Watts of power at the actual port.  By "actual port", I mean the true IFO port, taking into account any optical elements between the port and the photodiode, like beam splitters and dumps, or loss from the imperfect reverse isolation of the input Faraday.

The code all compiles and runs fine, although I haven't done any explicit testing yet.

Still to-do for Sensing Matrix:

* Find all of the numbers for all of the EPICS variables.  In particular, I need to get the ratio of the power hitting each photodiode to the power at that port. 

* Write a script to do a burt-restore with all the correct settings, and turn on the dither lines.

* Put the lowpass filters back in the demodulators, now that they have new (shorter) names.

* Try it, and compare with the optickle model, and previous measurements.

* Copy Anamaria's script to look at the error statistics for my measurements.

 

  9246   Wed Oct 16 10:32:40 2013 SteveUpdateSUSFlowbench effect on oplev error signals

 ETMX _OPLEV_...ERROR signals are effected by turning ON the  flow bench motor  at the south end 

 The broadband noise [~ 5-60 Hz] is much higher when the motor is running.

The flow bench was turned off.

 

 

Attachment 1: FlowBenchOnOff.png
FlowBenchOnOff.png
  9247   Wed Oct 16 17:34:28 2013 JenneUpdateLSCPRMI + 2 arm attempt

Koji reminded me that we should also save the data from the PRMI+Xarm, just in case we want to look at it later.

Here is the time series, in which you can see us finding the Xarm IR resonance, moving the arm off resonance, locking PRMI, and bringing the arm back into resonance.  At the very end, the arm is still held on resonance, but I had disabled the LSC locking, so we see very large flashes at TRX (of order 40, rather than 1).

TimeSeries_PRMI_Xarm_16Oct2013.png

The data is in the same folder as the 2arm data: /users/jenne/PRCL/PRMI_Xarm_ALS_16Oct2013/

The text files have been differentiated, so that the 2arm data has "_2arms" at the end of the filename, while the Xarm data had "_Xarm" appended to the filename. Since we left the cavities locked for many minutes (during which transfer functions were taken), the data set for the PRMI+Xarm is very long.

  9248   Wed Oct 16 19:19:14 2013 MasayukiUpdateGreen LockingEnd PDH 60 Hz comb noise in YARM

[Manasa, Masayuki]

- Motivation

For PRMI + 2arm, we tried to make the ALS control noise better. As this entry we had huge 60 Hz comb noise in PDH loop of YARM.

So we tried to figure out the problem and fix it.

- What we did

We checked which power supply the staff in Y-end are connected to, and change some of them to connect to 1Y4 AC power supply from wall AC. What we changed was
1.Main end laser
2.He-Ne laser
3.Green REFL PD

We checked error signal of PDH control and compared before and after. The 60 Hz peak get better from -80 dBVpk to -90 dBVpk. Also I attached the plot of XARM, privious YARM (the data of Yesterday night), and current YARM ALS in-loop noises. The RMS of ALS in-loop noise of Y-arm get better by factor of 2. However, even the 60 Hz comb noise get better than before, RMS get worse by comb noise. 

We would like to make these noise better at least until these noises don't affect to RMS, so we should continue to check.

Attachment 1: comb_noise.pdf
comb_noise.pdf
  9249   Thu Oct 17 13:26:13 2013 JenneUpdateASCPOP QPD realigned

I locked the PRMI, and tried to turn on the ASS, but this caused PRMI to lose lock. 

Since this is similar to what happened the other night (see elog 9243, 2nd big paragraph), I looked into it a little further.  I noticed that the POP QPD pitch was very close to the edge of the QPD, so I went out and (while PRMI was locked) recentered the POP QPD.  After doing so, I was able to run the PRM ASS, and it worked very nicely, just as it has before.  So, it looks like something drifted, such that the optimal PRM alignment caused the POP beam to not be fully on the QPD.  Since the ASC loop is triggered by PRMI lock, and is constantly on, falling off the QPD causes lockloss.

While I was out there, I tweaked up the PMC pitch alignment yet again.  The FSS numbers all looked reasonable, however PMC transmission was ~0.75 .  I did a tiny bit of work in pitch, and now we're back to 0.83 transmission. 

  9250   Thu Oct 17 13:40:55 2013 JenneUpdateLSCNew lockin / sensing matrix frequencies

I locked PRMI, and (after fixing the POP QPD situation, noted in elog 9249) took power spectra of all the REFL RFPDs.  It looks like the area above 500 Hz is pretty clean and flat for all the signals, so I'm going to use 560Hz, 562Hz, 564Hz, 566Hz and 568Hz for my 5 sensing matrix frequencies.

Also, I'm not sure what is going on with REFL11, but there's a weird dip between 630 Hz and 660 Hz in both I and Q.  I recentered this guy not too long ago (elog 9218), but it clearly needs some more looking-at.

All_REFL_PRMI_17Oct2013.pdf

  9251   Thu Oct 17 18:29:28 2013 KojiUpdateLSCPRMI+2arm attempt (not really yet)

While Manasa, Jenne, and Masayuki are working on the preparing the interferometer, I write the elog for them.

- 6PM-ish: X and Y arms were was locked. They were aligned with ASS.

- PRMI was locked. The PRM was aligned with ASS.

- Jenne went into the lab and aligned the PRM ASC QPD.

- Jenne also aligned all of the oplev spots except for the SRM.

- 6:40PM Then, Manasa and Masayuki checked the out-of-loop stability of the arms.
The X and Y arms have the rms of 2.2kHz and 600Hz, respectively.
The X arm is significantly worse than the Y arm.

Masayuki saved the plot somewhere in his directory.

- 7:20PM X beat: 41.2MHz, Y beat: 14.8MHz

- 7:22PM PRMI locked POP110 115-120 

- 7:30PM Lost lock of everything. Start over. Taking the arm alignment.

- 7:45PM start the 2nd trial. PRMI+one arm ready.

- 8:00PM explosion! Lost lock.

- 8:30PM The Xarm ALS is not stable anymore. It loses the control in ~10sec.
We are investigating the out-of-loop stability of the Yarm ALS.
(i.e. Look at the beat note error signal while locking the Yarm with the IR PDH)

  9252   Thu Oct 17 22:38:25 2013 MasayukiUpdatePSLPSL temperature changed

[Manasa, Masayuki]

PSL temperature changed

The beat note of Xarm looked somehow strange before (elog). It should be the highest when the green transmission power is highest, in other words when the end green PDH locks with a TEM00 mode. But it was not like that. When the end PDH locked with other modes (GTRX: below 0.3), the beat note was higher than TEM00 mode (GTRX: around 0.5). 

We guessed that end green laser was somewhere around the point where there were 2 stable TEM00 modes . In order to move away from this unstable region of the end laser, we changed PSL temperature to obtain beat note at a different green laser frequency where we do not have any of the weird modes oscillating.

We changed the PSL temperature from 31.63 degree to 31.33 degree. We measured the in-loop noise of ALS loop and I attached it. There is not big difference in Yarm, but the Xarm in-loop noise become better in high frequency region. We think before the xend green laser was in a not-so-good state and the laser had more frequency noise then. 

ALS stability

After change PSL temperature, Xarm ALS is so stable. Actually Xarm is being locked right now and it is locked for more than 50 minutes!!
Although the Xarm ALS is so stable, Yarm ALS is not stable right now. It lost lock by ~5min. We don't know what is the reason, so we will try to fix it tomorrow.

Attachment 1: in-loop.pdf
in-loop.pdf
  9253   Fri Oct 18 08:12:08 2013 SteveUpdatePEM1000 days trends
Attachment 1: trend1000days.png
trend1000days.png
  9254   Fri Oct 18 15:18:49 2013 SteveUpdatePEM particle count peak or ...

Sunday evening fireworks. Manasa heard it.

Attachment 1: PEMcount?.png
PEMcount?.png
Attachment 2: PemCountPeak?No.png
PemCountPeak?No.png
  9255   Mon Oct 21 09:46:12 2013 SteveUpdatePSLLaser just turned on

I have just turned on the PSL Innolight laser. The laser shut down  with unknown reason a day ago.

Attachment 1: laserTurnedON.png
laserTurnedON.png
  9256   Mon Oct 21 13:15:52 2013 KojiUpdateIOOPMC aligned

PMC aligned. Trans 0.78 -> 0.83

  9257   Tue Oct 22 10:12:33 2013 SteveUpdatePEM south arm AC intake duct checked

  The 4th week of no wet mopping of the floor  and no wet wiping  the vacuum envelope.

 

We cleaned the intakes of the south arm IFO air condition. The bottom duct have quite a bit accumulation Atm1

See wet wiped contrast on Atm2

We found 3 holes around pipes ( coming from CES ) on the east wall that has to be sealed.

After closer examination of these holes, they are sealed off well.

Attachment 1: PEM0.5micron60d.png
PEM0.5micron60d.png
Attachment 2: southArmIntakeNorth.jpg
southArmIntakeNorth.jpg
Attachment 3: SouthArmMidIntakeWipe.jpg
SouthArmMidIntakeWipe.jpg
  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.

 

  9259   Tue Oct 22 18:55:55 2013 ranaUpdateCDSWorkstation swap: Rosalba to ???

We got a new computer from Xi computer corp. I am currently installing Ubuntu 10.04 LTS on to it to start with and then will move on to 12 if we can figure out a way to test it besides "I guess it should work?"

Rosalba has been removed and put onto the old Jamie desk. Old Jamie desk also has a Mac Mini running on there.

At the meeting tomorrow we need to decide on a new Italian baby girl name for this new machine.

  9260   Wed Oct 23 00:05:17 2013 manasaUpdateSUSUnstable Y arm ALS points to problems with ETMY suspension

[Masayuki, Manasa]

Looking into control signals and error signals of the Y arm green PDH servo,

1. The saturation of feedback signal (PZT_OUT) at +/-4000 counts (less than 5V) comes from only the readout saturating. The signals looked fine on the oscilloscope.
2. We did a sine sweep at the PZT_OUT and optimized the LO frequency. The LO frequency did not need any change.
3. The error signal has some offset to it. We are not sure where this comes from.

We have been seeing that whenever green loses lock, the spot position moves down in pitch on the ETMYF camera and the GTRY camera. This led us to think about if the lock loss originated from the PDH or from the cavity.

We looked into dataviewer channels of green, IR, oplev and suspension for the following cases:
1. Green and IR PDH locked
2. Green locked and arms flashing for IR
3. Green shutter closed and IR PDH locked
4. Green shutter closed and arms flashing for IR
5. Arms flashing for IR and ETMY oplev servo turned off.

Dataviewer snapshots of glitch in all the above cases are saved in masayuki's folder users/masayuki/ALS/kicked_mirror/

In all the above cases, we could still see the glitch. We could conclude that the problem lied with the ETMY SUS.
Shown below is the dataviewer snapshot of ETMY sus and shadow sensor channels. The glitch exists even when the oplev servo is turned off pointing to problems associated with the ETMY suspension.

Y-SUS_All.png

  9261   Wed Oct 23 00:13:30 2013 MasayukiUpdateGreen LockingFPMI with ALS arm stabilization

Summary
In 2arms + MICH configuration, residual motion of the cavity will couple with MICH signal. When cavity length change, the reflectivity of cavity also change. And that cause the phase shift in reflected light. That phase shift is detected in MICH signal. When we try to lock the DRMI + arm, that coupling will be problem for lock acquisition. For practice to estimate that coupling, I estimated the coupling between the cavity motion and the AS55Q signal.

What I did

- Measurement steps
  I did the same measurement as that of this entry. For the estimation below steps are needed. The detail of each step will be written below.
  --Measurement and calibration of the AS55Q error signal with MICH + 2arms locked by ALS control
  --Measurement of the ALS in-loop noise and estimation of residual motion of the cavities.
  --Calibration of the coupling from residual arm motion to AS55Q signal

- Calibration of  the AS55Q signal
1. Sensor gain estimation
  We used the same method as the previous entry,
  We excited the BS at 580 Hz with a given amplitude (Vin). We enabled the notch filter at 580 Hz in the LSC MICH servo. We measured  the peak height (Verr) of the AS55Q error signal. We used the actuator response (A_bs) of BS measured in this entry.
  We can get the sensor gain (H) of AS55Q in unit of count/m

          Verr    1
   H = ------- -------
          Vin   A_bs

By this calculation H = 4.2e+07.

2. Fitting of OLTF for the MICH loop
  We measured the OLTF of the MICH loop. Modelled OLTF is fitted into the measurement data. That modelled OLTF includes the actuator response of BS, the MICH servo filters, DAI,DAA,AI,AA filters, the TF of sample and hold circuit. (About DAI, DAA filters and S/H circuit please read this entry. About AI,AA filters please read this entry)  Also I put time-delay into that OLTF. I estimated that time-delay and the gain of OLTF by fitting.  The time delay was 311usec.

OLTF.png

3. Estimation of the MICH free running noise
 With modeled OLTF, I estimated the MICH free running noise.

Estimation of the coupling from residual cavity motion to AS55Q signal
 The ALS in-loop noise data has the unit of Hz/rHz (disturbance of the cavity resonant frequency). By multiplying L_arm/f_laser we can convert the unit to m/rHz (disturbance of the cavity length) .
 I used the same coupling constant between residual motion of cavity and MICH noise as this entry. For estimation of the coupling constant, we excited ETMs  and measured the TF from excitation signal to AS55Q error signal.  I assumed the cavity pole as 4000 Hz. The result is discussed below

Discussion

  ALS in-loop noise include the sensor noise. in high frequency region the in-loop noise is dominated by the sensor noise. So in this region in-loop noise does not mean actual residual motion of the cavity.  And this sensor noise pushes the mirror. So we have to estimate the actual motion of the cavity by multiplying the servo transfer function of the control in this region.

 I made 2 plots. Both include the MICH free running noise and estimated coupling noise from both arms. In one plot, for estimation of the coupling I multiplied only coupling constant to calibrated in-loop noise of the ALS loop. In another plot,  I multiplied coupling constant and OLTF of ALS loop in order to estimate the actual motion of the cavity.  If the 3 curves are coincide in first plot, that means the ALS in-loop noise is same as the residual cavity motion in that region and the MICH free running noise is dominated by coupling from residual cavity motion. If those curves are coincide in second plot, that means the ALS in-loop noise is sensor noise in that region.

 Above 40 Hz, the 3 curves are totally in coincident in first plot. On the other hand in second plot the 3 curves look similar in this region. That may mean above 40 Hz the ALS noise are dominated by sensor noise and MICH free running noise is dominated by the coupling from residual cavity motion.  Also in the region between 10 Hz and 40 Hz, the MICH free running noise seems to be dominated by coupling from cavity motion.

Figure 1

 ALSnoise1.png

Figure 2

ALSnoise2.png

In second plot, the coupling from cavity motion is overestimated. It's possibly because of overestimation of coupling constant, but I'm not sure.
Koji mentioned that we should measure the residual motion of the cavity by using POX and POY. Now the ALS is much more stable than before, so I think we can easily do the measurement again with out of loop measurement. That will be more strait forward measurement.

  9262   Wed Oct 23 09:17:33 2013 SteveUpdateSUSETMY sensors compared to ETMX

 ETMY sensors are glitching or getting kicked up.

Atm3, There is no seismic activity here.

 

Attachment 1: ETMYglitching.png
ETMYglitching.png
Attachment 2: OSEMsensorsETMY&X.png
OSEMsensorsETMY&X.png
Attachment 3: ETMYgettingKickedUp.png
ETMYgettingKickedUp.png
Attachment 4: drive-damp.png
drive-damp.png
  9263   Wed Oct 23 11:42:28 2013 ranaUpdateSUSETMY sensors compared to ETMX

  This is not really definitive. The 0.1-0.3 Hz band is not the right one to look for seismic transients - it should be the higher frequency ones.

The other test to do is to turn off the ETMY damping and then look for glitching in the sensors. And then, of course, check to see that no one has bumped the satellite box with a cart or a mop...

  9264   Wed Oct 23 15:46:01 2013 JenneUpdatePSLPMC was unlocked

The PMC was unlocked for a little over an hour.  I relocked it, and the MC locked itself.  Today, it looks like PMC yaw alignment is bad, and maybe pitch isn't so good either.  Transmission is 0.77

  9265   Wed Oct 23 15:48:06 2013 ranaUpdateSUSETMY sensors compared to ETMX

I noticed by eye that during one event when ETMY was getting kicked up, its CPU meter (C1:FEC-47_CPU_METER) went RED.

Thinking that this might be a clue I tried to trend this channel. Even though this channel is in the SCY EDCU file and the 'rtcds install' command claims to be 'installing C1EDCU_SCY', many of the channels named in the file are not actually showing up in ur dataviewer SLOW channels list.

I smell a cockroach in our RCG build process, but I can't find the log file for the make-install part of the build nor can I find the Makefile from which the make-install is born. Help us Jamie!

remote-control-cockroach.jpg

I have deleted a few filters from c1scy to see if that could reduce the CPU time and I have killed the c1tst process to see if that can cool down the entire computer. Next, we can try to open the rack doors and put a fan on there to see if we can shave a couple microseconds. I have a StripTool running on pianosa to see if we see some correlations between FEC47 and the ETMY SUS watchdog RMSs. Don't close it.

  9266   Wed Oct 23 17:30:17 2013 jamieUpdateSUSETMY sensors compared to ETMX

c1scy has been running slow (compared to c1scx, which does basically the exact same thing *) for many moons now.  We've looked at it but never been able to identify a reason why it should run slower.  I suspect there may be some bios setting that's problematic.

The RCG build process is totally convoluted, and really bad at reporting errors.  In fact, you need to be careful because the errors it does print are frequently totally misleading.  You have to look at the error logs for the full story.  The rtcds utility is ultimately just executing the "standard" build instructions.  The build directory is:

    /opt/rtcds/caltech/c1/rtbuild

The build/error logs are:

    <model>.log     <model>_error.log 
I'll add a command to rtcds to view the last logs.

(*) the phrase "basically the exact same thing" is LIGO code for "empirically not at all the same"
  9267   Wed Oct 23 18:24:56 2013 ranaUpdateSUSETMY sensors compared to ETMX

 

 While that would be good - it doesn't address the EDCU problem at hand. After some verbal emailing, Jamie and I find that the master file in target/fb/ actually doesn't point to any of the EDCU files created by any of the FE machines. It is only using the C0EDCU.ini as well as the *_SLOW.ini files that were last edited in 2011 !!!

So....we have not been adding SLOW channels via the RCG build process for a couple years. Tomorrow morning, Jamie will edit the master file and fix this unless I get to it tonight. There a bunch of old .ini files in the daq/ dir that can be deleted too.

  9268   Wed Oct 23 18:28:01 2013 JenneUpdateSUSETMY sensors compared to ETMX

We have now watched the ETMY computer situation for a little over 150 minutes, and have seen one 'event' where the CPU time of the scy model hit 62 microseconds, and a glitch in the ETMY OSEM sensors happened at the same time.  We also see no such glitches at any other time, which makes sense with our latest hypothesis, since this event was the only time that the CPU time reported being greater than 61 microseconds.  (1/16384 Hz = 61.1696 microseconds). 

I have now restarted the c1tst model, to see if that increases the rate of glitches (assuming that running another model heats up the whole computer a bit more, and that makes things run a little bit slower).

Screenshot-Untitled_Window.png


Wed Oct 23 21:05:28 2013 

RXA: It looks like there was a real effect. Its between -2.5 and 0 on the plot below.

 

Screenshot-Untitled_Window-1.pngI've stopped the process of c1tst again to make it get better. At 9:20, I also went and opened the front rack door (the back one was already open). One reason its hot may be that the exhaust vents on the top of c1iscey are blocked by one of the custom multi-pin adaptor boxes. In the morning, we should drop the computer down by 1 or 2 notches in the rack so that it can air cool itself better. Make sure to poweroff the computer from the terminal before moving it though.

I checked the cabling somewhat. The fat grey cable which comes out of the old Sander Liu AA chassis was connected to the blue adaptor box but the strain relief screws were not being used. I tightened them (we need to buy a set of small screwdrivers for the toolboxes at each end). While doing this, the Cat6 cable in the back labeled 'c1iscey' popped out and the screen went white. This cable has a broken latch on it so it doesn't stay put - needs to be replaced too during the computer move.

  9269   Wed Oct 23 19:14:10 2013 JenneUpdatePEMSeismometer status

As you may recall, Den designed some nice seismometer stations for us with the help of Steve. The granite base was installed : elog 8461. The point of these is to have nice solid bases for our seismometers to sit on, rather than the flimsy linoleum flooring.  Also, they are covered (and will be insulated) to help prevent air currents and temperature fluctuations from affecting our seismometer measurements.  Even though these seismometer stations have been in place for a few months, we are not yet taking advantage of them.  This is a status elog, so that we know what needs to be done.

Recently, Den finished up the design for, and Steve ordered, and we received, the small aluminum plates that go on the side of the granite slabs, so that we can feed the connectors for the seismometer through the baseplate, in an airtight way. 

The current plan is to use one Guralp at each end station, and the Trillium at the vertex.  As of this moment, we have 1 Guralp at ETMY, 1 Guralp at ITMX, and a Streckeisen at ETMX, and the Trillium is sitting to the south of the POX table.

Most of the work that's left to do is just to place the seismometers on the new stations, and to make cables.


I have taken an inventory of all the things that I think we need to buy (or I need to find in the lab) in order for us to finish this project up.

We need to buy a LEMO connector for the T-240 plate. 

We need to buy 6 O-rings:  3 to go between each aluminum plate and the granite slabs, the other 3 between the plate and the milspec connectors for the seismometer cables.

We need to buy or confirm that we have screws to attach the plates to the granite slabs.

We need to buy or confirm that we have screws to attach the milspec connectors to the plates.

I need to confirm that I have another 37-pin dsub for the Xarm Guralp cable, and a 25-pin dsub for the Trillium.

Assuming that I am reusing the existing Yarm Guralp cable, we have all the milspec connectors necessary.

I have a 30m long spool of 19-pair cable that I will use to make the Trillium cable.  I have a long cable, formerly a Streckeisen cable, that I will cut the ends off of, and make into a Guralp cable.  (We had 3 of these incredibly long, maybe ~50m cables - one became the Yarm Guralp cable, one is waiting to be the new Xarm Guralp cable, and the 3rd one is connected to the Streckeisen that we still have).

Work to be done:

* Make long cables for Xarm Guralp and Vertex Trillium.  Check pinouts for the milspec -> dsub connections on each cable.

* Make small cables that go inside of the granite and seismometer station.  These are to connect the sensor to the aluminum plate, and then the long cables go from the plate to the readout box.  Unfortunately, the holes in the granite are not large enough to pass a connector through, so these will have to be soldered in-situ. 

* Plug in the Trillium readout box and confirm that it's working / makes sense.

Longer term modifications and add-ons:

* Lemo connector with wiring for temperature and pressure sensors inside the vertex station.  I believe that Den was looking into what sensors we might want.

* Needle valve for slow pressure equalization on vertex station (all stations should have this, but only the Trillium plate has a hole for this). 


Is there anything else that I'm forgetting??  Please reply with thoughts.

 

  9270   Wed Oct 23 19:28:22 2013 JenneUpdateLSCNew lockin / sensing matrix model parts

I have modified the Sensing Matrix I,Q to Mag, Phase library part in the new sensing matrix system.

I had forgotten that in the c-code, I convert from radians to degrees, and so was doing the conversion again in the model.  As it turns out, this gives you a nonsense number.  I removed the multiplication by 180/pi in the model, and just use the output of the c-code, which is already in degrees.

I also put in some "choice" blocks just before the divisions in the calibration section of this library part.  If it's about to divide by zero, divide by one instead.

The last modification so far today was adding the _PHASE_DEG and _MAG_WPERM (watts per meter) channels to a DAQ channels block, so that they are saved.

The RCG was very unhappy with me having 2 channels, with no data rate after them (doing this is supposed to imply that both should be saved at the default data rate), however after I put in "2048", it was happy.  The symptom was a little tricky:  The channel names in Dataviewer showed up red, even though the model compiles and runs.  An indicator that you have a problem is a note in the model's "GDS" screen (the details screen that you can click to from the CDS front end overview screen).  The channel name is "C1:FEC-50_MSGDAQ" (where the number 50 is specific to the c1cal model).  After restarting the model, but before restarting the framebuilder's daqd process, this channel said "Error reading DAQ file!", rather than the date and time of the last successful read.   At this point, before restarting the daqd process on the framebuilder, all of the fb statuses are green and good.  However, after restarting the daqd process on the framebuilder, I got status "0x2000".  Anyhow, after trying many different things, I determined that I could have 1 channel, without a specified rate, but if I wanted more than one channel, I needed to specify the rate for both.

  9271   Wed Oct 23 22:11:20 2013 ranaUpdateCDSWorkstation swap: Rosalba to ???

  I've finished setting up the fstab on Chiara and the upgrade to Ubuntu 12 seems to have gone well enough. She's fast:

24.png

but I forgot to make sure to order a dual head graphics card for it. So we'll order some dual DVI gaming card that the company recommends. Until then, its only one monitor.

Still, its ready for testing control room tools on. If everything works OK for a couple weeks, we can go to 12 on all the other ones.

  9273   Thu Oct 24 04:07:32 2013 MasayukiUpdateGreen LockingEnd PDH control signal, X-end PDH servo gain optimization

Control signal measurement of end PDH control

The Yarm ALS wasn't robust. Yesterdays night, we found that suspension kicked by something and that was the reason why the end PDH control lost lock. To make sure that the PDH loop itself is robust, I measured control signals of End PDH loops. When the gain inclease, the peak at UGF appeared and become unstable. Both arms does not seems unstable before the peaks appear.

controlsignal.png

 Xarm PDH servo gain optimization

I optimized the x end PDH servo gain with measuring OLTF. Now the servo gain is 5.0. UGF is around 10 kHz and phase margin is 40 degree.

OLTF.png

Also I measured out of loop noise. I locked the arm using IR PDH, and measure the ALS error signal. The high frequency noise become better.

outojloop.png

  9274   Thu Oct 24 04:13:15 2013 JenneUpdateLSCPRMI + 2 ALS arms

[Masayuki, Jenne, Rana]

We have, for the past hour and a few minutes, had PRMI + 2 arms locked.  Yup, that's right, we did it! (We never gave control of the arms to the IR LSC system, so it's kind of cheating, but it was still cool.)

A little after midnight, we felt that the Yarm was behaving well enough that we could give PRMI + 2 arms a try.  So we did.  Probably around 1am-ish, or maybe a little bit before, we had the system locked. 

How did we do it?

* Locked arms in IR to help find green beatnotes.

* Misalign ETMs, lock and align PRMI.

* Misalign PRM.

* Restore ETMs, find arm resonances, then step away (I did +3 counts, which is 29 kHz).

* Restore PRM, lock PRMI.

* Brought Xarm back close to resonance using ALS (-3 counts). It seems like this may not actually have gotten us back to perfect resonance, but that actually made bringing in the other arm easier.

* Brought Yarm back close to resonance using ALS (-3 counts). 

* Turned on Sensing Matrix notches and oscillators (10,000 counts for MICH, actuating on BS and PRM at 562.01 Hz, 200 counts for PRCL actuating on PRM at 564.01 Hz). 

* Stepped arms back and forth to see how things responded.

Notes:

During this process, particularly during the various arm steps, the PRMI lost lock many times.  However, the ALS system never lost lock for either arm, for an hour and a half or so.  Good work, ALS team!!  The PRMI would reaquire lock (sometimes we'd have to undo whatever arm step we just took, to get farther away from resonance) without any intervention.  It seemed that as we came closer to full arm resonance, we were never able to hold PRMI locked.  This is what is instigating some of our investigations for tomorrow.

Also, Rana reported to me that he turned the c1tst model back off, and opened the door(s?) to the ETMY rack to allow more air flow sometime before midnight, which seems to have reduced the rate of the CPU going over 61 microseconds, as well as reduced the number of times the ETMY suspension glitches.  We definitely need to make some changes so that we're not so close to the edge.  This may have been one of the big things that allowed our success tonight.

The transmission PDs at the ends of the arms are saturating around 50 counts (they have gains of 2e-3 so that they are roughly normalized to 1 being the max power in a single arm).  We need to commission the end transmission QPDs. 

All of the signals looked a little ratty, and we heard lots of noise - Rana suggests that we recommission our CARM servo.

ALS beat info:  [Xarm  40.9 MHz,  -11.4 dB], [Yarm  50.5 MHz,  -17.7 dB]

Things to look at tomorrow:

Data!  I should be able to extract sensing matrix information, even though my sensing matrix software isn't totally ready yet.  I know what the oscillators were doing, and I can look at the PD error signals.  We also save the Offsetter numbers, so I can kind of tell what the PRMI+arms situation was. 

Can we tell by looking at the end laser PZT feedback signals whether we're making our arms longer or shorter?  So that we can tell if we're putting on DARM or CARM offsets.

Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if we're saturating while we bring the arms into resonance.  Basically, does anything bad happen, particularly since the PD is not a resonant PD, so there are some 1f signals floating around in addition to the 3f signals.  We want to put in a directional coupler after the PD, before the demod board, and send that signal to a spectrum analyzer and a 'scope.  Hopefully we can use the power of the internet to not need to sit in the IFO room saving data as we move the arms around.  Do we need to put bandpass filters on the PD signal before it goes to the demod board?

Optickle model of 1f vs. 3f signals in the different ports, as the CARM offset is reduced.

Violin notches for the arms - should be put into ALS and LSC models.  It looks like the modes are around 631 Hz, but we should check. 

Hardware for end low gain transmission QPDs.

Software (schmidt triggering) for end transmission QPDs.

Modifying / preparing a matrix in the ALS system so that we can give CARM and DARM offsets conveniently.

  9275   Thu Oct 24 08:04:54 2013 SteveUpdateLSCPRMI + 2 ALS arms

 

 Nice work. Congratulation

  9276   Thu Oct 24 09:08:27 2013 jamie.UpdateLSCPRMI + 2 ALS arms

nice.

  9277   Thu Oct 24 10:31:25 2013 SteveUpdateSUSETMY sensors compared to ETMX

Atm1,  The strong glitches are back.

Atm2,  SUS-ETMX & Y_SENSOR_LL Damping OFF at (ref0 & ref1). damping ON (red & blue)

ETMY sus looks OK

 

Attachment 1: 24h_glitching.png
24h_glitching.png
Attachment 2: dampingOffref.png
dampingOffref.png
  9278   Thu Oct 24 12:00:11 2013 jamieUpdateCDSfb acquisition of slow channels

Quote:

 

 While that would be good - it doesn't address the EDCU problem at hand. After some verbal emailing, Jamie and I find that the master file in target/fb/ actually doesn't point to any of the EDCU files created by any of the FE machines. It is only using the C0EDCU.ini as well as the *_SLOW.ini files that were last edited in 2011 !!!

So....we have not been adding SLOW channels via the RCG build process for a couple years. Tomorrow morning, Jamie will edit the master file and fix this unless I get to it tonight. There a bunch of old .ini files in the daq/ dir that can be deleted too.

I took a look at the situation here so I think I have a better idea of what's going on (it's a mess, as usual):

The framebuilder looks at the "master" file

    /opt/rtcds/caltech/c1/target/fb/master

which lists a bunch of other files that contain lists of channels to acquire.  It looks like there might have been some notion to just use 

    /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini

as the master slow channels file.  Slow channels from all over the place have been added to this file, presumably by hand.  Maybe the idea was to just add slow channels manually as needed, instead of recording them all by default.  The full slow channels lists are in the

    /opt/rtcds/caltech/c1/chans/daq/C1EDCU_<model>.ini

files, none of which are listed in the fb master file.

There are also these old slow channel files, like

    /opt/rtcds/caltech/c1/chans/daq/SUS_SLOW.ini

There's a perplexing breakdown of channels spread out between these files and C1EDCU.ini:

controls@fb ~ 0$ grep MC3_URS /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini
[C1:SUS-MC3_URSEN_OVERFLOW]
[C1:SUS-MC3_URSEN_OUTPUT]
controls@fb ~ 0$ grep MC3_URS /opt/rtcds/caltech/c1/chans/daq/MCS_SLOW.ini
[C1:SUS-MC3_URSEN_INMON]
[C1:SUS-MC3_URSEN_OUT16]
[C1:SUS-MC3_URSEN_EXCMON]
controls@fb ~ 0$

why some of these channels are in one file and some in the other I have no idea.  If the fb finds multiple of the same channel if will fail to start, so at least we've been diligent about keeping disparate lists in the different files.

So I guess the question is if we want to automatically record all slow channels by default, in which case we add in the C1EDCU_<model>.ini files, or if we want to keep just adding them in by hand, in which case we keep the status quo.  In either case we should probably get rid of the *_SLOW.ini files (by maybe integrating their channels in C0EDCU.ini), since they're old and just confusing things.

In the mean time, I added C1:FEC-45_CPU_METER to C0EDCU.ini, so that we can keep track of the load there.

 

  9279   Thu Oct 24 14:14:18 2013 ranaUpdateLSCPRMI + 2 ALS arms

 Just in case people were confused, although the PRMI + 2 ALS arms were controlled, we weren't able to bring them in to resonance. They were in some unknown off-resonant state.

We can try to calculate the expected recycling gain (ignoring losses in the PRM) following section F.2.1 of my Manifesto:

T_PRM = 5.6%, R_ARMS ~ 98%, G_PRC ~38.

So the full TRX/TRY powers should be G_PRC/T_PRM = 690.

In our stable configuration, we were sitting at TRX/Y powers of ~5-10. Once in awhile we could get a state where the power was saturating the detectors at ~50 and possibly would have gone up to 100, but it was all oscillation at that point. (we've got to find and notch the ETM violin mode frequencies in the ALS feedback servos.

As we move in towards resonance, we have to now consider all of complications of handing off to various error signals and CARM optical spring compensation and RF saturation that have been discussed in Rob's thesis and Lisa's lock acquisition modeling.

  9280   Thu Oct 24 15:19:58 2013 KojiUpdateLSCPRMI + 2 ALS arms

all of complications of handing off

That involves:

- ALS error signals transfered to the LSC input matrix.

- Handing off from the ALS to the 1/sqrt(TRX)+offset signal

- Handing off to the RF signal

- And, of course, CM servo.

  9281   Thu Oct 24 17:18:44 2013 SteveUpdateSUSETMY oplev error signals are still bad

Quote:

 Just plot.

RA: I'm not sure how to interperet this; I think that the SUM channel is divided by the SUM so that this is supposed to be RIN, but not sure. Can someone please take a look into the SUS model and then explain in the elog what the SUM normalization algorithm is?

 

Attachment 1: ETMY_OPLEV_ERRORS.png
ETMY_OPLEV_ERRORS.png
  9282   Thu Oct 24 17:26:35 2013 jamieUpdateCDSnew dataviewer installed; 'cdsutils avg' now working.

I installed a new version of dataviewer (2.3.2), and at the same time fixed the NDSSERVER issue we were having with cdsutils.  They should both be working now.

The problem turned out to be that I had setup our dataviewer to use the NDSSERVER environment, whereas by default it uses the LIGONDSIP variable.  Why we have two different environment variables that mean basically exactly the same thing, who knows.

  9283   Thu Oct 24 19:12:45 2013 MasayukiUpdateGreen LockingALS OFFSETTER calibration

I calibrated the ALS-OFFSETTER output.
I measured the FSR of cavity in unit of counts. That was 395 counts. Our cavity FSR is 3.8 MHz, so 1 count of the OFFSETTER output is 9.7 kHz.

  9284   Thu Oct 24 21:46:18 2013 KojiUpdateGreen LockingALS OFFSETTER calibration

Quote:

I calibrated the ALS-OFFSETTER output.
I measured the FSR of cavity in unit of counts. That was 395 counts. Our cavity FSR is 3.8 MHz, so 1 count of the OFFSETTER output is 9.7 kHz.

 Really? What cavity length did you use in the calculation?

  9285   Thu Oct 24 23:12:21 2013 jamieUpdateCDSnew dataviewer installed; no longer works on Ubuntu 10 workstations

Quote:

I installed a new version of dataviewer (2.3.2), and at the same time fixed the NDSSERVER issue we were having with cdsutils.  They should both be working now.

The problem turned out to be that I had setup our dataviewer to use the NDSSERVER environment, whereas by default it uses the LIGONDSIP variable.  Why we have two different environment variables that mean basically exactly the same thing, who knows.

 Dataviewer seems to run fine on Chiara (Ubuntu 12), but not on Rossa or Pianosa (Ubuntu 10), or Megatron, which I assume is also something medium-old.

We get the error:

controls@megatron:~ 0$ dataviewer
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Error in obtaining chan info.
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1

Sadface :(   We also get the popup saying "Couldn't connect to fb:8088"

  9286   Thu Oct 24 23:25:37 2013 JenneUpdateLSCEnd transmission triggering

Quote:

Software (schmidt triggering) for end transmission QPDs.

 I have modified the ETM suspension models to include a schmidt triggering block, so that we can choose between using the high gain low power Thorlabs PD and the low gain high power QPD. 

The Thorlabs high gain PD signal is used as the signal to trigger on, so we need to put appropriate thresholds in.

If things are "triggered", that will imply that the Thorlabs PD is seeing a lot of power, so we should be using the QPD SUM channel instead.  There is a "choice" block after the trigger block, to do this switching.

Since the LSC model will only see the output of this choice block, the gain that is currently in C1:LSC-TR[X or Y]_GAIN should be moved to the end SUS model.  We also need to find the correct gain for the QPD sum channels so that they are also normalized to "1" for single arm full power so that we can smoothly go between the 2 diodes.

Rana has promised to make screens, and write scripts for the switching stuff.

  9287   Thu Oct 24 23:30:57 2013 jamieUpdateCDSnew dataviewer installed; no longer works on Ubuntu 10 workstations

Quote:

Quote:

I installed a new version of dataviewer (2.3.2), and at the same time fixed the NDSSERVER issue we were having with cdsutils.  They should both be working now.

The problem turned out to be that I had setup our dataviewer to use the NDSSERVER environment, whereas by default it uses the LIGONDSIP variable.  Why we have two different environment variables that mean basically exactly the same thing, who knows.

 Dataviewer seems to run fine on Chiara (Ubuntu 12), but not on Rossa or Pianosa (Ubuntu 10), or Megatron, which I assume is also something medium-old.

We get the error:

controls@megatron:~ 0$ dataviewer
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Error in obtaining chan info.
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1

Sadface :(   We also get the popup saying "Couldn't connect to fb:8088"

Sorry, that was a goof on my part.  It should be working now.

ELOG V3.1.3-