40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 104 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  8975   Wed Aug 7 10:09:30 2013 KojiUpdateLSCArms locked in IR, aligned. IFO at nominal power

I have a concern about the SRM suspension. The yaw alignment bias produces huge pitch coupling.

This could be a connector issue or the rubbing of the mirror on the EQ stops.

We have the photos of the magnets and they were not touching the OSEMs.

  8977   Wed Aug 7 15:32:37 2013 KojiUpdateASCASS setting up accelerated (slightly)

I moved bunch of ezcawrite from the ASS Dither On script to a snapshot file.

This accelerated a half of the "up" time but still switching part is not in the snapshot.

If you find anything wrong with ASS, please notify me.

  8982   Wed Aug 7 22:18:43 2013 KojiUpdateASCASS update

While Gautam is working on the Xarm green ASS...

The EPICS monitor points for the ASS actuators were added to the ASS model.

This will be used for the offloading the ASS actuations to the alignment biases.
As this modification allowed us to monitor the actuation apart from the dithering,
now we can migrate the ASS actuation to the fast alignment offset on the suspension.
This modification to the offset moving scripts were also done.

Screenshot-Untitled_Window.png

  8989   Thu Aug 8 21:25:36 2013 KojiUpdateGeneralPost-vent alignment cont'd

- IPANG aligned on the QPD. The beam seems to be partially clipped in the chamber.

- Oplev of the IFO mirrors are aligned.

- After the oplev alignment, ITMX Yaw oplev servo started to oscillate. Reduced the gain from -50 to -20.

  8991   Fri Aug 9 21:05:28 2013 KojiUpdateSUSfixed: SRM coils fine - problem with slow bias slider

Now the SRM Yaw bias in yaw is functional without any strage behavior.
The problem was found at the connector of the flat ribbon cable from the DAC to the cross connect.

I used the extender board to diagnose the SRM coil driver circuit at 1X4.
The UL coil input did not show any sign of voltage no matter how the bias slider was jiggled.

I opened the side panel of the rack and found the signal was absent at the cross connect which relays two flat ribbon cables
for the SRM coil driver. I checked the DAC output with a multimeter. All the bias outputs were OK at the DAC.

Then I opened the IDC connector at the DAC side of the crossconnect as the signal was already missing there.
I found that the flat ribbon cable was a half line shifted from the supposed location.
This resulted a short circuit of the DAQ +/- pins for the SRM UL coil.

I recrimped the connector and now the SRM Yaw slider is back.
This changed the nominal position of the SRM. The new slider values were saved.

  8992   Fri Aug 9 22:51:37 2013 KojiUpdateLSCPRMI(sb) lock recovered

PRMI(sb) lock was recovered


PRMI lock

- Stared at the time series data of the REFL demod signals, and decided to use REFL165I&Q for the locking.

- Jiggled the demodulation phase of REFL165 and POP110. Changed the servo gains.

- Finally found a short lock. Further optimized the parameters.

- PRM ASC was turned on by giving the identity matrices for the input and output matrices.
  Now just hitting the up button is sufficient to engage the ASC servo.

- Under the presence of the ASC, the PRMI is indefinitely locked as before.

- Reacquisition is also instantaneous. (It acquires even if the ASC is left "on".)

- Actually the lock is somewhat robust even when the PRM ASC is not used.
  This is VERY GOOD as we can skip one of the steps necessary for the full lock.

  Although, the seismic on Friday night is very quiet.
  The spot motion at POP seems to be somewhat pitch/yaw mixed, in stead of previous "totally-dominated-by-yaw" situation.

- We are ready to implement ASS for PRM

Demod phase adjustment

- Shook PRM at 580Hz / 100cnt

- Swept the demod phase of REFL165 such that the PRM peak is minimized in the Q signal

- Open DTT. Measured transfer functions between REFL165I and the Q signals of each PD.

- Minimized the PRCL signal coupling in the signals.

- The resolution of the adjustment was ~1deg.

Locking test with PRM/BS

