40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 128 of 339  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  4196   Mon Jan 24 14:27:13 2011 kiwamuUpdateGreen LockingRe: X arm locked !

Quote: #4193

So, how is the IR error signal stabilized when the IR is brought in to the resonance?

I can see the linear trend of 0.1V/s from 5s to 10s.  This corresponds to 100kHz/s and 13nm for the residual beat drift and the arm length motion, respectively. That sounds huge.

 I haven't yet taken any data for the IR fluctuation when the Xarm is locked by the green locking.

You are right, the DC drift was due to a lack of the DC gain. But don't worry about that, because this issue has been solved.

 


(DC gain issue)

  The lack of DC gain was because I put an IIR filter called ''DC block" that I made. It has 1/f shape below 30mHz and becomes flat above it.

The purpose of this filter was to avoid a DC kick when it starts feeding back to ETMX.

Usually the output signal from the PLL has an offset, typically ~5V, then this offset is also acquired into the ADC and eventually kicks ETMX through the feedback.

So when I took the time series data I enabled the 'DC block', that's why it drifts slowly.

 After taking the time series, I found that without this 'DC block' technique, the lock can be achieved by appropriately subtracting the offsets with epics numerical values.

This subtraction technique, of course, gave me more stable lock at DC.

 


(open loop transfer function)

Here is the open-loop TF of the arm locking I measured last night:

masslock_oltf.png

The IIR filter chain has the following poles and zeros:

     pole 0.1Hz, 1000Hz,

   zero 1Hz, 30Hz

For the fitting I assume that the ETMX pendulum has a resonance at 1Hz with Q of 5. Also I put the cavity pole at 24 kHz, assuming the finesse is 80 at 532 nm.

I just fitted the gain and the time delay by my eyes.

If I believe the result of the fitting, whole time delay is 330 usec, which sounds pretty large to me.

  4197   Tue Jan 25 00:09:54 2011 KojiUpdateGeneralJenne laser is at PSL Lab

I found Tara's elog entry that Jenne laser is at PSL Lab.
Since we recently use it frequently, we should be aware where it is now.

  4198   Tue Jan 25 05:26:51 2011 kiwamuUpdateGreen Lockingcavity scan

cavity_scan.png

I scanned the X arm by changing an offset for the feedback to ETMX while the arm stayed locked by the green locking.

But the resultant plot is still far away from a beautiful one.

Changing the offset broke the lock frequently, so eventually I couldn't measure the stability of the IR-PDH signal at the resonance. 

 

 The plot above is a result of the scanning. You can see there is a clear resonance at the center of the plot.

However the lock frequently became unstable when I was changing the offset.

It looked like this unstability came from the end PDH lock. I guess there are two possible reasons:

  (1)  feedback range for the laser PZT is not wide enough. Right now the range is limited by a SR560, which has been used for a summing amplifier.

  (2)  Length to Alignment coupling. Pushing ETMX causes a misalignment.

The issue (1) can be easily solved by engaging the temperature feedback, which helps actuating the laser frequency a lot at DC.

The issue (2) will be also solved by well align the IR beam, the arm cavity and the green beam.

  4199   Tue Jan 25 06:48:55 2011 kiwamuUpdateGreen LockingTo do list

Here are some tasks that I want someone to work on during my absence.

1. Y-arm alignment for IR

 Basically we gradually have to move onto the Y-arm locking at some point.

Prior to it we need to align the Y arm for IR. Probably we have to touch PZT1 and PZT2.

It would be very nice if the X-arm alignment also gets improved together with this work. 

 