Tried the lock acquisition only with PRM and BS. (cf. http://nodus.ligo.caltech.edu:8080/40m/8816)

This just worked nicely.


Today's locking parameters:

PRMI(sb) lock:

MC Trans: 17500
POP110I (in lock): 150

PRCL Source: REFL165(I) 106deg / 45dB / Normalization SQRT(10 POP110I) / Input MTRX 1.0
PRCL Trigger: POP110I x 1.0 50up 25down
PRCL Servo: G=+3.5 Acq: FM4/FM5 Opr: FM2/FM3/FM6/FM7
PRCL Actuator: PRM +1.0

MICH Source: REFL165(Q) 106deg / 45dB / Normalization SQRT(0.1 POP110I) / Input MTRX 1.0
MICH Trigger: POP110I x 1.0 50up 25down
MICH Servo: G=-10 Acq: FM4/FM5 Opr: FM2/FM3/FM6
MICH Actuator: (ITMX -1.0 / ITMY +1.0) or (BS 0.5 / PRM -0.267)

Demod phases:

AS55 -17deg
REFL11 135deg
REFL33 -18deg
REFL55 120deg
REFL165 106deg

  8999   Mon Aug 12 17:30:03 2013 KojiUpdateASCPRCL ASS software in place

Why POPDC???

  9007   Tue Aug 13 17:20:54 2013 KojiUpdateCDS[Fixed] c1iscex needs help

c1x01 timing issue was solved. Now all of the models on c1iscex are nicely running.

Symptons

- c1x01 was synchronized to 1PPS in stead of TDS

- C1:DAQ-DC0_C1X01_STATUS (Upper right indicator) was red. The bits were 0x4000 or 0x2bad.
  C1:DAQ-DC0_C1X01_CRC_SUM kept increasing

 - c1scx, c1spx, c1asx could not get started.

Solution

- login to c1iscex "ssh c1iscex"

- Run "sudo shutdown -h now"

- Walk down to the x end rack

- Make sure the supply voltages for the electronics are correct (See Steve's entry)

- Make sure the machine is already shutdown.

- Unplug two AC power supply of the machine.

- Turn off the front panel switch of the IO chassis

- Wait for 10sec

- Turn on the IO chassis

- Plug the AC power supply cables to the machine

- Push the power switch of the realtime machine

  9009   Tue Aug 13 21:49:32 2013 KojiSummaryGeneralTesting new AG4395A network analyzer

New AG4395, sn MY41101114  for West Bridge Labs was delivered. For the test purpose it is at the 40m now.

I made a series of tests in order to find anything broken.

Network analyzer test

- RF out / Rch test

RF out directly connected to R input channel.
The received power at the R-ch was measured while the output was swept from 10Hz to 500MHz.

The RF power was changed from -50dBm to +15dBm with +10dBm increment (but the last one).

The attenuator setting was changed from 50dB to 0dB.

=> The configured output power was properly detected by the R channel.

=> RF output is producing the signal properly. R-ch is detecting the produced signal properly.

- Ach/Bch test

Same test as above for Ach and Bch 

=> Same result as above

=> A-ch and B-ch are detecting the produced signal properly.

- Transfer function test

Connect a power splitter to the RF out. Detect the split signals by R-ch and A-ch

=> Measurement is at around 0dB +/- 1dB up to 500MHz.

Same measurement for B-ch

=> Same result

=> A/R and B/R indicates proper transfer function measurements.

- Calibration

RF out was split in to two. One was connected to R-ch. The other was connected to A-ch.
The thru response calibration was run.

=> The thru calibration was performed properly. 

- Practical tranfer function measurements.

In the above calibration setup, various RF filters were inserted in the Ach path.

The measured data was extracted via GPIB connection.

=> Practical transfer function measurements were performed.

=> GPIB connectivity was confirmed

 

External reference test

- External 10MHz reference from an SRS frequency counter was connected to Ext Ref In

=> Ext Ref indicator on the screen appeard

=> The internal oscillator seemed to be locked to the external reference in

 

 

Spectrum analyzer test

- Measured the signals from DS345 by R/A/B ch

Sinusoidal signal (1V) swept from 10MHz to 30Mhz

=> Corresponding moving peak was detected in each case

- Noise level measurement

R/A/B channels were terminated. The attenuation at each port was set to 0dB.

Frequency span was changed between 500MHz, 10MHz, 100kHz, 1kHz.

=> Noise level of ~10nV/rtHz between 0.1-500MHz was confirmed. All R/A/B channels have the same performance.

Attachment 1: AG4395A_noise.pdf
AG4395A_noise.pdf
  9010   Tue Aug 13 22:21:12 2013 KojiSummaryGeneralMinicircuit Filter TFs (AG4395A test)

As a part of the network analyzer test in the previous entry, the transfer functions of Mini-Circuits filters we have at the 40m were measured.

<<List of the filters>>

- LPF (SMA): SLP1.9, SLP5, SLP21.4, SLP30, SLP50, SLP100, SLP150, SLP750
- LPF (BNC): BLP1.9, BLP2_5, BLP5, BLP30
- BPF (SMA): SBP10.7, SBP21.4, SBP70
- HPF (SMA): SHP25, SHP100, SHP150, SHP200, SHP500

 

Attachment 1: Minicircuit_LPF.pdf
Minicircuit_LPF.pdf
Attachment 2: Minicircuit_BPF.pdf
Minicircuit_BPF.pdf
Attachment 3: Minicircuit_HPF.pdf
Minicircuit_HPF.pdf
Attachment 4: 130813.zip
  9012   Thu Aug 15 01:51:50 2013 KojiSummaryGeneralRFM<->Dolphin bridge distributed to c1rfm and c1mcs

Since the RFM-Dolphin bridges for the ASX model was added to the c1rfm model, c1rfm kept timing-out from the single sample time of 60us.

The model had 19 dolphin accesses, 21 RFM accesses, and 9 shared memory (SHM) accesses.

At the beginning 2 RFM and 2 SHM accesses were moved to c1sus (i.e. they were mistakenly placed on c1rfm).
But this actually made the c1sus model timed out. So the model was reverted.

The current configuration is that the WFS related bridges were accommdated in the c1mcs model.
This made the timing of c1rfm ~40us. So it is safe now.
On the other hand, the c1mcs model has the time consumption of ~59us. This is marginal now.

We need to understand why any RFM access takes such huge delay.

  9018   Fri Aug 16 13:25:50 2013 KojiUpdateASSASX model/screen cleaning up

[Koji Manasa]

Yesterday we cleaned up the ASX model and screens to have more straight forward structure of the screen
and the channel names, and to correct mistakes in the model/screens.

The true motivation is that I suspect the excess LF noise of the X arm ALS can be caused by misalignment
and beam jitter coupling to the intensity noise of the beat. I wanted to see how the noise is affected by the alignment.
Currently X-end green is highly misaligned in pitch.

- Any string "XEND" was replaced by "XARM", as many components in the system is not localized at the end table.

- The name like "XARM-ITMX" was changed to "XARM-ITM". This makes easier to create the corresponding model for the other arm.

- There was some inconsistency between the MEDM screens and the ASX model. This was fixed.

- A template StripTool screen was created. It is currently saved in users/koji/template as ASX.stp.
  It will be moved to the script directory once it's usefulness is confirmed.


The next step is to go to the end table and manually adjust M2 mirror while M1 is controlled by the ASX.
The test mass dithering provides the error signal for this adjustment but the range of the PZT is not enough
to make the input spot position to be controlled. In the end, we need different kind of matching optics
in order to control the spot position. (But is that what we want? That makes any PZT drift significantly moves the beam.)

  9025   Mon Aug 19 09:36:32 2013 KojiUpdateGreen LockingXend green aligned

[Rana Koji]

This is an elog about the activity on Friday night.

- The X arm green beam was aligned with assist of the ASX system.

- M1 PZT alignment was swept while M2 PZT was under the control of ASX.

- Everytime M1 was touched, M2 was restored by manual alignment so that the REFL beam hits the center of the REFL PD.
  This way we could recover the lock of TEM00. Once TEM00 is recovered, ASX took care of the alignment of M2

- The error signal used by the cavity dither did not give us a good indication where the optimal alignment is.

- Thus the best alignment of M1 had to be manually scanned. The resulting maximum green transmission was ~0.88

- Once the beam was aligned, the out-of-loop stability of the Xarm was measured.
  There has been no indication of the improvement compared to Manasa's measurement taken before our beam alignment.

Attachment 1: ALS_OUTOFLOOP_130816.pdf
ALS_OUTOFLOOP_130816.pdf
  9032   Mon Aug 19 15:23:07 2013 KojiUpdateIOOMC mirrors' ASC has non-zero inputs

[Jenne, Koji]

This disturbance in the MC ASC channels were fixed.

This craziness happened ~10pm last night. Was there any action at the time? >> Sunday-night workers? (RXA: No, Nakano-kun and I left before 9:30 PM)

We found that the signals came from c1ioo. However, restarting, recompiling c1ioo and c1mcs didn't help
to clean up this issue. Just in case we cleaned up the corresponding entries in the ipc file /opt/rtcds/caltech/c1/chans/ipc/C1.ipc
and recomplied c1ioo and c1mcs because these are the channels we touched last week to mitigate the timing out issue of c1rfm.

Incidentally, we fell into a strange mode of the RCG: IOPs could not restart. We ended up running "sudo shutdown -r now"
on each machine (except for c1lsc which was not affected by this issue). This solved the issue.

Even now c1oaf could not be running properly. This is not affecting the IFO operation right now, but we need to look into this issue again
in order to utilize OAF.

  9035   Mon Aug 19 19:08:35 2013 KojiUpdateGreen LockingXend green layout corrections

- An Aluminum mirror instead of 2" unknown mirror for the pick-off for the rejected beam from the green faraday isolator (Steve)
=> Replaced. To be reviewed

- Faraday mount replacement. Check what we have for the replacement. (Steve)

- The green REFL PD should be closer to the pick-off mirror. (Steve)
=> Moved. To be reviewed

- A beam dump should be placed for the green REFL PD

- Move the green shutter to the place where the spot is small (Steve)
=> Moved. To be reviewed.

- The pole of the PZT mounting should be replaced with a reasonable one. (Steve with Manasa's supervision)

- Tidying up doubling oven cable. Make a hole on the wall. (Steve)
=> Done. To be reviewed.

- Tidying up the PZT cabling (Steve)

- The optics are dirty. To be drag wiped. (Manasa, Masayuki)

  9040   Tue Aug 20 11:41:30 2013 KojiUpdateLSCREFL investigations

As I always tell everyone: Don't use a 10% reflector which produce ghost beams. Use a 90% reflector.

  9048   Wed Aug 21 23:50:40 2013 KojiUpdateSUSPRM SUS_LSC violin (FM5) set to correct frequency

[Jenne Koji]

It seems that the PRM violin mode freqs shifted from 625-ish to 640Hz.
The peaks rang up because of the servo.

Once the notch freq was shifted to 640Hz, the violin mode started to decay.

ellip("BandStop",4,1,90,636,644) gain(1.12202)

  9053   Thu Aug 22 13:20:54 2013 KojiUpdateLSCDRMI Locked for 1+ minute!!!!!!

Don't go for a hacky solution. We want to climb a staircase step by step.
Prepare an independent 110MHz demod ports.

Quote:

To-do:  Set up the AS OSA.  Also, perhaps temporarily borrow the 110 demod board from POP.  We were triggering on POP22 tonight, and that seemed to work okay. 

 

  9060   Sat Aug 24 00:11:07 2013 KojiUpdateLSCDRMI Locked with improved lock streatches

Friday night locking

Much more stable DRMI lock was achieved, partly thanks to the Friday-night quiet seismic,
and partly because of the improved servo gain and LF boosts


55MHz thru-put

I wanted to confirm the enhancement of the 110MHz signal at the AS port.

As the AS110 PD is placed in the CCD path, there is nothing visible with PRMI.
The Thorlabs PD was moved to the main AS path. Now the AS110 PD is receiving 50% of the power.
 

With PRMI 110MHz peak was -30dBm (As it was fluctuating, anything more precise number did not make sense)
When the DRMI was locked, the peak was enhanced to 0dBm.

The 2f signal comes from the beat between the sidebands.
Thus the amplitude of the intensity is proportional to the power of the sidebands (assuming the +1 and -1 order sidebands have the same amplitude)
-30dBm -> 0dBm means 31.6 times amplitude of the intensity. Therefore the amplitude transmission of the sidebands is 5.6 times more. (Is this true?)

According to the wiki, the AS port thru-put (i.e. power transmission) for the 55MHz sideband is 0.0026 and 0.43 for PRMI and DRMI respectively.
This corresponds to the amplitude difference of ~13. So we still have only half of the sidebands leaking out from the IFO. This could be attributed
to both the smaller PR gain and SR gain.


Locking setup

Same as the one Jenne used the other day. Later I engaged several additional triggers.
The following is the trigger setting I used

MICH: Delay 2 sec, FM1/FM2/FM3/FM6/FM7

PRCL: Delay 0.5 sec, FM2/FM3/FM6

SRCL: Delay 5 sec, FM1/FM2/FM3/FM6

SRCL FM1 was modified from +3dB to +6dB


Lock stability

Once lock is acquired, it lasts tens of minutes. (see the attached striptool chart.)
Even the lock is lost, it reacquires quickly.

The videos to show the lock acquisition and the in-lock stability are attached below.
The AS port beam is very round. It is not so shaky, but some yaw motion is visible.
The mode at the AS port is defined by the SRM, putting a QPD at the AS port would help to
stabilize the spot.


IFO state upon leaving

I left the 40m with the arms aligned, PRM and SRM slightly misaligned, and LSC setting is for the DRMI locking.


TO DO

- AS110I/Q for triggering

- PRCL/MICH/SRCL normalization

- We should resurrect the IFO config scripts.

- Remove BS->SRCL actuation coupling

- Handing off to 3f signals (preparation for the full lock)

- Improve ALS stability

- SRM ASC: AS QPD for SRM control


Lock Acquisition Video
UL (REFL) / UR (POP)
LL (AS) / LR (PRM Face)

 
In-lock video
UL (REFL) / UR (POP)
LL (AS) / LR (PRM Face)

 

Attachment 1: Screenshot-Untitled_Window.png
Screenshot-Untitled_Window.png
  9064   Mon Aug 26 19:13:38 2013 KojiUpdateLSCLSCoffset script updated

What do you mean???

What is the effect of the anti-whitening filter?

Quote:

You should know that if you use OUT16 channel, the effect of the unwhite filter is not taken into account.

 

  9073   Tue Aug 27 18:58:52 2013 KojiConfigurationElectronics110 MHz LO options

- Do we have an appropriate amplifier?

- True challenge could be to find a feedthrough for the new port. (or to find a space for the amplifier in the box)

- PDXXX channels is on the DC whitening filter module. There could be some modification on this module (like diabling the whitening gain selector).

- We don't have AS11 and AS165, and so far it is unlikely to use AS11. i.e. The feedthrough, the slot on the crate, the whitening, and the channels can be trasnsition from 11 to 110.

Quote:

I want to amplify that by ~10 dB, to give 9 dBm.  Attenuate by 5 dB to get to 4 dBm, then split into 2, giving me 2 110 MHz spigots, each of ~1 dBm. 

Thoughts, before I start scrounging parts, and pulling the RF distribution box?

 

  9076   Tue Aug 27 20:43:34 2013 KojiConfigurationCDSfront end IPC configuration

The reason we had the PCIe/RFM system was to test this mixed configuration in prior to the actual implementation at the sites.
Has this configuration been intesively tested at the site with practical configuration?

Quote:

Attached is a graph of my rough accounting of the intended direct IPC connections between the front ends. 

It's hard to believe that c1lsc -> c1sus only has 4 channels. We actuate ITMX/Y/BS/PRM/SRM for the length control.
In addition to these, we control the angles of ITMX/Y/BS/PRM (and SRM in future) via c1ass model on c1lsc.
So there should be at least 12 connections (and more as I ignored MCL).

I personally prefers to give the PCIe card to c1ioo and move the RFM card to c1lsc.
But in either cases, we want to quantitatively compare what the current configuration is (not omitting the bridging by c1rfm),
and what the future configuration will be including the addtional channels we want add in close future,

because RFM connections are really costly and moving the RFM card to c1lsc may newly cause the timeout of c1lsc
just instead of c1sus.

  9116   Fri Sep 6 23:01:08 2013 KojiUpdateLSCStable DRMI lock was recovered from the impact on the RF system modification

Summary

Stable DRMI lock was recovered. The AS110 phase was adjusted. PRCL and MICH were locked with REFL33I and REFL165Q.
Still SRCL is controlled with REFL55Q.


PRMI sensing matrix

Thursday night, Jenne and I found DRMI can not be locked at all. Also the PRMI lock with REFL55 showed change in the optical gain.

In order to investigate what is happening, the PRMI sensing matrix was measured and compared with the previous one taken in the night of 8/26.

SensMat_PRMI_1000cts_580Hz_2013-08-26_235635.pngVSSensMat_PRMI_1000cts_580Hz_2013-09-06_201137.png

It shows that some signals are unchanged, some are partial change, and some are completely different.
My intuition saids something is wierd with the sensing matrix measurement.
Right now I can't trust these plots.

- Jenne and I have adjusted REFL55 demod angle so that REFL55Q has no PRCL. And I have confirmed with DTT that this is still true.
  However, the radar chart shows that REFL55Q is almost correct phase for PRCL instead of MICH.

- REFL11 shows the same amplitude and angle as before. But POX11/POY11 shows different MICH angle.

- I have rotated REFL55 demod phase and remearsured the sensing matrix. Evrything else looked same but REFL55.
  Since REFL55I&Q were not used for the control for this measurement, what we expect is to see no change of the sensing matrix and
  only see the angle of "I"&"Q" rotates. But the result was different from the expectation.

DRMI locking

Since no real info was obtained from the sensing matrix, I had to make a fight without any weapon.
After sevral hours of work, stable DRMI lock was recovered.

Basically I gave larger gains to REFL55 signals: REFL55I for SRCL was 100 instead of 1, and REFL55Q for MICH was 2 instead of 0.1.
This was enough to get a second locking. Using this short sections, I have optimized the FM triggers and the gain boosts (i.e. FM1)
as well as the mirror alignment.

Then, PRM ASS was left running during the lock. This actually stabilized the lock a lot.
This made thee lock indefinite.

The demod phase of AS110I was adjusted so that AS110Q fluctuates around zero.
In this condition, the nominal AS110I was 7300 with the whitening gain of 30dB.

Note that the AS110I&Q were also measured with PRMI. With the same phase and gains, AS110I and Q were -35,  -170, respectively.
Do we expect to have this phase shift? If I believe these numbers, the aplitude of 110MHz at the optimal phase is 173,
The ratio of AS110 between DRMI and PRMI is 7300/173 = 42. This corresponds to the ratio of the 110MHz sideband power at the AS port.
According to the wiki, this ratio shoud be ~160.

AS110I was in fact glitchy as you can see in the StripTool chart. I wonder this signal is suitable for the normalization or not.


=== SENSING ===

REFL11 -67deg / whitening gain 0dB
REFL33 -20deg / whitening gain 30dB
REFL55 45deg / whitening gain 6dB
REFL165 96deg / whitening gain 45dB

POP110 69deg whitening on / 15dB
POP22 102.2deg whitening on / 21dB
AS110 145deg whitening off / 30dB (seems to be related to AS11 whitening setting)

=== INPUT MATRIX ===

REFL11I x -0.125 => PRCL (REFL33I x 2.5 was also OK)
REFL55I x 100 => SRCL
REFL55Q x 2 => MICH (REFL165Q x 0.1 was also OK)

=== NORMALIZATION / TRIGGER ===

No normalization

Trigger settings
MICH POP22I UP:50 DOWN:10
PRCL POP22I UP:50 DOWN:10
SRCL POP22I UP:50 DOWN:25

=== SERVO FILTERS ===

MICH x -0.8 FM4/5 ON, no limitter
FM Trigger: delay 2sec, FM1 (modified from 6dB to 20dB), FM2, FM3

PRCL x +0.035 FM4/5 ON, no limitter
FM Trigger: delay 0.5sec, FM2/3/6

SRCL x -0.1 FM4/5 ON, no limitter
FM Trigger: delay 5sec, FM1, FM2

=== OUTPUT FILTERS ===

MICH => PRM -0.267 / BS +0.5

PRCL => PRM +1.0

SRCL => SRM +1.0

=== VIOLIN FILTER TRIGGER ===

delay 1sec: FM1/FM2/FM3/FM6

=== ASC/ASS ===

PRM ASC UP:50 DOWN:25
PITCH&YAW: FM1/9 (ALWAYS ON) + FM2/3 (turned on by the up-script)

PRM ASS left turned on for slow tracking

Attachment 1: DRMI.png
DRMI.png
  9124   Wed Sep 11 23:43:10 2013 KojiSummaryGreen LockingALS locking in both arms

What was the beat freq for each arm?
The HF noise level depends on the frequency of the beat note.
As the BBPD has the freq dependent noise level. (See this entry)

  9189   Thu Oct 3 01:18:57 2013 KojiHowToLSCsteps to full IFO

I vote on PRMI+1arm -> PRFPMI

  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)

  9256   Mon Oct 21 13:15:52 2013 KojiUpdateIOOPMC aligned

PMC aligned. Trans 0.78 -> 0.83

  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.

  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?

  9327   Fri Nov 1 17:44:06 2013 KojiSummaryLSCSimulation of REFL_3f signal when the arms come in

Yes, the resonance of the 2nd-order sidebands to the IFO screws up the 3f scheme.

2f (~22MHz) and 10f (~110MHz) are at x 5.6 and x 27.9 FSR from the carrier, so that's not the case.

Could we also see how much gain fluctuation of the 3f signals we would experience when the arm comes into the resonance?

  9340   Mon Nov 4 18:24:15 2013 KojiUpdateLSCThoughts on Transition to IR

 You have the data. Why don't you just calculate 1/SQRT(TRX)?

...yeah, you can calculate it but of course you don't have no any reference for the true displacement...

  9363   Sat Nov 9 10:25:43 2013 KojiUpdateLSCNew Broadband PD for POP 22/110

General Remarks on the BBPD

- To form the LC network: Use fixed SMD inductors from Coilcraft. SMD tunable capacitors are found in the shelf right next to Steve's desk.
  If the tuning is too coarse, combine an appropriate fixed ceramic SMC C and the tunable C (in parallel, of course)

- L1/C1a/C1b pads are specifically designed for an additional notch

- Another notch at the diode stage can be formed between the middle PD pin (just left of the marking "C3b") to the large GND pad (between C1a/C1b to C3a).
  You have to scratch off the green resin with a small flat screw driver (or anything similar)

- A notch at the amplifier stage can be formed between the output of MAR-6SM ("+" marking)  and one of the GND pads (left side of the "U1" marking)

- The original design of the PD is broadband. So additional notches on the diode stage provides notches and resonances.
  Check if the resonances do not hit the signal frequencies.

- One would think the PD can have resonant feature to reduce the coupling of the undesired signals.
  In some sense it is possible but it will be different from the usual resonant tank circuit in the following two points.

  * Just adding a parallel L between the cathode and ground does not work. As this DC current should be directed to the DC path,
    L&C combo should be added. In fact this actually give a notch-resonance pair. This C should be big enough so that you can ignore it
    at the target resonant frequency. Supply complimentary small C if necessary to keep low impedance of the Cs at the target frequency.
    (i.e. Check SRF - self-resonant frequency of the big C)

  * Since the input impedance of MAR-6SM is 50Ohm, the top of the resonant curve will be cut at 50Ohm. So the resultant shape looks
    like a bandpass rather than a resonance.

- So in total, simulation of the circuit is very important to shape the transimpedance. And, consider the circuit can not be formed as simulated
  because of many practical imperfections like stray Ls and Cs.

 

  9390   Fri Nov 15 09:27:58 2013 KojiUpdateIOOWFS with beam dumps

Unfortunately this does not work. These WFSs are not the detectors which we can move freely.
In order to move the WFS detectors, we need the precise design of the Gouy phase for each WFS heads.
Without the design, we can't move the detectors.

  9394   Fri Nov 15 12:00:28 2013 KojiUpdateCDSCan't talk to AUXEY?

Quote:

Please just try rebooting the vxworks machine.  I think there is a key on the card or create that will reset the device.  These machines are "embeded" so they're designed to be hard reset, so don't worry, just restart the damn thing and see if that fixes the problem.

 Don't forget to run burtrestore for the target.

  9403   Mon Nov 18 21:26:13 2013 KojiUpdateSUSPRM pictures

Can't we somehow hook up this camera to the MUX with the movie mode?
I think both the MUX and the sensoray are compatible with the color video signal.
Only the old CRT is B/W.

  9404   Mon Nov 18 21:40:24 2013 KojiUpdateLSCPRM oplev measured and modeled TF

I forgot how we could turn on the PRM oplev servo and the PRM ASC servo at the same time without conflict.
It seems that this new oplev servo covers 0.04 to 8Hz. It's pretty broadband. Do we inject the ASC signal to the oplev error?

  9425   Mon Nov 25 10:57:14 2013 KojiUpdateCDSwoes on the X-end hosts

This morning I came in the 40m then found
1) c1auxex was throwing out the same errors as recently seen.
2) c1iscex processes had errors which persisted even after the mx stream reset.

1) c1auxex - fixed

Tried telnet c1auxex => rejected by the host

Went down to the south end. Power cycled the target. Came back to the control room.
=> Confirmed the epics read/write is back.
Burtrestored the epics vars for the target to the snapshot on 31th Oct at 5:07.

2) c1iscex - still not fixed

ssh c1iscex
rtcds restart all
=> c1x01 is still in red. 
Followed the procedure on the elog entry 9007. => Still the same error.

At least c1x01 is stalled. Here is the status.

Sync Source is TDS.
C1:DAQ-DC0_C1X01_STATUS is 0x2bad.
C1:DAQ-DC0_C1X01_CRC_SUM stays 0.
The screen shot is attached.

dmesg related to c1x01

controls@c1iscex ~ 0$ dmesg |grep c1x01
[   32.152010] c1x01: startup time is 1069440223
[   32.152012] c1x01: cpu clock 3000325
[   32.152014] c1x01: Epics shmem set at 0xffffc9001489c000
[   32.152208] c1x01: IPC at 0xffffc90018947000
[   32.152209] c1x01: Allocated daq shmem; set at 0xffffc9000480c000
[   32.152210] c1x01: configured to use 4 cards
[   32.152211] c1x01: Initializing PCI Modules
[   32.152226] c1x01: ADC card on bus b; device 4 prim b
[   32.152227] c1x01: adc card on bus b; device 4 prim b
[   32.154801] c1x01: pci0 = 0xdc300400
[   32.154837] c1x01: pci2 = 0xdc300000
[   32.154842] c1x01: ADC I/O address=0xdc300000  0xffffc90003f62000
[   32.154845] c1x01: BCR = 0x84060
[   32.154858] c1x01: RAG = 0x117d8
[   32.154861] c1x01: BCR = 0x84260
[   32.583220] c1x01: SSC = 0x16
[   32.583223] c1x01: IDBC = 0x1f
[   32.583236] c1x01: DAC card on bus 14; device 4 prim 14
[   32.583237] c1x01: dac card on bus 14; device 4
[   32.584527] c1x01: pci0 = 0xdc400400
[   32.584546] c1x01: dac pci2 = 0xdc400000
[   32.584551] c1x01: DAC I/O address=0xdc400000  0xffffc90003f6a000
[   32.584555] c1x01: DAC BCR = 0x810
[   32.584678] c1x01: DAC BCR after init = 0x30080
[   32.584681] c1x01: DAC CSR = 0xffff
[   32.584687] c1x01: DAC BOR = 0x3415
[   32.584693] c1x01: set_8111_prefetch: subsys=0x8114; vendor=0x10e3
[   32.584722] c1x01: Contec 1616 DIO card on bus 23; device 0
[   32.593429] c1x01: contec 1616 dio pci2 = 0x4001
[   32.593430] c1x01: contec 1616 diospace = 0x4000
[   32.593434] c1x01: contec dio pci2 card number= 0x0
[   32.593439] c1x01: Contec BO card on bus 18; device 0
[   32.593447] c1x01: contec dio pci2 = 0x3001
[   32.593448] c1x01: contec32L diospace = 0x3000
[   32.593451] c1x01: contec dio pci2 card number= 0x0
[   32.593456] c1x01: 5565 RFM card on bus 7; device 4
[   32.597218] Modules linked in: c1x01(+) open_mx mbuf
[   32.599939]  [<ffffffffa002e430>] mapRfm+0x71/0x392 [c1x01]
[   32.600199]  [<ffffffffa002ec91>] mapPciModules+0x540/0x8cf [c1x01]
[   32.600458]  [<ffffffffa002f2c1>] init_module+0x2a1/0x9d6 [c1x01]
[   32.600717]  [<ffffffffa002f020>] ? init_module+0x0/0x9d6 [c1x01]
[   32.616194] c1x01: RFM address is 0xd8000000
[   32.616196] c1x01: CSR address is 0xdc000000
[   32.616206] c1x01: Board id = 0x65
[   32.616209] c1x01: DMA address is 0xdc000400
[   32.616213] c1x01: 5565DMA at 0xffffc90003f72400
[   32.616215] c1x01: 5565 INTCR = 0xf010100
[   32.616217] c1x01: 5565 INTCR = 0xf000000
[   32.616218] c1x01: 5565 MODE = 0x43
[   32.616220] c1x01: 5565 DESC = 0x0
[   32.616232] c1x01: 5 PCI cards found
[   32.616233] c1x01: ***************************************************************************
[   32.616234] c1x01: 1 ADC cards found
[   32.616235] c1x01:     ADC 0 is a GSC_16AI64SSA module
[   32.616236] c1x01:         Channels = 64
[   32.616236] c1x01:         Firmware Rev = 34
[   32.616238] c1x01: ***************************************************************************
[   32.616239] c1x01: 1 DAC cards found
[   32.616239] c1x01:     DAC 0 is a GSC_16AO16 module
[   32.616240] c1x01:         Channels = 16
[   32.616241] c1x01:         Filters = None
[   32.616242] c1x01:         Output Type = Differential
[   32.616242] c1x01:         Firmware Rev = 6
[   32.616244] c1x01: MASTER DAC SLOT 0 1
[   32.616244] c1x01: ***************************************************************************
[   32.616246] c1x01: 0 DIO cards found
[   32.616246] c1x01: ***************************************************************************
[   32.616248] c1x01: 0 IIRO-8 Isolated DIO cards found
[   32.616248] c1x01: ***************************************************************************
[   32.616250] c1x01: 0 IIRO-16 Isolated DIO cards found
[   32.616250] c1x01: ***************************************************************************
[   32.616252] c1x01: 1 Contec 32ch PCIe DO cards found
[   32.616252] c1x01: 1 Contec PCIe DIO1616 cards found
[   32.616253] c1x01: 0 Contec PCIe DIO6464 cards found
[   32.616254] c1x01: 2 DO cards found
[   32.616255] c1x01: TDS controller 0 is at 0
[   32.616256] c1x01: Total of 4 I/O modules found and mapped
[   32.616257] c1x01: ***************************************************************************
[   32.616259] c1x01: 1 RFM cards found
[   32.616260] c1x01:     RFM 0 is a VMIC_5565 module with Node ID 41
[   32.616261] c1x01: address is 0x18d80000
[   32.616261] c1x01: ***************************************************************************
[   32.616262] c1x01: Initializing space for daqLib buffers
[   32.616263] c1x01: Initializing Network
[   32.616264] c1x01: Found 1 frameBuilders on network
[   32.616265] c1x01: Epics burt restore is 0
[   33.616012] c1x01: Epics burt restore is 0
[   34.617018] c1x01: Epics burt restore is 0
[   35.618017] c1x01: Epics burt restore is 0
[   36.619011] c1x01: Epics burt restore is 0
[   37.621007] c1x01: Epics burt restore is 0
[   38.622008] c1x01: Epics burt restore is 0
[   39.733257] c1x01: Sync source = 4
[   39.733257] c1x01: Waiting for EPICS BURT Restore = 1
[   39.793001] c1x01: Waiting for EPICS BURT 0
[   39.793001] c1x01: BURT Restore Complete
[   39.793001] c1x01: Found a BQF filter 0
[   39.793001] c1x01: Found a BQF filter 1
[   39.793001] c1x01: Initialized servo control parameters.
[   39.794002] c1x01: DAQ Ex Min/Max = 1 3
[   39.794002] c1x01: DAQ XEx Min/Max = 3 53
[   39.794002] c1x01: DAQ Tp Min/Max = 10001 10007
[   39.794002] c1x01: DAQ XTp Min/Max = 10007 10507
[   39.794002] c1x01: DIRECT MEMORY MODE of size 64
[   39.794002] c1x01: daqLib DCU_ID = 19
[   39.794002] c1x01: Calling feCode() to initialize
[   39.794002] c1x01: entering the loop
[   39.794002] c1x01: ADC setup complete
[   39.794002] c1x01: DAC setup complete
[   39.794002] c1x01: writing BIO 0
[   39.814002] c1x01: writing DAC 0
[   39.814002] c1x01: Triggered the ADC
[   40.874003] c1x01: timeout 0 1000000
[   40.874003] c1x01: exiting from fe_code()

 