2. Temperature feedback with a digital control for X end PDH lock

  Need a temperature feedback not with an analog way but with a digital way because we want to put an offset and the feedback signal at the same time (#4198).

 Right now the temperature control input of the laser is connected to a slow DAC (#3850).

Probably we should plug the feedback signal from the PDH box to the fast ADC (i.e. c1iscex), and then connect a fast DAC to the laser temperature.

This entry maybe helpful.

 

3. Calibration of optical gain for IR arm locking

 In order to evaluate the performance of the green locking, one of the key points is the IR PDH signal.

Because it tells us how much the motion of the X arm is suppressed at IR when the green lock is engaged.

To get this information in m/sqrtHz, we need to know the optical gain.

 

4. MC servo characterization and PSL frequency noise measurement

 SInce the green beat note tells us the frequency difference between the MC and the arm in the current configuration, we should know how the MC servo is.

Along with this work, I need someone to measure the PSL frequency noise, when it is locked to the MC over the frequency range from 0.01Hz to 1kHz.

 

5. PLL characterization 

 Solve this issue (#4195) and make it reliable.

  4200   Tue Jan 25 15:20:38 2011 josephbUpdateCDSUpdated c1rfm model plus new naming convention for RFM/Dolphin

After sitting down for 5 minutes and thinking about it, I realized the names I had been using for internal RFM communication were pretty bad.  It was because looking at a model didn't let you know where the RFM connection was coming from or going to.  So to correct my previous mistakes, I'm instituting the following naming convention for reflected memory, PCIE reflected memory (dolphin) and shared memory names.  These don't actually get used anywhere but the models, and thus don't show up as channel names anywhere else.  They are replaced by raw hex memory locations in the actual code through the use of the IPC file (/opt/rtcds/caltech/c1/chans/ipc/C1.ipc).  However it will make understanding the models easier for anyone looking at them or modifying them.

 

The new naming convention for RFM and Dolphin channels is as follows.

SITE:Sending Model-Receiving Model_DESCRIPTION_HERE

The description should be unique to that data being transferred and reused if its the same data.  Thus if its transfered to another model, its easy to identify it as the same information.

The model should be the .mdl file name, not the subsystem its a part of.  So SCX is used instead of SUS.  This is to make it easier to track where data is going.

In the unlikely case of multiple models receiving, it should be of the form SITE:Sending Model-Receiving Model 1-Receiving Model 2_DESCRIPTION_HERE.  Seperate models by dashes and description by underscores.

Example:

C1:LSC-RFM_ETMX_LSC

This channel goes from the LSC model (on c1lsc) to the RFM model (on c1sus).  It transfers ETMX LSC position feedback.  The second LSC may seem redundant until we look at the next channel in the chain.

C1:RFM-SCX_ETMX_LSC

This channel goes from the RFM model to the SCX model (on c1iscex). It contains the same information as the first channel, i.e. ETMX LSC position feedback.

 

I have updated all the models that had RFM and SHMEM connections, as well as adding all the LSC communciation connections to c1rfm.  This includes c1sus, c1rfm, c1mcs, c1ioo, c1gcv, c1lsc, c1scx, c1scy.  I have not yet built all the models since I didn't finish the updates until this afternoon.  I will build and test the code tomorrow morning.

 

 

 

  4201   Tue Jan 25 20:42:46 2011 OsamuUpdateGreen LockingSlow servo for green laser

I implemented a slow servo for green laser thermal control on c1scx.mdl. Ch6,7 of ADC and ch6 of DAC are assigned for this servo as below;

 

Ch6 of ADC: PDH error signal

CH7 of ADC: PZT feedback signal

CH6 of DAC: feedback signal to thermal of green laser

 

Note that old EPICS themal control cable is not hooked anymore.

I made a simple MEDM screen(...medm/c1scx/master/C1SCX_BCX_SLOW.adl) linked from GREEN medm screen (C1GCV.adl) on sitemap.

During this work, I noticed that some of the epics switch is not recovered by autoburt. What I noticed is filter switch of SUSPOS, SUSPIT, SUSYAW, SDSEN, and all coil output for ETMX.

I had no idea to fix them, probably Joe knows. I guess other suspensitons has the same problems.

  4202   Tue Jan 25 21:57:59 2011 KojiUpdateGreen LockingSlow servo for green laser

1. The dewhitening filter CH6 had no output. I disconnected the cable and put it to the monitor out of the AI filter.
So the dewhitening is not in the loop.

2. I have made a thermal control filter

BANK1: pole 0Hz, zero 1mHz / LF boost stage
BANK2: pole 1mHz, zero 30mHz / LPF stage
BANK3: pole 1Hz, zero 0.1Hz / phase compensation stage
Gain: 0.05

It seems working with the gain of 0.05. As the thermal is very strong, the output has less than 10.
This means the we are effectively only using ~4bit. We need external filter.

Note that output of 30000counts were about 3V at  CH6.

3. Measured End PZT feedback with and without the thermal control. The UGF seems to be 0.2Hz.
The suppression at 10mHz is ~100. This is so far OK.

Quote:

I implemented a slow servo for green laser thermal control on c1scx.mdl. Ch6,7 of ADC and ch6 of DAC are assigned for this servo as below;

 

Ch6 of ADC: PDH error signal

CH7 of ADC: PZT feedback signal

CH6 of DAC: feedback signal to thermal of green laser

 

Note that old EPICS themal control cable is not hooked anymore.

I made a simple MEDM screen(...medm/c1scx/master/C1SCX_BCX_SLOW.adl) linked from GREEN medm screen (C1GCV.adl) on sitemap.

During this work, I noticed that some of the epics switch is not recovered by autoburt. What I noticed is filter switch of SUSPOS, SUSPIT, SUSYAW, SDSEN, and all coil output for ETMX.

I had no idea to fix them, probably Joe knows. I guess other suspensitons has the same problems.

 

Attachment 1: 110125_Xend_thermal.pdf
110125_Xend_thermal.pdf
  4203   Tue Jan 25 22:49:13 2011 KojiUpdateCDSFront End multiple crash

STATUS:

  • Rebooted c1lsc and c1sus. Restarted fb many times.
  • c1sus seems working.
  • All of the suspensions are damped / Xarm is locked by the green
  • Thermal control for the green is working
  • c1lsc is frozen
  • FB status: c1lsc 0x4000, c1scx/c1scy 0x2bad
  • dataviewer not working

1. DataViewer did not work for the LSC channels (liek TRX)

2. Rebooted LSC. There was no instruction for the reboot on Wiki. But somehow the rebooting automatically launched the processes.

3. However, rebooting LSC stopped C1SUS processes working

4. Rebooted C1SUS. Despite the rebooting description on wiki, none of the FE processes coming up.

5. Probably, I was not enough patient to wait for the completion of dorphine_wait? Rebooted C1SUS again.

6. Yes. That was true. This time I wait for everything going up automatically. Now all of c1pemfe,c1rfmfe,c1mcsfe,c1susfe,c1x02fe are running.
FB status for c1sus processes all green.

7. burtrestored c1pemfe,c1rfmfe,c1mcsfe,c1susfe,c1x02fe with the snapshot on Jan 25 12:07, 2010.

8. All of the OSEM filters are off, and the servo switches are incorrectly on. Pushing many buttons to restore the suspensions.

9. I asked Suresh to restore half of the suspensions.

10. The suspensions were restored and damped. However, c1lsc is still freezed.

11. Rebooting c1lsc freezed the frontends on c1sus. We redid the process No. 5 to No.10

12. c1x04 seems working. c1lsc, however, is still frozen. We decided to leave C1LSC in this state.

 

  4204   Wed Jan 26 02:18:12 2011 KojiUpdateSUSETMX length to angle matrix

I have put an offset of 1000 counts to C1:SUS-ETMX_ALS_OFFSET. This actually misalign the mirror a lot.

While the offset is applied. I adjusted the balance of the coil matrix.
UL 1.580 UR 0.620
LL 0.420 LR 1.380

> ezcaread C1:SUS-ETMX_TO_COIL_0_0_GAIN
C1:SUS-ETMX_TO_COIL_0_0_GAIN = 1.58
> ezcaread C1:SUS-ETMX_TO_COIL_0_1_GAIN
C1:SUS-ETMX_TO_COIL_0_1_GAIN = 0.62
> ezcaread C1:SUS-ETMX_TO_COIL_0_2_GAIN
C1:SUS-ETMX_TO_COIL_0_2_GAIN = 0.42
> ezcaread C1:SUS-ETMX_TO_COIL_0_3_GAIN
C1:SUS-ETMX_TO_COIL_0_3_GAIN = 1.38

Now, we can keep TEM00 for green with +/-1000counts of push although the fast step of the offset make the lock lost.

It turned out that the step longitudinal input temporary misalign the mirror in pitch because the length and pitch are coupled.
I guess that we don't excite pitch if we push the mirror slowly. Eventually, we need f2p transfer function adjusted in the output matrix.

Kiwamu told us that:
(2)  Length to Alignment coupling. Pushing ETMX causes a misalignment.

 

  4205   Wed Jan 26 10:11:47 2011 AidanUpdateGreen Lockingcavity scan

Quote:

cavity_scan.png

 

Whether or not it's as clean as we'd like, it's really nice to see this result with real data.

  4206   Wed Jan 26 10:58:48 2011 josephbUpdateCDSFront End multiple crash

Looking at dmesg on c1lsc, it looks like the model is starting, but then eventually times out due to a long ADC wait. 

[  114.778001] c1lsc: cycle 45 time 23368; adcWait 14; write1 0; write2 0; longest write2 0
[  114.779001] c1lsc: ADC TIMEOUT 0 1717 53 181

I'm not sure what caused the time out, although there about 20 messages indicating a failed time stamp read from c1sus (its sending TRX information to c1lsc via the dolphin connection) before the time out.

Not seeing any other obvious error messages, I killed the dead c1lsc model by typing:

sudo rmmod c1lscfe

I then tried starting just the front end model again by going to the /opt/rtcds/caltech/c1/target/c1lsc/bin/ directory and typing:

sudo insmod c1lscfe.ko

This started up just the FE again (I didn't use the restart script because the EPICs processes were running fine since we had non-white channels).  At the moment, c1lsc is now running and I see green lights and 0x0 for FB0 status  on the C1LSC_GDS_TP screen.

At this point I'm not sure what caused the timeout.  I'll be adding some more trouble shooting steps to the wiki though.  Also, c1scx, c1scy are probably in need of restart to get them properly sync'd to the framebuilder.

I did a quick test on dataviewer and can see LSC channels such as C1:LSC-TRX_IN1, as well other channels on C1SUS such as BS sensors channels.

Quote:

STATUS:

  • Rebooted c1lsc and c1sus. Restarted fb many times.
  • c1sus seems working.
  • All of the suspensions are damped / Xarm is locked by the green
  • Thermal control for the green is working
  • c1lsc is frozen
  • FB status: c1lsc 0x4000, c1scx/c1scy 0x2bad
  • dataviewer not working 

 

  4207   Wed Jan 26 12:03:45 2011 KojiUpdateCDSFront End multiple crash

This is definitely a nice magic to know as the rebooting causes too much hustles.

Also, you and I should spend an hour in the afternoon to add the suspension swtches to the burt requests.

Quote:

I killed the dead c1lsc model by typing:

sudo rmmod c1lscfe

I then tried starting just the front end model again by going to the /opt/rtcds/caltech/c1/target/c1lsc/bin/ directory and typing:

sudo insmod c1lscfe.ko

This started up just the FE again

 

  4208   Wed Jan 26 12:04:31 2011 josephbUpdateCDSExplanation of why c1sus and c1lsc models crash when the other one goes down

So apparently with the current Dolphin drivers, when one of the nodes goes down (say c1lsc), it causes all the other nodes to freeze for up to 20 seconds.

This 20 seconds can force a model to go over the 60 microseconds limit and is sufficiently long enough to force the FE to time out.  Alex and Rolf have been working with the vendors to get this problem fixed, as having all your front ends go down because you rebooted a single computer is bad.

[40184.120912] c1rfm: sync error my=0x3a6b2d5d00000000 remote=0x0
[40184.120914] c1rfm: sync error my=0x3a6b2d5d00000000 remote=0x0
[44472.627831] c1pem: ADC TIMEOUT 0 7718 38 7782
[44472.627835] c1mcs: ADC TIMEOUT 0 7718 38 7782
[44472.627849] c1sus: ADC TIMEOUT 0 7718 38 7782
[44472.644677] c1rfm: cycle 1945 time 17872; adcWait 15; write1 0; write2 0; longest write2 0
[44472.644682] c1x02: cycle 7782 time 17849; adcWait 12; write1 0; write2 0; longest write2 0
[44472.646898] c1rfm: ADC TIMEOUT 0 8133 5 7941

The solution for the moment is to start the computers at exactly the same time, so the dolphin is up before the front ends, or start the models by hand after the computer is up and dolphin running, but after they have timed out.  This is done by:

sudo rmmod c1SYSfe

sudo insmod /opt/rtcds/caltech/c1/target/c1SYS/bin/c1SYSfe.ko

 

Alex and Rolf have been working with the vendors to get this fixed, and we may simply need to update our Dolphin drivers.  I'm trying to get in contact with them and see if this is the case.

  4209   Wed Jan 26 14:49:48 2011 AidanUpdateEnvironmentTurned on Control room AC

80 degrees is too uncomfortable in the control room so I turned on the AC. The set point is 74F.

  4210   Thu Jan 27 03:24:56 2011 KevinUpdateElectronicsPOY Optical Transfer Function

[Rana and Kevin]

I measured the optical transfer function of POY and fit the data using LISO. The fit can be found at http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/POY. POY was missing the RF cage and back cover so I took those parts from AS55 in order to make these measurements.

POY does not have the unwanted oscillations at 225 MHz that POX has. Attachment 1 shows the transfer functions of POX and POY.

To measure the transfer functions, I used a 50/50 beam splitter to send half the light from an AM laser to POY and half the light to a New Focus 1611 reference photodiode. The transfer function for POY was measured as the transfer function of the signal from POY divided by the signal from the 1611. When I was measuring the transfer function for POX, I failed to ensure that the photodiodes were operating linearly. Before making the measurements for POY, I varied the RF power modulating the AM laser and recorded the magnitude of the transfer function at the 11 MHz peak. Attachment 2 shows these values. The measurements for POY were made in the linear region at an RF power of -10 dBm. The measurements for POX were made at 0 dBm and were most likely not in the linear region for POX.

Attachment 1: tf_pox_poy.png
tf_pox_poy.png
Attachment 2: linearity.png
linearity.png
  4211   Thu Jan 27 11:04:27 2011 KojiUpdateGreen Lockingbeat freq scan

Experiment in the night of Jan 26.

o The arm was locked for the IR beam and was aligned for it.
o The green was aligned to the arm
o The beat freq was observed with the RF analyzer and the webcam.
o Engaged the ALS servo
o Compared the fluctuation of the beat freq with and without ALS
o Scanned the beat freq in order to find an IR resonance

The beat freq was scanned. A resonance for IR was found.
However, the residual motion of the arm was not within the line width of the IR resonance.

 To Do
- Improve the ALS servo (==>Koji)
- VCO noise characterization (==>Suresh is on it)
- Calibrate the PLL feedback (i.e. ALS error) into Hz/rtHz (==>Suresh)
- Calibrate the end green PZT fb into Hz/rtHz (==>Osamu is on it)
- Tuning of the suspension filters to reduce the bounce mode coupling.


DETAILS

o How to lock the arm with IR

  • Coarsely align the arm without lock. Transmittion was ~300 with MCTRANS ~40000
  • REFL11I is the error signal. unWhiten filter (FM1) should be on.
  • Unlock the MC and null the error and the arm trans offset by running the following commands

ezcaservo -g -0.1 -r C1:LSC-REFL11_I_OUTPUT C1:LSC-REFL11_I_OFFSET
ezcaservo -g -0.1 -r C1:LSC-REFL11_Q_OUTPUT C1:LSC-REFL11_Q_OFFSET
ezcaservo -g 0.1 -r C1:LSC-TRX_OUTPUT C1:LSC-TRX_OFFSET

  • Confirm the input matrix to pass REFL11I to MC path (why don't we use XARM path...?)

ezcawrite C1:LSC-MTRX_81 1.0

  • Servo configuration
    • For acquisition: Gain of 2. Only FM1 (1000:10) has to be on.
    • After the acquisition (TRX>200): The gain is to be changed to 1. FM2 and FM3 can be turned on for the LF boost.
  • Actuator matrix: connect MC path to ETMX and MC2

ezcawrite C1:LSC-OM_MTRX_18 1.0
ezcawrite C1:LSC-OM_MTRX_78 1.0

 

o How to align the green beam

  • After the alignment I went the end and aligned the last two steering mirrors.


o The beat freq monitor

  • Put the RF analyzer at the RF splitter of the RFPD output.
  • Used Zonet webcam (http://192.168.113.201:3037) for the remote monitoring

 

o How to engage the ALS servo

  • Preparation:
    • VCO PLL feedback comes to X_FINE path.
    • Put an offset of -850 to cancel too big offset (when the VCO is unlocked)
    • Use Y_FINE channel for the offset addtion. FM1 is 10mHz LPF in order to make the offset smooth.
    • Add X_FINE and Y_FINE by the matrix.
  • Control
    • Turn off X_FINE out. Leave Y_FINE output turned on.
    • Turn on ETMX ALS path.
    • Servo setting: FM1 1000:30 ON, others OFF, gain1
    • Wait for the beat comes in to the locking range at around 80MHz.
    • If the peak is too far, sweep Y_FINE offset in order to . Or change GCV slow thermal offset to let the beat freq jump.
    • You may have ambiguity of the feedback sign depending on which green has higher freq.
    • After the capture of the ALS lock, increse the gain up to 20. Turn on 0.1:boost at FM3.

 

o Comparison of the stability of the beat freq (Attachment3)

  • The spectra of the VCO PLL feedback was measured.
  • First of all, the signal was measured without ALS (blue).
    The PLL lost lock quite frequently, so the careful adjustment of the offset was necessary.Still I think there was slight saturation upconversion.
  • Then, the ALS was turned on (red). The gain was 20. This is an in-loop evaluation of the servo. The suppression was ~1000 at 1Hz.

o Beat freq scanning

  • The following command was used for the beat note scanning 

ezcastep -- "C1:GCV-YARM_FINE_OFFSET" "5,500"

  • Once the IR transmission was found, the scan was stopped.
  • Because the resultant rms stability of the arm was not within the line width of the cavity, the smooth resonant curve was not obtained.
  • From the shape of the error signal the peak-to-peak displacement (f>1Hz) was estimated to be +/-0.7nm. The dominant displacement
    in the period is 16Hz component.

 

Attachment 1: arm_scan.pdf
arm_scan.pdf
Attachment 2: arm_cav_scan3.png
arm_cav_scan3.png
Attachment 3: 110126_ALS_inloop.pdf
110126_ALS_inloop.pdf
  4212   Thu Jan 27 15:16:43 2011 josephbUpdateCDSUpdated generate_master_screens.py

I modified the generate_master_screens.py script in /opt/rtcds/caltech/c1/medm/master/ to handle changing the MCL (and MC_L) listings to ALS for the two ETM suspension screens and associated sub-screens.

The relevant added code is:

custom_optic_channels = ['ETMX',
{'MCL':'ALS','MC_L':'ALS'},
'ETMY',
{'MCL':'ALS','MC_L':'ALS'}]

 

for index in range(len(custom_optic_channels)/2):
   if optic == custom_optic_channels[index*2]:
     for swap in custom_optic_channels[index*2+1]:
       sed_command = start_sed_string + swap + "/" + custom_optic_channels[index*2+1][swap] + middle_sed_string + optic + file
       os.system(sed_command)

When run, it generates the correctly named C1:SUS-ETMX_ALS channels, and replaces MCL and MC_L with ALS in the matrix screens.

 

  4214   Thu Jan 27 21:10:47 2011 OsamuUpdate40m UpgradingCalibrated noise of green

I calibrated noise spectrum of green lock.

1. Measurement of conversion factor of ADC input from V to ct:

As a preparation, first I measured a conversion factor at ADC input of C1;GCX1SLOW_SERVO1.

It was measured while the output of AI ch6 as the output of C1;GCX1SLOW_SERVO2 with 1Hz, 1000ct(2000ct_pp) was directly connected into AA ch7 as the input of C1;GCX1SLOW_SERVO1. Amplitude at the output at AI ch6 was 616mVpp measured by oscilloscope, and C1;GCX1SLOW_SERVO1_IN1 read as 971.9ct_pp. So the conversion factor is calculated as 6.338e-4[V/ct].

2. Injection of a calibration signal:

When Green laser was locked to cavity with fast PZT and slow thermal, I injected 100Hz, 1000ct EXC at ETMX ASL. The signal was measured at C1:GCX1SLOW_SERVO1_IN1 as 5.314ct_rms. It can be converted into 3.368e-3Vrms using above result, and then converted into 3368Hz_rms using PZT efficiency as 1MHz/V. This efficiency was obtained from Koji's knowledge, but he says that it might have 30% or higher error. If somebody get more accurate value, put it into the conversion process from V to Hz here.

3. Conversion;

Frequency of green f=c/532nm=5.635e14[Hz] is fluctuating with above 3368Hz_rms,so the fluctuation ratio is 3368/5.635=5.977e-12, and it corresponds to length fluctuation of 37.5m. So, cavity fluctuation will be 5.977e-12*37.5=2.241e-10m_rms by 100Hz, 1000ct EXC at ETMX ASL.

4. Results;

Finally, we knew 5.314ct corresponds to 3368Hz and 2.241e-10m, so conversion factor from ct to Hz and ct to m are ;

633.8[Hz/ct] @ C1:GCX1SLOW_SERVO1

4.217e-11[m/ct] @ C1:GCX1SLOW_SERVO1

 

5. Calibration:

You can measure green noise spectrum at C1;GCX1SLOW_SERVO1_IN1 during lock,  and mutiply above result to convert Hz or m.

This calibration is effective above corner frequency of slow and fast servo around 0.5Hz and UGF of fast servo around 4kHz.

I show an example of calibrated green noise.

20110127_Calibrated_grrennoise.jpg

20110127_Calibrated_grrennoise.pdf

Each color show different band-width. Of course this results of calibration cactor does not depend on band-width. Noise around 1.2Hz is 6e-8Hz/rHz. It sounds a bit too good by factor ~2. The VCO efficiency might be too small.

 

Note that there are several assumptions in this calibration;

1. TF from actual PZT voltage to PZT mon is assumed to be 1 in all frequency. Probably this is not a bad assumption because circuit diagram shows monitor point is extracted PZT voltage directly.

2. However above assumption is not correct if the input impedance of AI is low.

3. As I said, PZT efficiency of 1MHz/V might be wrong.

 

I also measured a TF from C1:SUS-ETMX_ALS_EXC to C1:GCX1SLOW_SERVO1_IN1. It is similar as calibration injection above but for wide frequency. This shows a clear line of f^-2 of suspension.

20110127_TF_ETMXSUSEXC_to_PZTOUT.pdf

 

Files are located in /users/osamu/:20110127_Green_calibration.

  4215   Thu Jan 27 21:43:37 2011 KojiUpdateGreen Lockingno transmission of ALS signals

No signal is transmitted from C1:GCV-SCX_ETMX_ALS (on c1gcv) to C1:GCV-SCX_ETMX_ALS (on c1scx)

I can't find RFM definition for ALS channels in c1rfm. Where are they???

  4219   Fri Jan 28 11:08:44 2011 josephbUpdateGreen Lockingno transmission of ALS signals

As you've correctly noted, the source of the C1:GCV-SCX_ETMX_ALS channels is in the c1gcv model. The first 3 letters of the channel name indicate this (GCV).

The destination of this channel is c1scx, the 2nd 3 letters indicate this (SCX). If it passed through the c1rfm model, it would be written like C1:GCV-RFM_ETMX_ALS.

This particular channel doesn't pass through the c1rfm model, because the computers these two run on (c1ioo and c1scx) are directly connected via our old VMIC 5565 RFM cards, and don't need to pass through the c1sus computer. This is in contrast to all communications going to or from the c1lsc machine, since that is only connected the c1sus machine by the Dolphin RFM. The c1rfm also handles a bunch of RFM reads from the mode cleaner WFS, since each eats up 3-4 microseconds and I didn't want to slow the c1mcs model by 24 microseconds (and ~50 microseconds before the c1sus/c1scx computer switch).

So basically c1rfm is only used for LSC communications and for some RFM reads for local suspensions on c1sus.

As for the reason we have no transmission, that looks to be a problem on c1ioo's end. I'm also noticing that MCL is not updating on the MC2 suspension screen as well as no changes to MC PIT and YAW channels, which suggests we're not transmitting properly.

I rebooted the c1ioo machine and then did a burt restore of the c1ioo and c1gcv models. These are now up and running, and I'm seeing both MCL and ALS data being transmitted now.

Its possible that when we were working on the c1gfd (green frequency divider model) on c1ioo machine we disturbed the RFM communication somehow. Although what exactly, I'm not sure.

Quote:

No signal is transmitted from C1:GCV-SCX_ETMX_ALS (on c1gcv) to C1:GCV-SCX_ETMX_ALS (on c1scx)

I can't find RFM definition for ALS channels in c1rfm. Where are they???

 

  4220   Fri Jan 28 12:15:58 2011 josephbUpdateCDSUpdating conlog channel list/ working on "HealthCheck" script

I've updated the scan_adls script (currently located in /cvs/cds/caltech/conlog/bin) to look at new location of our medm screens.  I made a backup of the old conlog channel list as /cvs/cds/caltech/conlog/data/conlog_channels.old-2011-01-28.

I then ran the update_chanlist script in the same directory, which calls the scan_adl script.  After about 5 minutes it finished updating the channel list.  I restarted the conlogger just to be sure, and checked that our new model channels showed up in the conlog (which they do).

I have added a cron job to the op340m cron tab to once a day run the update_conlog script at 7am.

Next, I'm working on a HealthCheck script which looks at the conlog channel list and checks to see if channels are actually changing over short time scales, and then spit back a report on possibly non-functioning channels to the user.

  4222   Fri Jan 28 13:07:31 2011 JenneUpdateIOOBeam is back on the WFS

The MC WFS have had beam dumps in front of them for the past ~2 weeks, until I could find the appropriate optic to put in the WFS path, to avoid melting the WFS' electronics. 

Koji noted that Steve had a W2-45S in a secret stash near his desk (which Steve later had put into the regular optics storage shelves down the Yarm), so I used that in front of the black hole beam dump on the AS table.  Now the beam is ~1W reflected from the unlocked mode cleaner, and ~100mW goes to the MC REFL PD.  The other 900mW now goes to this W2, and only ~5mW is reflected toward the MC WFS.  Most of the 900mW is transmitted through the window and dumped in the black hole.  There is a ghost beam which is reflected off the back surface of the wedged window, and I have blocked this beam using a black anodized aluminum dump.  I will likely change this to a razor dump if space on the table allows.  I have aligned the beam onto WFS1 and WFS2, although I did not re-align the mode cleaner first, so this alignment of the WFS will likely need to be redone. 

WFS1 has about 2mW incident, and WFS2 has about 3mW incident, when the mode cleaner is unlocked.  I have not yet measured the power incident when the MC is locked, although obviously it will be much smaller.

Except that I might temporarily remove one of the WFS for more quantum efficiency measurements later today, the WFS should be ready to turn back on for alignment stabilization of the mode cleaner. 

Quote:

My goal this afternoon was to measure the quantum efficiency of the MC WFS.  In the process of doing this, I discovered that when I reverted a change in the MCWFS path (see elog 4107 re: this change), I had not checked the max power going to the WFS when the MC unlocks.

Current status:

MC locks (is locked now).  No light going to WFS at all (to prevent MC WFS french-fry action).  Quantum Efficiency measured.

The Full Story:

Power to WFS:

Rana asked me to check out the quantum efficiency of the WFS, so that we can consider using them for aLIGO.  This involves measuring the power incident on the PDs, and while doing so, I noticed that WFS1 had ~160mW incident and WFS2 had ~240mW incident while the mode cleaner was unlocked.  This is bad, since they should have a max of ~10mW ever.  Not that 200mW is going to destroy the PD immediately, but rather the current out, with the 100V bias that the WFS have, is a truckload of power, and the WFS were in fact getting pretty warm to the touch.  Not so good, if things start melting / failing due to extended exposure to too much heat.

The reason so much power was going to the WFS is that it looks like Yuta/Koji et. al., when trying to use the WFS as a MC1 oplev, changed out 2 of the beam splitters in the MC WFS / MC Refl path, not just one.  Or, we've just been crispy-frying our WFS for a long time.  Who knows?  If it is option A, then it wasn't elogged.  The elog 3878 re: BS changeout only mentions the change of one BS.

Since the MC Refl path has a little more than ~1W of power when the MC is unlocked, and the first BS (which was reverted in elog 4107) is a 10% reflector, so ~100mW goes to the MC Refl PD, and ~900mW goes to the MC WFS path.  In front of a Black Hole beam dump was sitting a BS1-33, so we were getting ~300mW reflected to be split between the 2 WFS, and ~600mW dumped.  The new plan is to put a W2 window in place of this BS1-33, so that we get hopefully something like 0.1% reflected toward the WFS, and everything else will be dumped.  I could not find a W2-45S (everything else is S, so this needs to be S as well).  I found a bunch of W2-0deg, and a few W2-45P.  Does anyone have a secret stash of W2-45S's???  To avoid any more excessive heat just in case, for tonight, I have just left out this mirror entirely, so the whole MC WFS beam is dumped in the Black Hole.  The WFS also have aluminum beam dumps in front of them to prevent light going in.  None of this affects the MC Refl path, so the MC can still lock nice and happily.

 

  4224   Fri Jan 28 18:19:21 2011 JenneUpdateIOOWFS2 has some kind of oil on it

Mystery solved!

I removed WFS2 from the AP table (after placing markers so I can put it back in ~the same place) so that I could take some reflectivity as a function of angle measurements for aLIGO WFS design stuff.

I was dismayed to discover, upon glancing at the diode itself, that half of the diode is covered with some kind of oil!!!.  The oil is mostly confined to quadrants 3 and 4, which explains the confusion with their quantum efficiency measurements, as well as why the readback values on the MEDM WFS Head screen for WFS2 don't really make sense. 

The WFS QPD has a piece of glass protecting the diode itself, and the oil seems to be on top of the glass, so I'm going to use some lens tissue and clean it off.

Pre-cleaning photos are on Picasa.

Update:  I tried scrubbing the glass with a Q-tip soaked with Iso, and then one soaked in methanol.  Both of these failed to make any improvement.  I am suspicious that perhaps whatever it is, is underneath the glass, but I don't know.  Rana suggested replacing the diode, if we have spares / when we order some spares.

Oily_WFS2.jpg

Quote:

Problem with 2 quadrants of WFS2?

While doing all of this, I noticed that quadrants 3 and 4 of WFS2 seem to be different than all the rest.  You can see this on the MEDM screens in that all 6 other quadrants, when there is no light, read about -0.2, whereas the 2 funny quadrants read positive values.  This might be okay, because they both respond to light, in some kind of proportion to the amount of light on them.  I ended up getting QE of ~72% for both of these quadrants, which doesn't make a whole lot of sense since the spec for green is 70%, and silicon is supposed to be less good for infrared than green.  Anyhow, we'll have to meditate on this.  We should also see if we have a trend, to check how long they have been funny.

 

  4225   Sat Jan 29 00:31:05 2011 SureshUpdateGeneralVertex crane upgrade completed

The Vertex crane is smarter and safer now.  This upgrade ensures that the two sections of I-beam (8ft, 4ft) remain firmly latched to form a straight member till the latch is released.

In specific, it ensures that problems such as this one do not occur in the future.

 

The new safety features are:

When the I-beam sections are latched together, a pneumatic piston ensures that the latch is secure. 

If the latch is not engaged the trolley does not move outward beyond the end of the 8-foot section of the I beam.

If the trolley is out on the 4-foot section of the beam then we cannot disengage the latch.

 

How does it work?

 

 Vertex_Crane-2.png Vertex_Crane-4.png

 

The state of the Limit Switch 1 changes when the trolly goes past it.    The Limit Switch 2 gets pressed when the two sections are latched together.

The pneumatic piston raises or lowers the latch.  The Pneumatic Latch Switch operates a pneumatic valve controlling the state of the piston.

 

 

Vertex_Crane-3.png P1280545.JPG

The new controller now has Pneumatic Latch Switch in addition to the usual Start, Stop, Up, Down, In and Out buttons. 

Each of the Up, Down, In and Out buttons have two operational states:  Half pressed (low speed) and Full pressed (High Speed).  Their functions remain the same as before.

 

The new Pneumatic Switch:

When this switch is 'Engaged' and the 4 ft section is swung in-line with the 8 ft section, the two sections get latched together.

To unlatch them we have to throw the switch into the 'Disengage' state.  This makes the piston push the latch open and a spring rotates the 4 ft section about its pivot.

Limit Switch 2 is not pressed (I-beams not aligned straight) ==> Limit Switch 1 will prevent the trolley from out going beyond the 8 ft section.

While Limit Switch 2 is pressed we cannot disengage the latch.

 

Note: 

   The pneumatic piston requires 80psi of pressure to operate.  However we have only 40psi in the lab and the piston seems to operate quite well at this pressure as well.  I believe a request has been made to get an 80psi line laid just for this application.

 

Attachment 1: Vertex_Crane-2.png
Vertex_Crane-2.png
Attachment 2: Vertex_Crane-4.png
Vertex_Crane-4.png
  4226   Sat Jan 29 03:13:44 2011 ranaUpdateWienerFilteringImprovement in H1 Wiener FF prediction by using weights and taps

(Jenne, Rana)

Tonight we noticed that there were significant improvements to be had in the predicted DARM Wiener filtering FF performance by using weighting filters and more taps in the FIR filter.

The plots below tell the story:

The first one shows the improvement in the residual (black & blue) by applying a weighting filter. The weight filter tilts the spectrum up at HF and applies and all real pole BP from 10-20 Hz.

The second plot shows the improvement gotten by using 3000 instead of 2000 taps for the Wiener filter. With the larger number of taps we not only get the big improvement at LF, but also some beefy reduction in the higher frequency stack modes and the LOS roll mode.

I'm not sure why we haven't run across this before; the weighting filter was arrived at today by just iterating by hand on the placement of poles and zeros until the trace looked nice.

Jenne is going to run this new filter on the S5-month that we have been using for stationarity testing.

* Some notes:

** this Wiener stuff is faster, by far, on rossa than either megatron or rosalba or my laptop. More than a factor of 3.

*** there is a bug with Macports/Matlab - if you get fftw3 with Macports, it sets itself as the right version to use. This confuses matlab in some cases.

     if you get the error about libfftw3.dylib, whe trying fft in matlab after installing macports, then you can fix it by setting the Matlab lib/ path with the fftw libraries to be ahead of /opt/local/lib in the LD_LIBRARY_PATH in your .cshrc.

Attachment 1: darmweight.png
darmweight.png
Attachment 2: darm3000.png
darm3000.png
  4230   Mon Jan 31 07:41:23 2011 AidanUpdateGreen LockingDFD - medm screen

I added an MEDM screen for the DFD to the GREEN screen. It is displayed in the attached screen shot.

This screen is located in: /cvs/cds/rtcds/caltech/c1/medm/c1gfd/C1GFD_DFD.adl

Attachment 1: Screenshot-3.png
Screenshot-3.png
  4231   Mon Jan 31 10:31:30 2011 josephbUpdateWienerFilteringImprovement in H1 Wiener FF prediction by using weights and taps

Rossa is a rather beefy machine. It effectively has 8 Intel i7 Cores (2.67 Ghz each) and 12 Gigs of ram.  Megatron only has 8 Gigs of ram and just 8 Opterons (1 GHz each).  Rosalba has 4 Quad Core2  (2.4 GHz) with only 4 Gigs of ram. 

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM The Dolphins Sim.Plant Frame builder TDS
                       
  4232   Mon Jan 31 12:40:38 2011 rana, joeUpdateGreen LockingDFD - medm screen

This is a plot showing the old filters and the new ones we added this morning.

The new ones have a Cheby for AC coupling below 10 Hz and then a 500 Hz LP after the mixer. The LP frequency has been increased so that we can use this signal in a feedback loop to the ETM with a ~100 Hz UGF.

Attachment 1: a.pdf
a.pdf
  4233   Mon Jan 31 16:12:11 2011 steveUpdateVACVertex crane upgrade shorth coming

 The upgrade is almost finished. I found that the passive latch lock  is not closing down all the way. It has about a 3/8" gap.    See Atm. 1 & 2

The service man was here this morning and agreed to fix it.  They will be back next week. The latch needs an other spring to push it into full lock. 

We tested all possible sequences of operation of the new upgrade. It performed to specification.

 

 

Quote:

 

Attachment 1: P1070364.JPG
P1070364.JPG
Attachment 2: P1070358.JPG
P1070358.JPG
  4234   Mon Jan 31 18:25:25 2011 AidanUpdateGreen LockingDFD - results from the new filters (and running with AWG)

Quote:

This is a plot showing the old filters and the new ones we added this morning.

The new ones have a Cheby for AC coupling below 10 Hz and then a 500 Hz LP after the mixer. The LP frequency has been increased so that we can use this signal in a feedback loop to the ETM with a ~100 Hz UGF.

Joe injected a 234.567 etc. Hz sine wave into the excitation channel in the DFD INPUT filter. The spectrum of the output of the LP filter with the new filter is shown below with the RMS calculated from 300Hz down to 1mHz - see first attachment. The RMS is equal to about 2.5Hz. (Incidentally, the RMS is very much higher (slightly less than 400Hz - see second attachment) if you calculate it from 7kHz down to 1mHz). 

Attachment 1: DFD-bandwidth_noise_CLP500_to_300Hz.pdf
DFD-bandwidth_noise_CLP500_to_300Hz.pdf
Attachment 2: DFD-bandwidth_noise_CLP500_to_7000kHz.pdf
DFD-bandwidth_noise_CLP500_to_7000kHz.pdf
  4236   Tue Feb 1 17:34:21 2011 JenneUpdateSUSETMX and PRM watchdogs tripped

I sat down in the control room to find that ETMX and PRM's watchdogs had been tripped.  I don't know how long they've been crazy, but there was a big something that showed up in the seismometers around 16:30UTC, or ~11:30 this morning.  I don't find any significant earthquakes on the USGS site for that time though, so it might be more local, i.e. work next door or trucks or whatever.

I take back the suggestion that it was that seismic event.  Clearly the PRM and the ETMX were kicked at different times, neither of which is the same as the seismic action. Mystery.  You can see they have been ringing down for a while though, which is neat. 

Attachment 1: Seis_1Feb2011.png
Seis_1Feb2011.png
Attachment 2: Seis_SUS_1Feb2011.png
Seis_SUS_1Feb2011.png
  4241   Wed Feb 2 15:07:20 2011 josephbUpdateCDSactivateDAQ.py now includes PEM channels

[Joe, Jenne]

We modified the activateDAQ.py script to handle the C1PEM.ini file (defining the PEM channels being recorded by the frame builder) in addition to all the optics channels.  Jenne will be modifying it further so as to rename more channels.

  4242   Thu Feb 3 01:46:54 2011 KevinUpdateElectronicsPOY Shot Noise and Dark Spectrum

[Koji and Kevin]

I measured the shot noise of POY and fit the data to determine the RF transimpedance at 11 MHz and the dark current. The transimpedance is (3.860 +- 0.006) kΩ. I realize that there are not many data points past the dark current but I did not want to take any further data because the light bulb was getting pretty bright. If this is a problem, I can try to redo the measurement using a lens to try to focus more of the light from the bulb onto the photodiode.

I also measured the spectrum and recorded a time series of the RF signal with the light to the photodiode blocked. These measurements do not show any large oscillations like the ones found for POX.

The plots of the measurements are on the wiki at http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/POY.

  4243   Thu Feb 3 04:43:58 2011 SureshUpdateElectronicsAdded two new DAQ channels

[Suresh, Joe]

We added the following two new DAQ channels into the c1:GCV model.  The daq:analog input channels are on card ADC0 and correspond to channels 3 and 4 on the card.

c1:GCV-EXT_REF_OUT_DAQ   Sampling rate=2kHz  acquiring a 1Hz sine wave from the SRS Function Generator DS345.  This is using the Rb 10MHz signal as an external frequency reference.

c1:GCV-PLL_OUT_DAQ    Sa.rate=2kHz acquiring the demodulated signal from the PLL servo.

This work is connected to the study of VCO PLL loop noise at frequencies below 0.1Hz.    We are trying to measure phase noise in the VCO PLL servo at low frequencies as this noise would result in arm length fluctuations in the green-locking scheme.

 

 

 

  4244   Thu Feb 3 11:13:52 2011 KojiUpdateElectronicsPOY Shot Noise and Dark Spectrum

I wonder why POY11 has the dark noise level of 90nV/rtHz that is 5 times larger than that of POX (18nV/rtHz)
even though the Q are the same (~15) and the transimpedance is better (3.9k instead of 2k).

What cause this high noise level?
What is the expected dark noise level?

Quote:

[Koji and Kevin]

I measured the shot noise of POY and fit the data to determine the RF transimpedance at 11 MHz and the dark current. The transimpedance is (3.860 +- 0.006) kΩ. I realize that there are not many data points past the dark current but I did not want to take any further data because the light bulb was getting pretty bright. If this is a problem, I can try to redo the measurement using a lens to try to focus more of the light from the bulb onto the photodiode.

I also measured the spectrum and recorded a time series of the RF signal with the light to the photodiode blocked. These measurements do not show any large oscillations like the ones found for POX.

The plots of the measurements are on the wiki at http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/POY.

 

  4245   Thu Feb 3 16:08:06 2011 AidanUpdateComputer Scripts / ProgramsRCG VCO frequency error

Joe and I were looking at the RCG VCO algorithm to determine if we could adapt it to run at a faster rate (you can currently change its frequency at 1Hz). I noticed that the algorithm that is used to calculated the values of sine and cosine at time T1  is a truncated Taylor series which uses the values of sine and cosine calculated at time T1 - Delta t . I was concerned that there would be an accumulating phase error so I tested the algorithm in MATLAB and compared it to a proper calculation of sine and cosine. It turns out that at a given 'requested' frequency there is a constantly accumulating phase error - which means that the 'actual' frequency of the RCG VCO is incorrect. So I have plotted the frequency error vs requested VCO frequency. It gets pretty bad!

 Here's the code I used:

dt = 1/16384;

diffList = [];
% set the frequencies

flist = 1:5:8192;
for f = flist;
   
    % get the 'accurate' values of sine and cosine
    tmax = 0.05;
    time1 = dt:dt:tmax;
    sineT = sin(2.0*pi*f*time1);
    cosineT = cos(2.0*pi*f*time1);
   
    % determine the phase change per cycle
    dphi = f*dt*2*pi;
    cosT1 = 1:numel(time1);
    sinT1 = 0*(1:numel(time1));
   
    % use the RCG VCO algorithm to determine the values of sine and cosine
    for ii = 1:numel(time1) - 1;                 
        cosNew = cosT1(ii)*(1 - 0.5*dphi^2) ...
                      - (dphi)*sinT1(ii);
        sinNew = sinT1(ii)*(1 - 0.5*dphi^2) ...
                      + (dphi)*cosT1(ii);
                 
       
        cosT1(ii+1) = [ cosNew];
        sinT1(ii+1) = [ sinNew];
       
    end
    % extract the phase from the VCO values of sine and cosine
    phaseT = unwrap(angle(cosineT + i* sineT));
    phaseT1 = unwrap(angle((cosT1 + i*sinT1)));
   
    % determine the phase error for 1 cycle
    diff = phaseT1 - phaseT;
    % determine the frequency error
    slope = (diff(2) - diff(1))/(dt);
   
    diffList = [diffList, slope];
    disp(f)
    pause(0.001)
end

% plot the results

close all
figure
orient landscape
loglog(flist, abs(diffList/(2.0*pi)))
xlabel('Requested VCO Frequency (Hz)')
ylabel('Frequency error (Hz)')
grid on

print('-dpdf', '/users/abrooks/VCO_error.pdf')

Attachment 1: VCO_error.pdf
VCO_error.pdf
  4246   Thu Feb 3 16:45:28 2011 josephbUpdateCDSGeneral CDS updates

Updated the FILTER.adl file to have the yellow button moved up, and replaced the symbol in the upper right with a white A with black background.  I made a backup of the filter file called FILTER_BAK.adl.  These are located in /opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/util.

I also modified the Makefile in /opt/rtcds/caltech/c1/core/advLigoRTS/ to make the startc1SYS scripts it makes take in an argument.  If you type in:

sudo startc1SYS 1

it automatically writes 1 to the BURT RESTORE channel so you don't have to open the GDS_TP screen and by hand put a 1 in the box before the model times out.

The scripts also points to the correct burtwb and burtrb files so it should stop complaining about not finding them when running the scripts, and actually puts a time stamped burt snapshot in the /tmp directory when the kill or start scripts are run.  The Makefile was also backed up to Makefile_bak.

 

  4247   Thu Feb 3 17:25:03 2011 josephbUpdateComputersrsync script was not really backing up /cvs/cds

So today, after an "rm" error while working with the autoburt.pl script and burt restores in general, I asked Dan Kozak how to actually look at the backup data.  He said there's no way to actually look at it at the moment.  You can reverse the rsync command or ask him to grab the data/file if you know what you want.  However, in the course of this, we realized there was no /cvs/cds data backup.

Turns out, the rsync command line in the script had a "-n" option.  This means do a dry run.  Everything *but* the actual final copying.

I have removed the -n from the script and started it on nodus, so we're backing up as of 5:22pm today.

I'm thinking we should have a better way of viewing the backup data, so I may ask Dan and Stewart about a better setup where we can login and actually look at the backed up files.

In addition, tomorrow I'm planning to add cron jobs which will put changes to files in the /chans and /scripts directories into the SVN on a daily basis, since the backup procedure doesn't really provide a history for those, just a 1 day back backup.

  4248   Fri Feb 4 11:10:27 2011 SureshUpdateGreen LockingVCO PLL Frequency noise

This measurement pertains to the BL2002 VCO PLL unit.

 

Our goal is to measure the frequency fluctuations introduced by the VCO. 

 

First the VCO calibration was checked.  It is -1.75 MHz per volt.  The calibration data is below:

VCO_calibration.png

 

 

 

Next we measured the Transfer function between points A and B  in the diagram below using the Stanford Research System's SR785.  This measurement was done with loop opened just after the 1.9MHz LPF and with the loop closed.

VCO_PLL_Servo.png

 

The TF[open] / TF [closed ] gave the total gain in the loop.  As shown below:

VCO_Transfer_Functions.png

Green curve is the Transfer Function with the loop open and the red with that of the loop closed.

Gain Shown below is the quotient TF[open]/TF[closed]

 

VCO_Gain.png

 

 c) As can be seen from the graph above the loop gain is >>1 over 0.1 to 300Hz.  And hence the frequency noise of the VCO is just the product of the voltage noise and the VCO calibration factor over this range,

d) the noise power at the point B was measured and multiplied by the VCO calibration  factor to yield dF(rms)/rtHz:

VCO_PLL_Freq_Noise.png

The green line with dots are the data

The blue line is the rms frequency fluctuation.

This corresponds to a arm length fluctuation of about 20pm.

 

 

  4249   Fri Feb 4 13:31:16 2011 josephbUpdateCDSFE start scripts moved to scripts/FE/ from scripts/

All start and kill scripts for the front end models have been moved into the FE directory under scripts:  /opt/rtcds/caltech/c1/scripts/FE/.  I modified the Makefile in /opt/rtcds/caltech/c1/core/advLigoRTS/ to update and place new scripts in that directory. 

This was done by using

sed -i 's[scripts/start$${system}[scripts/FE/start$${system}[g' Makefile

sed -i 's[scripts/kill$${system}[scripts/FE/kill$${system}[g' Makefile

  4250   Fri Feb 4 13:45:25 2011 josephbUpdateComputersTemporarily removed cronjob for rsync.backup
<p>I removed the rsync backup from nodus' crontab temporarily so as to not have multiple backup jobs running.&nbsp; The job I started from yesterday was still running.&nbsp; Hopefully the backup will finish by Monday.</p>
<p>The line I removed was:</p>
<p>0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup</p>
<table align="left" width="786" cellspacing="1" cellpadding="1" border="2">
    <tbody>
        <tr>
            <td><span style="font-size: larger;">MC damp</span></td>
            <td><span style="font-size: larger;">dataviewer</span></td>
            <td><span style="font-size: larger;">diaggui</span></td>
            <td><span style="font-size: larger;">AWG</span></td>
            <td><span style="font-size: larger;">c1lsc</span></td>
            <td><span style="font-size: larger;">c1ioo</span></td>
            <td><span style="font-size: larger;">c1sus</span></td>
            <td><span style="font-size: larger;">c1iscex</span></td>
            <td><span style="font-size: larger;">c1iscex</span></td>
            <td><span style="font-size: larger;">RFM</span></td>
            <td><span style="">The Dolphins</span></td>
            <td><span style="font-size: larger;">Sim.Plant</span></td>
            <td><span style="font-size: larger;">Frame builder</span></td>
            <td><span style="font-size: larger;">TDS</span></td>
            <td><span style="font-size: larger;">Cabling</span></td>
        </tr>
        <tr>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="green"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="yellow"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="orange"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="yellow"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="yellow"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="yellow"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="red"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="orange"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="orange"><span style="font-size: larger;">&nbsp;</span></td>
        </tr>
    </tbody>
</table>
  4251   Fri Feb 4 15:03:20 2011 josephbUpdateComputersModified cshrc.40m

Removed some lines from the PATH environment variable since they point to old codes which no longer work with the new frame builder and setup.

The change was:

#setenv PATH $LINUXPATH/bin:$GDSPATH/bin:$ROOTSYS/bin:$TDSPATH/bin:${SCRIPTPATH}:$PATH
setenv PATH $TDSPATH/bin:${SCRIPTPATH}:$PATH

  4252   Fri Feb 4 18:58:19 2011 ranaUpdateComputersTemporarily removed cronjob for rsync.backup

Quote:

I removed the rsync backup from nodus' crontab temporarily so as to not have multiple backup jobs running.  The job I started from yesterday was still running.  Hopefully the backup will finish by Monday.

The line I removed was:

0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup

Actually, this is not true. Joe actually killed the currently running backup and set it to start tomorrow morning at 6AM. Its taking forever since its not an incremental backup but a new one due to the change in the setup.

  4253   Fri Feb 4 23:39:56 2011 rana, kojiUpdateLSCmixer based FD set up for noise test

We set up the mixer based FD to check out its noise performance.

It is being acquired as C1:GCV-XARM_FINE_OUT_DAQ.

We have calibrated it by driving the frequency of the RF signal generator and putting the value into the GAIN field. We got 100 kHz / 5450 counts; the _OUT_DAQ channel is now being recorded in units of Hz. The cable length has been adjusted so that the full mixer output can swing 16 MHz peak-peak before turning over.

Also, we did a lot of cable cleanup around the IO rack. Kiwamu and Suresh's setups were somewhat dismantled. The whole area was too messy and too hacky to be allowed to survive. Our "temporary" setups have a way of becoming permanent holding places for barrels, adapters, duct tape, etc.

  4255   Sun Feb 6 02:29:28 2011 ranaUpdateElectronicsAnalog MFD: longer cable

I swapped over to a 3x longer cable (old 65 ft. Pasternak cable from ancient 40m days). The old one was 6m, the new one is 18.2 m. It was already coiled up so I put it into a tupperware box to shield it somewhat from the HVAC wind.

The noise went down nearly proportional to the length (after I recalibrated the DAQ channel for the ~3x higher phase->voltage gain). With this length, the peak-peak mixer range is 5.5 MHz, so still enough to go an FSR here.

mfd18.png

I give credit to the low frequency improvement entirely to Tupperware for their excellent containers. The current noise limit is most likely the SR560.

  4256   Mon Feb 7 10:37:28 2011 josephbUpdateComputersTemporarily removed cronjob for rsync.backup

The backup appears to have finished on nodus, and I've put the rsync job back in the crontab.

Quote:

I removed the rsync backup from nodus' crontab temporarily so as to not have multiple backup jobs running.  The job I started from yesterday was still running.  Hopefully the backup will finish by Monday.

The line I removed was:

0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup

  4261   Tue Feb 8 15:22:13 2011 kiwamuUpdateGreen Lockingnew electronics rack at X end

 Yesterday I moved the whole green electronics stuff, which had been sitting on the floor at the X end,  into a new electronics rack.

The rack now is placed under the cable rail close to the ETMX chamber.

DSC_2861_ss.png

  4262   Tue Feb 8 16:04:58 2011 josephbUpdateCDSHard coded decimation filters need to be fixed

[Joe, Rana]

Filter definitions for the decimation filters to epics readback channels (like _OUT16) can be found in the fm10Gen.c code (in /opt/rtcds/caltech/c1/core/advLigoRTS/src/include/drv).

At the moment, the code is broken for systems running at 32k, 64k as they look to be defaulting to the 16k filter.  I'd like to also figure out the notation and plot the actual filter used for the 16k.

Rana has suggested a 2nd order, 2db ripple low pass Cheby1 filter at 1 Hz.

 

  51 #if defined(SERVO16K) || defined(SERVOMIXED) || defined(SERVO32K) || defined(SERVO64K) || defined(SERVO128K) || defined(SERVO256K)
  52 static double sixteenKAvgCoeff[9] = {1.9084759e-12,
  53                                      -1.99708675982420, 0.99709029700517, 2.00000005830747, 1.00000000739582,
  54                                      -1.99878510620232, 0.99879373895648, 1.99999994169253, 0.99999999260419};
  55 #endif
  56
  57 #if defined(SERVO2K) || defined(SERVOMIXED) || defined(SERVO4K)
  58 static double twoKAvgCoeff[9] = {7.705446e-9,
  59                                  -1.97673337437048, 0.97695747524900,  2.00000006227141,  1.00000000659235,
  60                                  -1.98984125831661,  0.99039139954634,  1.99999993772859,  0.99999999340765};
  61 #endif
  62
  63 #ifdef SERVO16K
  64 #define avgCoeff sixteenKAvgCoeff
  65 #elif defined(SERVO32K) || defined(SERVO64K) || defined(SERVO128K) || defined(SERVO256K)
  66 #define avgCoeff sixteenKAvgCoeff
  67 #elif defined(SERVO2K)
  68 #define avgCoeff twoKAvgCoeff
  69 #elif defined(SERVO4K)
  70 #define avgCoeff twoKAvgCoeff
  71 #elif defined(SERVOMIXED)
  72 #define filterModule(a,b,c,d) filterModuleRate(a,b,c,d,16384)
  73 #elif defined(SERVO5HZ)
  74 #else
  75 #error need to define 2k or 16k or mixed
  76 #endif

  4263   Tue Feb 8 16:44:43 2011 JenneUpdateComputersLIGO Grid Cluster client upgraded on Rossa

I did a yum-install of the latest ldg-client (to get onto the LIGO Clusters) on Rossa. 

I followed the instructions on the wiki page, and everything seemed to work nicely.

I think the new ldg client installs somewhere on the local computer, so if anyone wants cluster access on any other computer, they should follow the same directions.

  4264   Wed Feb 9 10:25:46 2011 steveUpdateSAFETYAP table

I blocked the  AP table's south west 10" ID port since it is obsolete with the new layout.

Reminder: items on the enclosure self can fall down in an earthquake. I moved oscilloscope and heavy calorimeter head from the edge of the cliff.

Attachment 1: P1070395.JPG
P1070395.JPG
ELOG V3.1.3-