Attachment 1: Screenshot.png
Screenshot.png
  9430   Wed Nov 27 18:31:26 2013 KojiSummaryLSCAdittion of the ALS error signals to the LSC input matrix

The Phase tracker outputs (= ALS X/Y error signals) are now conveyed to the LSC model.

Their entry points at the LSC model are C1:LSC-ALSX_IN1 and C1:LSC-ALSY_IN1.
They are connected to the signal matrix (28th and 29th signals) via signal conditioning filters (C1:LSC-ALSX and C1:LSC-ALSY).

The main LSC screen has not been updated. The conventional ALS servos are still remains as they were.

This renovation required the recompilation of c1als, c1rfm, and c1lsc. Two PCIe-RFM bridge paths were added resulting in
increase of the c1rfm timing budget from 38 to 44.

  9436   Tue Dec 3 17:08:06 2013 KojiUpdateCDScomputer problems

It seems that the front fan unit was running at the full speed. The fan itself seems still OK.

I talked with Jamie and make a power cycling (i.e. shutdown gracefully, unplug the power supply cables (x4), plug them in again, and pushed the power button)

The warning signal went off and the fan is quiet. FOR NOW.

Now, daqd and ndsd is down.

FB cannot mount /opt/rtcds and /cvs/cds during its boot.

After mounting these manually, I tried to run /opt/rtcds/caltech/c1/target/fb/start_daqd.inittab and /opt/rtcds/caltech/c1/target/fb/start_nds.inittab
but they don't keep running.

I'll be back to this issue tomorrow with Jamie's help.

  9437   Wed Dec 4 12:02:39 2013 KojiUpdateCDSFB restored

Now FB is fixed: daqd and nds are running


When I rebooted FB, I noticed that any of the nfs file systems were not mounted.
I started tracking down the issues from here.

I googled the common issues of the nfs mounting during the boot sequence.
- It is good to give "_netdev" option to fstab to mount the system after the network connection is established.

- "auto" option specifies that the file system is mounted when mount -a is run

Resulting /etc/fstab is this:

/dev/sdb1                            /            ext3    noatime                    0 1
/swapfile                            none         swap    sw                         0 0
shm                                  /dev/shm     tmpfs   nodev,nosuid,noexec        0 0
/dev/sda1                            /frames      ext3    noatime                    0 0
linux1:/home/cds/                    /cvs/cds     nfs     _netdev,auto,rw,bg,soft    0 0
linux1:/home/cds/rtcds               /opt/rtcds   nfs     _netdev,auto,rw,bg,soft    0 0
linux1:/home/cds/rtapps              /opt/rtapps  nfs     _netdev,auto,rw,bg,soft    0 0
linux1:/home/cds/caltech/apps/linux  /opt/apps    nfs     _netdev,auto,rw,bg,soft    0 0

But this didn't help mounting the nfs file systems at boot yet. I dug into google again and found a command "/sbin/rc-update".
"/sbin/rc-update show" shows what services are activated at boot. It did not include "nfsmount". So the following command
was executed

 

> sudo /sbin/rc-update add nfsmount boot

> /sbin/rc-update show

* Broken runlevel entry: /etc/runlevels/boot/portmap
            bootmisc | boot                         
             checkfs | boot                         
           checkroot | boot                         
               clock | boot                         
         consolefont | boot                         
               dcron |      default                 
               dhcpd |      default                 
            hostname | boot                         
            in.tftpd | boot                         
             keymaps | boot                         
               local |      default nonetwork       
          localmount | boot                         
             modules | boot                         
               monit |      default                 
                  mx |      default                 
            net.eth0 |      default                 
              net.lo | boot                         
            netmount |      default                 
                 nfs | boot                         
            nfsmount | boot                         
          ntp-client | boot default                 
           rmnologin | boot                         
           rpc.statd | boot                         
                sshd | boot                         
           syslog-ng | boot                         
      udev-postmount |      default                 
             urandom | boot                         
              xinetd |      default

After rebooting, I confirmed that the nfs file systems are correctly mounted
and daqd and nds are automatically started.

This means that FB had never been configured to run correctly at boot. Shame on you!

  9441   Wed Dec 4 21:33:24 2013 KojiUpdateCDSc1scy time-over issue mitigated

c1scy had frequent time-over. This caused the glitches of the OSEM damping servos.

Today Eric Q was annoyed by the glitches while he worked on the green PDH inspection at the Y-end.

In order to mitigate this issue, low priority RFM channels are moved from c1scy to c1tst.
The moved channels (see Attachment 1) are supposed to be less susceptible to the additional delay.

This modification required the following models to be modified, recompiled, reinstalled, and restarted
in the listed order:
c1als, c1sus, c1rfn, c1tst, c1scy

Now the models are are running. CDS status is all green.
The time consumption of c1scy is now ~30us (porevious ~60us)
(see Attachment 2)

I am looking at the cavity lock of TEM00 and I have witnessed no glitch any more.
In fact, the OSEM signals have no glitch. (see Attachment 3)

We still have c1mcs having regularly time-over. Can I remove the WFS->OAF connections temporarily?

Attachment 1: TST.png
TST.png
Attachment 2: CDS.png
CDS.png
Attachment 3: no_glitch.png
no_glitch.png
  9449   Fri Dec 6 21:38:27 2013 KojiUpdateLSCCDS related activities for LSC

I worked on the CDS related stuffs for LSC yesterday and today.


1. Slow machines:

I checked the database files for c1iscaux and c1iscaux2 (slow machines). They are mainly
used for the control of LSC whitening filters. The channel names were totally random as we
reconfigured the RF PDs while the channel names had been unchanged.

- Now the database was modified so that the PD name and the channels are related.
- saverestore.req and autoBurt.req were also changed accordingly.

- PD interface channels are completely random. Don't use them.
- I found the whitening of DCPDs are not effective.

- We need to clean up /cvs/cds/caltech/target directory. The autoBurt requests in the old targets
are making unnecessary burt files.

2. LSC screens

- The channel names on the LSC OVERVIEW screen was modified. (Attachment 1)
- A new LSC Whitening screen was made. (Attachment 2)

3. LSC screen generator

To touch the main LSC screen is very tough. The screen was split in to several sub screens
and combined with a command.

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/generateLSCscreen.py

This command combines the multiple adl files into a single file with x&y offsets.
This way, you can work with the each section of the screen.
Also, moving the blocks are just easy.

4. LSC Code Bug?

During the screen making, I found that a couple of the whitening switches are not
working properly.
e.g. When AS165 (either I or Q) FM1 is activated throught the whitening trigger,
the MSB bit (bit15) of the binary I/O (C1:LSC-BIO_0_0) does not .

SImilarly ASDC FM1 does not toggle bit15 of C1:LSC-BIO_0_1.

The other channels seems OK.

At first, I thought this is a bug of "Bit2Word" block. But an individual test of the block showed that
the block is not guilty. So why is only Bit15 malfunctioning???

 

Attachment 1: LSC1.png
LSC1.png
Attachment 2: LSC2.png
LSC2.png
  9450   Sat Dec 7 19:29:14 2013 KojiUpdateCDSMEDM/ADL: replace rectangle with specified objects

In order to unify the theme for MEDM screens, I'll have to make many combinations of rectangles, polygons, and invisible related-screen buttons.
Everytime I change the size of the block, I have to modify the size of this combination. It is impossile for me.

So, I made a script to replace a certain type of rectangles with a combination of the objects with the same (or related) size.

The script is here (so far)

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

So far, there is only "TYPE1" for the predefinition. It actually takes another argument to specify the
path of the related screen to open when the block is clicked. The path should be filled in "Channel B"
slot of the original rectangle. (See Attachment 1)

The "TYPE1" style has the function calls as indicated below. place_rect is to place a rectangle object. You can
specify the filling method and color. place_rel_disp is to place an invisible button with the link to the specified
path by strOpt. place_polygon places a polygon. The cordinate array for the polygon is described with
the relative positions from the specified position.

        place_rect(rect_x-4,         rect_y-4,        rect_w+7, rect_h+7, "outline",  0) # outline white box
        place_rel_disp(rect_x, rect_y, rect_w, rect_h, strOpt, 0, 14)                    # invisible button
        place_rect(rect_x,           rect_y,          rect_w,   rect_h,   "fill",     3) # main gray box
        place_rect(rect_x+3,         rect_y,          rect_w-6, 3,        "fill",     0) # top white rim
        place_rect(rect_x,           rect_y,          3,        rect_h-3, "fill",     0) # left white rim
        place_rect(rect_x+rect_w-3 , rect_y,          3,        rect_h,   "fill",    10) # right gray rim
        place_rect(rect_x,           rect_y+rect_h-3, rect_w-3, 3,        "fill",    10) # bottom gray rim
        place_polygon(rect_x+rect_w-3,rect_y,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # top-right white triangle
        place_polygon(rect_x,rect_y+rect_h-3,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # bottom-left white triangle

Attachment 1: rectangle_config.png
rectangle_config.png
Attachment 2: rect_replace_result.png
rect_replace_result.png
  9453   Tue Dec 10 15:13:55 2013 KojiUpdateIOOIMC servo inspection

Yesterday evening I inspected at IMC servo as a preparation of the CM servo recommissioning.

More details to come.

  9455   Thu Dec 12 00:21:04 2013 KojiUpdateGreen LockingX end PDH box oscillation issue solved (Re: screwed up the end PDH box)

What a such long pain we suffered.

After more than three years from Kiwamu's discovery, the PDH box 50kHz oscillation issue was finally solved.

This "weird peak at 50kHz" was caused by the oscillation of the voltage regulator (ON's MC7912).
As it imposed common noise almost everywhere, it screwed up transfer function measurements
like EricQ saw recently.

The negative voltage regulator (79XX) tends to get unstable than the positive counter parts (78XX).

The oscillation was removed by adding 22uF electrolytic capacitor between the output pin (pin3) and the ground pin (pin1) of MC7912.
This is indeed more than 20 times of the specification you can find in the data sheet.

  9457   Thu Dec 12 14:57:01 2013 KojiUpdateIOOIMC servo inspection

In order to accomplish CARM control with the PSL laser frequency, we use two actuators.

One is the longitudinal direction of one of the MC mirrors. The londitudinal motion of the MC induces
the laser frequency control via the MC servo. As we move the mirror, the range is sort of big,
but the BW is limited by the mechanical response.

The other is the additive offset path. We inject a signal to the additional input port of the MC.
The MC servo supresses this injection by giving the same amount but oppsite sign offset to
the error signal (before the addtion of the inputs). The bandwidth of this AO path is limited
by the bandwidth of the MC servo. Basically the BW of the AO path is about 1/10 of that of the MC servo.

In order to confirm the capability of the AO path as a frequency actuator, 1) OLTF of the MC servo
2) TF of the AO input to the servo error was measured.

Attachment 1 shows the openloop TF of the MC servo. The UGF seems just little bit higher than
100kHz. The OLTF is empirically modelled by LISO as seen in the figure.

Attachment 2 shows the TF from the additive input (In2) to the error monitor (MC Servo module Q error mon).
The gain setting of the MC servo box was: In1 +18dB, In2 0dB. The measured TF has arbitorary gain 
due to the gain setting, the measuemrent data was multiplied by 4 to mach the DC value to the unity.
This is to compare the measurement with the prediction from the OLTF.

The AO path TF is expected to show the character of -G/(1+G) where G is the OLTF. In my case,
G = 0.75*OLTF showed the best maching. There might have been some misalignment of the MC
upon the AO path measurement as I found after the measurement.

From the plot , we can see that the response is flat up to 20kHz. Above that it rapidly raises.
This should be dealt with the CM servo filter as the bump may hit the unity gain. Since we have to use
strong roll off to avoid the bump, this will eat the phase margin at low frequency.

In the case that we don't like this bump:
This bump is caused by low phase mergin of the OLTF at 30~40kHz. If the total gain
is increased, the bump is reduced. Or, we can decrease the PZT loop gain in order to
reduce the dip at the crossover ferquency between the PZT and PC loops. In both cases,
the PC path suffers more actuation. We may need to think about the HV actuation option
for the PC (Apex PA85).

Well, let's see how the CM servo can handle this.
The key point here is that we have enough data to start the design of the CM servo.

Attachment 1: OLTF_IMC.pdf
OLTF_IMC.pdf
Attachment 2: AOTF_IMC.pdf
AOTF_IMC.pdf
Attachment 3: 131209.zip
  9461   Thu Dec 12 22:12:17 2013 KojiUpdateGreen LockingBetter Xarm OLTF

OK, the next question will be "why the loop bandwidth is so miserable?"
In other words, what is preventing us to have the bandwidth of 20~30kHz?
Your breaking down will give us the answer.

  9463   Fri Dec 13 02:30:22 2013 KojiUpdateLSClocking activity

According to the measurement by Eric, the X-arm green PDH UGF is too low. We still have some room to increase the gain.

The out of loop stability of the ALS for each arm should be measured everyday.
Otherwise we can't tell whether the arm is prepared for advanced locking activities or not.

We expect to see the arm stablity of ~50pm_rms for the Y arm and ~150pm_rms for the X arm.

  9466   Fri Dec 13 13:45:50 2013 KojiUpdateCDSMEDM/ADL: replace rectangle with specified objects

rect_replace.py script was updated.
This sounds crazy but it was actually quite easy as I could use a free font data.


/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

Now new type "CHAR" (i.e. REPLACE_CHAR) was added. This replaces the string in Channel B slot
into 5x7 dot matrix representation of the string with the specified color. The dot size is derived from the
height of the original rectangular object.

 

Attachment 1: screen_shot.png
screen_shot.png
  9470   Fri Dec 13 23:07:04 2013 KojiUpdateIOOcommon mode servo

Looks good.

Once the control cable (bakplane cable) is identified, we can install the module to the LSC analog rack.

We should be able to test the CM servo with either POX or POY and only one correspoding arm without modifying the servo TF.
Just for this test, we don't need to use MCL.

ELOG V3.1.3-