40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 265 of 341  Not logged in ELOG logo
ID Date Author Type Category Subject
  3850   Wed Nov 3 02:37:39 2010 yutaSummaryGreen Lockingcoarse locked green beat frequency

(Kiwamu, Yuta)

We succeeded in coarse locking the green beat frequency, using a frequency counter and feeding back the signal to the X-end laser temperature.

Setup:
  beat note -> RF PD -> SHP-25 -> SLP-100 -> ZFL-1000LN -> ZFL-1000LN -> ZFL-500LN -> ZFRSC-42 -> SBP-70 -> ZFRSC-42 -> SR620 -> c1psl(C1:PSL-126MOPA_126MON)
  c1auxey(C1:LSC-EX_GREENLASER_TEMP) -> X-end laser temp

  The frequency counter SR620 converts the beat frequency to voltage.
  We added some filters (SHP-25, SLP-100, SBP-70). Otherwise, SR620 doesn't count the frequency correctly.

What we did:

  1. Getting green beat note again
     Set PSL laser temp to 31.81 °C and X-end laser temp to 37.89 °C.
     Set PPKTP crystal temp to 37.6 °C, which maximizes output green beam power.

  2. ADC channel and DAC channel
     Disconnected one channel going into VME-3123 (at 1X1) and used c1psl's C1:PSL-126MOPA_126MON as ADC channel for the output from SR-620
     Made a new DAC channel on c1auxey named C1:LSC-EX_GREENLASER_TEMP, and disconnected one channel from VME-4116 (at 1X9) to use it as DAC channel for X-end laser temperature control.

  3. Coarse lock by ezcaservo
     Ran;
        ezcaservo C1:PSL-126MOPA_126MON -s 150 -g -0.0001 C1:LSC-EX_GREENLASER_TEMP
     "-s" option is a set value. The command locks C1:PSL-126MOPA_126MON to 150 (in counts), using 0Hz pole integrator.

Result:
  The beat frequency locked on to ~77MHz. The frequency fluctuation of the beat note during the servo is ~3MHz with ~10sec timescale.
  VCO has  ~+/-5MHz range, so this coarse locking meets the requirement.

  Here's a plot of the error signal and feed back signal;
  Screenshot_LowFreqLock.png

  3849   Wed Nov 3 02:23:11 2010 yutaSummaryCDSchecking whitening filter board

Summary:
  Last night, I found that some of the input channels have wrong hardware filter switching(see elog #3842).
  So, to check the whitening board(D000210), I swapped the one with ok switching and bad switching.
  During the checking, I somehow broke the board.
  I fixed it, and now the status is the same as last night (or, at least look like the same).

What I did:
  1. Switching for SRM_LRSEN looked bad and every input channel for MC3 looked OK.
     So, I unplugged the whitening board for SRM (1X5-1-5B) and plugged it into MC3's place(1X5-1-8B).

  2. Ran WDWchecker.py for MC3. The switching seemed OK for every input channel, which means the whitening board was not the wrong one.

  3. Swapped back the whitening board as it was.

  4. Found MC3_ULSEN_OUT and MC3_LLSEN_OUT was keep showing negative value(they should be positive).

  5. Check the board and found that one of LT1125 for UL/LL was wrong (broken virtual ground).

  6. Replaced LT1125 and put the board back to 1X5-1-8B.

  7. Checked the board with WDWchecker.py and dataviewer 5-hour minute trend.
      The input signal came back to normal value(Attachment #1), MC3 damping working, input filter switching seems working

before LT1125 replacement after LT1125 replacement
C1:SUS-MC3_ULSEN_IN1: -2.4 dB [!]
C1:SUS-MC3_URSEN_IN1: 16.9 dB
C1:SUS-MC3_LRSEN_IN1: 15.4 dB
C1:SUS-MC3_LLSEN_IN1: -1.1 dB [!]
C1:SUS-MC3_SDSEN_IN1: 18.4 dB
C1:SUS-MC3_ULSEN_IN1: 18.2 dB
C1:SUS-MC3_URSEN_IN1: 17.6 dB
C1:SUS-MC3_LRSEN_IN1: 16.6 dB
C1:SUS-MC3_LLSEN_IN1: 17.1 dB
C1:SUS-MC3_SDSEN_IN1: 16.2 dB


Result:
  The whitening board seems OK.
  The wrong one is either wiring or RT model. Or, the checking script.

Attachment 1: MC3SEN.png
MC3SEN.png
  3848   Tue Nov 2 16:49:02 2010 JenneConfigurationCamerasCabling on the PSL table

Dear whomever setup the camera on the SW corner of the PSL table,

It would be handy if, even for temporary setups, all cables went underneath the white frame around the PSL table.  As it is now, the cables are in the way of the door.  The door is pretty much closed all the way, but if someone were to open other doors, the far door can easily be pushed all the way to the end of the track, thus squishing the cables.  Squished cables are bad cables.

Thanks!

  3847   Tue Nov 2 16:24:07 2010 KojiUpdateAuxiliary lockingAlignment for the green in the X trans table

[Kiwamu Koji]

Today we found the green beam from the end was totally missing at the vertex.

- What we found was very weak green beam at the end. Unhappy.

- We removed the PBS. We should obtain the beam for the fiber from the rejection of the (sort of) dichroic separator although the given space is not large.

- The temperature controller was off. We turned it on again.

- We found everything was still misaligned. Aligned the crystal, aligned the Faraday for the green.

- Aligned the last two steering mirrors such that we hit the approximate center of the ETMX and the center of the ITMX.

- Made the fine alignment to have the green beam at the PSL table.

The green beam emerged from the chamber looks not so round as there is a clipping at an in-vac steering.
We will make the thorough realignment before closing the tank.

  3846   Tue Nov 2 15:24:18 2010 josephbUpdateCDSc1ioo and c1mcs only sending MC_L, MC1_PIT, MC1_YAW

In order to have the c1mcs model run, we're running with only 3 RFM channels between c1ioo and c1mcs at the moment.  This leaves the model at around 45 microseconds, and at least lets us damp.

Alex and I still need to track down why the RFM read calls are taking so much time to execute.

  3845   Tue Nov 2 13:51:40 2010 josephb, yutaUpdateCDSRFM slowdown problem

Problem:

Each RFM memory location which needs to be read by a front end model slows the model significantly.

With no RFM memory locations to be read (replaced with grounds), the c1mcs model runs around 25 microseconds per cycle.

With 1 RFM memory location (MC_L), it runs around 29-33 microseconds.

With 3 RFM memory locations (MC_L, MC1_PIT, MC1_YAW), it runs around 45 microseconds.

With 7 RFM memory locations, the code generally doesn't run at all, going past the 62 microsecond maximum required to be able to keep up with the 16 kHz sample rate.

Last night Yuta somehow got it running with 7 RFM memory locations, but in that case, all the odd numbered RFM channels (1,3,5 as counted by the ipc file) did not work.  It was running at around 55 microseconds in that case.

The c1ioo code which is writing the data to the RFM card is experiencing no such slow down.

Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant Frame builder  ...
                     ... 
  3844   Tue Nov 2 11:34:53 2010 josephb, alexUpdateCDSdiagconfd running, excitations back in dtt

Problem:

Diagnostic test tools was starting with errors.

Cause:

After the reboot of the frame builder machine yesterday by Alex, the diagconfd daemon was not getting started by xinetd.  There was a sequence error in the startup where xinetd was being called before mounting drives from linux1.

Important Note:

If you do not see the "nds" line you would not have diagnostic tests enabled in the DTT:

[controls@rosalba apps]$ diag -i | grep nds
nds * * 192.168.113.202 8088 * 192.168.113.202

Solution:

Alex changed /etc/xinetd.d/diagconfd file to point to /opt/apps/gds/bin/diagconfd instead of /opt/apps/bin/diagconf.  He also ensured xinetd started after mounting from linux1.

Alex's Suggestion:
My feeling is we should get rid of this feature and have an NDS address
entry box in the "Online" tab in the DTT with the default "nds". I
mentioned this to Jim Batch and he greed with me, so maybe he is going to
implement this. So maybe you guys want to request the same thing too, send
the request to Rolf and Jim, so we can have the last demon exercised.

  3843   Tue Nov 2 00:17:01 2010 SureshConfigurationLockingTemporary changes to the Video Mux

Fiber coupling 1064 nm light at the end of X arm

This is 'work in progress'.  The attempt is to bring a few milliwatts of the 1064 nm light from the NPRO at the end of the South(X) Arm to the PSL table through an single mode optical fiber.  This would enable us to tune the two NPRO's to be less than 15 MHz apart by looking at their beat frequency before doubling.  Because we have a 1GHz bandwidth PD at 1064 nm, while the photodiode for green has a BW of about 30MHz.

A PBS (P-type) cube has been introduced into the beam of the X arm NPRO  (between the lamda/2 plate and the input lens of the doubling crystal).  By rotating the face of the PBS slightly away from normal incidence, I have diverted away 1.5mW of the 1064 light for coupling into the fiber. The beam has shifted slightly because of this and the green beam from the south arm has to be realigned to reach the PSL table.

A single mode fiber (Thorlabs SM980-5.8-125),  which was already laid half way, has been extended all the way to the PSL table. It runs along the  South arm in the cable tray. 

A pair of mirrors have been arranged in a zig-zag to steer the beam into a fiber coupler.  There was some hope that this coupler had been aligned at some point in the past and that attaching a fiber might result in some transmission.  But this is not the case and fiber coupler needs to be readjusted.

In order to see the light transmitted through the fiber, a camera has been set up on the PSL table.  Its output has been routed into the 'Ref Cavity reflected' video signal.  A video cable running from the ETMX to the Video-MUX used to be connected to the input channel 9 of the Video MUX.  This has now been shifted to output channel 25 of the MUX and disconnected from the camera at the ETMX.   The 'Ref Cav Refl.' video signal has been routed to the output channel 25.  The camera looking at the fiber output can now be seen on a local monitor at the end of the X arm and on the video monitor in the control room.

With the fiber disconnected, the 1064 nm beam was steered into the fiber coupler and its transmission maximised by observing  with an IR viewer.  The fiber was then connected and then the transmission at the PSL table was sought.  There was no transmission seen after a searching around this region for a few mins.

The plan is to purchase a Visual fault locator which would enable us to quickly get a rough alignment of the fiber coupler. A local vendor is listed as a distributor for this product from JDSU.  Contact info:

DuVac Electronics (EDGE)
Tel: 626-796-3291
Email: jack@duvac.com
1759 E Colorado Blvd
Pasadena, CA 91106

 

  3842   Mon Nov 1 23:31:05 2010 yutaUpdateCDSchecked input hardware filter in single frequency

Background:
  For input filter, we have analog whitening filter and also digital whitening filter. They have the same TF and when analog one is off, digital one should be on and vice versa.
  I made a python script that checks the switching automatically.

Method:
  Excite the suspension in a single frequency and see sensor inputs(XXSEN_IN1).
  Calculate the magnitude in the excitation frequency and compare it when digital whitening is off and on.
  When digital whitening is off, analog should be on, so sensor inputs should gone though the analog filter. That means the signal is multiplied by the TF of that filter, which makes the difference.

  We currently don't have excitation and I thought I have to wait, but instead of putting some extra excitation, I found that 60Hz line noise is useful.

Script:
  The script is /cvs/cds/caltech/users/yuta/scripts/WDWchecker.py
  For every sensor input, it;
    0. Stores current filter switching(XXSEN_SW1R)
    1. turns OFF the digital filter(FM1, using ezcaswitch)
    2. tdsdmd XXSEN_IN1 in 60Hz
    3. turns ON the digital filter
    4. tdsdmd XXSEN_IN1 in 60Hz
    5. divides mag(2.) by mag(4.) and calculate the analog filter gain in 60Hz
    6. Restores the filter switching in the state before the checking

Result:
  The results are;

C1:SUS-BS_ULSEN_IN1: 22.2 dB
C1:SUS-BS_URSEN_IN1: 18.7 dB
C1:SUS-BS_LRSEN_IN1: 22.7 dB
C1:SUS-BS_LLSEN_IN1: 16.0 dB
C1:SUS-BS_SDSEN_IN1: 21.5 dB
C1:SUS-ITMX_ULSEN_IN1: 16.9 dB
C1:SUS-ITMX_URSEN_IN1: 16.3 dB
C1:SUS-ITMX_LRSEN_IN1: 17.5 dB
C1:SUS-ITMX_LLSEN_IN1: 17.1 dB
C1:SUS-ITMX_SDSEN_IN1: 6.2 dB
C1:SUS-ITMY_ULSEN_IN1: 15.5 dB
C1:SUS-ITMY_URSEN_IN1: 16.5 dB
C1:SUS-ITMY_LRSEN_IN1: 17.4 dB
C1:SUS-ITMY_LLSEN_IN1: 16.3 dB
C1:SUS-ITMY_SDSEN_IN1: 18.0 dB
C1:SUS-PRM_ULSEN_IN1: 0.1 dB
C1:SUS-PRM_URSEN_IN1: 10.3 dB
C1:SUS-PRM_LRSEN_IN1: 13.1 dB
C1:SUS-PRM_LLSEN_IN1: -32.3 dB
C1:SUS-PRM_SDSEN_IN1: 14.6 dB
C1:SUS-SRM_ULSEN_IN1: 17.3 dB
C1:SUS-SRM_URSEN_IN1: 13.5 dB
C1:SUS-SRM_LRSEN_IN1: 1.6 dB
C1:SUS-SRM_LLSEN_IN1: 16.7 dB
C1:SUS-SRM_SDSEN_IN1: 18.3 dB

C1:SUS-MC1_ULSEN_IN1: 17.0 dB
C1:SUS-MC1_URSEN_IN1: 18.6 dB
C1:SUS-MC1_LRSEN_IN1: 14.9 dB
C1:SUS-MC1_LLSEN_IN1: 27.0 dB
C1:SUS-MC1_SDSEN_IN1: 16.6 dB
C1:SUS-MC2_ULSEN_IN1: 19.8 dB
C1:SUS-MC2_URSEN_IN1: 14.0 dB
C1:SUS-MC2_LRSEN_IN1: 20.8 dB
C1:SUS-MC2_LLSEN_IN1: 16.1 dB
C1:SUS-MC2_SDSEN_IN1: 17.3 dB
C1:SUS-MC3_ULSEN_IN1: 15.5 dB
C1:SUS-MC3_URSEN_IN1: 17.3 dB
C1:SUS-MC3_LRSEN_IN1: 18.2 dB
C1:SUS-MC3_LLSEN_IN1: 18.7 dB
C1:SUS-MC3_SDSEN_IN1: 16.8 dB


  Whitening filter has 18dB gain at 60Hz. (It's 3Hz pole, 30Hz zero, 100Hz zero and 0dB at DC)
  So, from the result, at least MC suspensions look like they have correct switching.
  But some channels doesn't look ok.
  We have to check those.

Plan:
   - check ITMX_SDSEN, PRM_ULSEN, PRM_LLSEN, SRM_LRSEN input filters
   - check the script and see if the script can really check. maybe the script needs some adjustments (# of averaging, multiple frequency, ......)
   - make AWG(, tdssine) work
   - check output hardware filter

By the way:
  fb is back. I don't know why. With help from Joe, I just compiled c1mcs again and again changing number of RFM channels.

  3841   Mon Nov 1 19:32:08 2010 yutaSummaryCDSfb crashed? during c1ioo and c1mcs connection at ASC

Frame builder died again!!

Background:
  We want to do angle to length measurement to optimize the beam position and increase visibility of MC locking.
  In order to do A2L measurement, we need excitation point, but AWG is currently not working.
  The better way is to use LOCKIN stuff like we had for OMC and put it to C1IOO WFS.
  A software oscillator in LOCKIN shakes the suspension, and demodulate the length signal.
  We can choose whatever DOF to shake, whatever signal to demodulate. It would be useful not just for A2L.

What I did:

  I started to put C1IOO WFS signal into C1SUS MC suspension RT model, but after compiling new c1mcs, fb crashed.
  Looks like daqd and mx_streams are running, but DAQ is not working(red).
  I don't know how to restart in a new way!

  3840   Mon Nov 1 17:27:47 2010 JenneUpdateSUSPRM ready for installation into chamber

[Jenne, Suresh]

Over the weekend, Bob and Daphen gave the PRM a 48hr. vacuum bake.  This afternoon Suresh and I placed it back in the wire in the tower.  We used the microscope-on-translation-stage technique to make sure the scribe lines on each side of the optic are at the same height, and then secured the PRM using all of the EQ stops.  It is wrapped in foil, and ready for its journey into the IFO room.  When we next have the BS chamber open, we should put the PRM in, and move the current PRM to its final place on the ITMY table as the SRM.

  3839   Mon Nov 1 16:43:24 2010 KojiSummaryCDSCDS time delay measurement

Um, Beautiful.

Actually, 123.5usec is almost exactly twice of 1/16384Hz.
Because of the loop, we have 1/16384Hz delay. I wonder where we do have the delay.

In order to understand the behaviour of the system can I ask you to test the following things?

1) What are the delay without IOPs with fsampl of 16k, 32k, 64k?

2) What are the delay with IOP with fsampl of 32k, 64k?

Quote:

Result:
  TF agreed well with 2-time feCoeff4x and CDS time delay was -123.5 usec.
CDSdelay2.png

 

  3838   Mon Nov 1 15:47:15 2010 yutaSummaryCDSCDS time delay measurement

Background:
  I measured CDS time delay last week, but because of my lack of understanding the system, it was incorrect.
  IOP has an anti-aliasing filter before downsampling from 64kHz(65536Hz) to 16kHz(16384Hz) and also has an anti-imaging filter before upsampling from 16kHz to 64kHz.
  So, I should have take feCoeff4x into account twice.
downupsampling.png

Result:
  TF agreed well with 2-time feCoeff4x and CDS time delay was -123.5 usec.
CDSdelay2.png


Plan:
 - make AWG(, diaggui TF measurement, tdssine) work
 - check input/output filter switching (using tdssine & tdsdmd)
 - measure openloop TF of MC suspension damping
 - divide it with my expectation and see if there are any filters I don't know

Quote:

Unsatisfactory.

Neglecting the digital anti-imaging filter makes the discrepancy. You must take into account your digital filter twice.

I attached the slides I made during my visit for March LVC '09. P.5 would be useful.

 

  3837   Mon Nov 1 15:35:41 2010 josephbUpdateCDSFront end USR and CPU times now recorded by DAQ

Problem:

We have no record of how long the CPUs are taking to perform a cycle's worth of computation

Solution:

I added the following channels to the various slow DAQ configuration files in /opt/rtcds/caltech/c1/chans/daq/

IOO_SLOW.ini:[C1:FEC-34_USR_TIME]
IOO_SLOW.ini:[C1:FEC-34_CPU_METER]
IOP_SLOW.ini:[C1:FEC-20_USR_TIME]
IOP_SLOW.ini:[C1:FEC-20_CPU_METER]
IOP_SLOW.ini:[C1:FEC-33_USR_TIME]
IOP_SLOW.ini:[C1:FEC-33_CPU_METER]
MCS_SLOW.ini:[C1:FEC-36_USR_TIME]
MCS_SLOW.ini:[C1:FEC-36_CPU_METER]
RMS_SLOW.ini:[C1:FEC-37_USR_TIME]
RMS_SLOW.ini:[C1:FEC-37_CPU_METER]
SUS_SLOW.ini:[C1:FEC-21_USR_TIME]
SUS_SLOW.ini:[C1:FEC-21_CPU_METER]

 

Notes:

To restart the daqd code, simply kill the running process.  It should restart automatically.  If it appears not to have started, check the /opt/rtcds/caltech/c1/target/fb/restart.log file and the /opt/rtcds/caltech/c1/target/fb/logs/daqd.log.xxxx files.  If you made a mistake in the DAQ channels and its complaining, fix the error and then restart init on the fb machine by running "sudo /sbin/init q"

  3836   Mon Nov 1 14:53:30 2010 josephb, alex, rolfUpdateCDSAlex updated FB and mx_streams code

Problem:

The framebuilder was being flaky.  MX_streams would go down, prevent testpoints from working and so forth.

Solution:

Send Alex up North for a week to fix the code. 

Alex came back and installed updates to the frame builder and the mx_streams code (Myrinet Express over Generic Ethernet Hardware) used by the front ends to talk to the frame builder.  Instead of 1 stream per model, there's now just 1 per front end handling all communications.

Alex did an SVN update and we now have the latest CDS code.

Self restarting codes:

The frame builder code (daqd) and nds pipe have been added to the fb machine's inittab.  Specifically it calls a script called /opt/rtcds/caltech/c1/target/fb/start_daqd.inittab and /opt/rtcds/caltech/c1/target/fb/start_nds.inittab.

The addition to the /etc/inittab file on fb is:

daq:345:respawn:/opt/rtcds/caltech/c1/target/fb/start_daqd.inittab 

nds:345:respawn:/opt/rtcds/caltech/c1/target/fb/start_nds.inittab

When these codes die they should automatically restart.

Self starting codes at boot up:

The front ends now start the mx_stream script (which lives in /opt/rtcds/caltech/c1/target/fb/ directory) at boot up.  They call it with the approriate command line options for that front end. It can be found in the /etc/rc.local file.

They look like: mx_stream -s "c1x02 c1sus c1mcs c1rms" -d fb:0

As always, the front end codes to be started are defined in the /etc/rtsystab file (or on fb, in the /diskless/root/etc/rtsystab file).

However, if it does go down you would need to restart it manually, although it seems more robust now and doesn't seem to go down every time we restart the frame builder.

All the usual front end IOCs and modules should be started and loaded on boot up as well.

 

Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant Frame builder  ...
                     ... 
  3835   Mon Nov 1 12:38:56 2010 Leo SingerConfigurationComputerspython-sqlite installed on Allegra

I installed the Python bindings for sqlite on Allegra using

$ sudo yum install python-sqlite python-sqlite2

  3834   Mon Nov 1 11:34:08 2010 josephbUpdateCDSCA.Client.Exception spam fixed

Problem:

CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:SUS-ITMX_TO_COIL_0_3_INMON", Connecting to: 192.168.113.85:42367, Ignored: c1susdaq:42367"
    Source File: ../cac.cpp line 1208
    Current Time: Fri Oct 29 2010 18:07:39.132686519

The above exception gets thrown for each channel sent to the framebuilder when you start the frame builder.  Its the 192.168.113.xxx (main martian) and 192.168.114.xxx (DAQ) networks sending the same information.  This makes it hard to see real errors when starting the frame builder.

Solution:

Configure EPICS channel access to only use one network.  This is done by modifying the /etc/bash/bashrc and the /diskless/root/etc/bash/bashrc files with the following two lines:

export EPICS_CA_AUTO_ADDR_LIST=NO
export EPICS_CA_ADDR_LIST="192.168.113.255"

The first line tells the computers not to automatically search all attached network devices.  The second tells it to use the 192.168.113.xxx network for EPICS channel broadcasts.

  3833   Mon Nov 1 10:28:41 2010 steveBureaucracySAFETYSuresh received 40m safety training

Our new postdoc Suresh Doravari received 40m specific safety training last week.

  3832   Mon Nov 1 10:17:55 2010 steveUpdateGeneralbreakers relabelled

Pedro of the electrical shop helped to retrace wires from the racks to the breakers. Many wrong labels were replaced. These labels are  still representing                          the south arm as Y and  the east arm as X.

Racks: 1X1,2,3,4 and 1Y3,4,5,6,7 and 9 are connected through manual disconnect swithes to  AC power breaker PC-1 on the west wall of IFO room 104.

             This panel PC-1 is connected to T1 isolation transformer in room 101 Panel L - # 38, 40, 42

Racks: 1Y1 & 2  psl and mc are connected through manual disconnect switches to AC power breaker PC-2 just west of the psl enclosure.

             This panel is connected to T2 isolation transformer in room 101 Panel L - # 32, 34, 36

Attachment 1: P1060970.JPG
P1060970.JPG
Attachment 2: P1060972.JPG
P1060972.JPG
Attachment 3: P1060975.JPG
P1060975.JPG
  3831   Sun Oct 31 00:19:35 2010 ranaSummaryComputer Scripts / ProgramsHP3563A netGPIB function

I've wheeled the old HP audio frequency signal analyzer into the control room to debug the GPIB/python interface. The wireless setup was getting more than 80% packet loss in the office area.

I also noticed that we have multiple and competing copies of the netgpib package installed. Kiwamu is going to merge them soon. Pleae only use the official location:

scripts/general/netgpibdata/

which is also the SVN working copy. Committ all changes periodicallty so that we can share the updated versions between sites.

  3830   Sat Oct 30 14:35:43 2010 KojiSummaryCDSCDS time delay measurement

Unsatisfactory.

Neglecting the digital anti-imaging filter makes the discrepancy. You must take into account your digital filter twice.

I attached the slides I made during my visit for March LVC '09. P.5 would be useful.

Quote:

Result:
  [time delay of the CDS]  (left, middle)
    The time delay gets larger with frequency. The time delay seems to be -175 usec at DC.
    However, the gain seems a little different from my expectation(feCoeff4x). So, there are maybe other filters I don't know.
    I neglected TF of upsampling this time.

 

Attachment 1: CDS_system_investigation_090323.pdf
CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf
  3829   Sat Oct 30 05:27:53 2010 yutaSummaryCDSCDS time delay measurement

Motivation:
  We want to know the time delay of CDS in the IOP scheme.

Setup:
delaysetup.png

What I did:
1. Plugged out SCSI cable from ADC card 2 and DAC card 0 on C1SUS machine.
   ADC card 2 is ADC 0
   DAC card 0 is DAC 0

2. Measured tranfer function between ADC and DAC by SR785 and compared with the downsampling filter in IOP with 65534Hz(=4x16384Hz) sampling frequency.

  As ADC_0_0 corresponds to PRM ULSEN input and DAC_0_0 corrsponds to ULCOIL output, we turned all the filters off and set gains to 0 or 1 so that TF between ULSEN to ULCOIL will be ideally 1. (see this wiki page for channel assigns)

  The filter coefficients for the down sampling filter was found in;
    /cvs/cds/rtcds/caltech/c1/core/advLigoRTS/src/fe/controller.c
  It was named feCoeff4x.

static double feCoeff4x[9] =
        {0.014805052402446,
        -1.71662585474518,    0.78495484219691,   -1.41346289716898,   0.99893884152400,
        -1.68385964238855,    0.93734519457266,    0.00000127375260,   0.99819981588176};


3. Calculated the time delay dt using the following formula;
  dt = [pm - pc]/f/360deg    (pm: measured phase, pc: calculated phase from feCoeff4x, f: frequency)

4. Measured TF between the SCSI cables to estimate the effect of the cables and others.
  Disconnected SCSI cables from ADC and DAC, and connected A aad B(see setup).
  I measured both when input coupling of SR785 is DC and AC and see what happens.

Result:
  [time delay of the CDS]  (left, middle)
    The time delay gets larger with frequency. The time delay seems to be -175 usec at DC.
    However, the gain seems a little different from my expectation(feCoeff4x). So, there are maybe other filters I don't know.
    I neglected TF of upsampling this time.

  [cable and other effect]  (right)
    The effect to the time delay measurement was tiny by a factor of 10^4 to 10^3 (few nsec).
    But the total cable length was about 5 m and assuming signal speed is 0.6c, delay will be about 30 nsec.
    I don't know what's happening.

CDSdelay.png

Plan:
  - make a model that does not go through IOP and see the delay caused by IOP

By the way:
  fb daqd is still running for hours!
  Every FEs are running(c1sus,rms,mcs).

  3828   Fri Oct 29 18:37:33 2010 yutaSummaryCDSdaqd and current CDS status

Background:
  Before Joe left(~ 1 hour ago), fb was working for a while. But after he left, daqd core dumped.
  This is maybe because we started c1sus and c1rms again for a delay measurement, just before he left.

What I did:
  I restarted IOP(c1x02) and FE models.
  Now it seems OK (we can use dataviewer and diaggui), but daqd reports bunch of errors like;

CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:SUS-ITMX_TO_COIL_0_3_INMON", Connecting to: 192.168.113.85:42367, Ignored: c1susdaq:42367"
    Source File: ../cac.cpp line 1208
    Current Time: Fri Oct 29 2010 18:07:39.132686519
..................................................................


tp node xx invalid  (xx is 38 to 36)

Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant  ...
                   ... 

   Please add other stuff you need.

Below is an example of how the color code works:

06-25-2009.NN_24ThreatLevel.GJH2L69BK.1.jpg

  3827   Fri Oct 29 16:43:25 2010 josephbUpdateCDSc1ioo now talking to c1sus

Problem:

c1ioo was not able to talk to c1sus because of timing issues.  This prevented the mode cleaner length signal (MC_L) from getting to c1sus.

Solution:

The replacement c1ioo chassis from Downs with a more recent revision of the IO backplane works. 

The c1ioo is now talking to c1sus and transmitting a signal.

We connected the cable hanging off the DAQ interface board labeled MC OUT1 to the MC Servo board's output labeled OUT1.

During debugging I modified the c1x02, c1x03, c1mcs and c1ioo codes to print debugging messages.  This was done by modifying the /opt/rtcds/caltech/c1/advLigoRTS/src/fe/commData2.c file.  I have since reverted those changes.

Future:

We still need to check that everything is connected properly and that the correct signal is being sent to the MC2 suspension.

 

  3826   Fri Oct 29 16:39:01 2010 JenneUpdateTreasureOld Green suspension towers disassembled

[Jenne, Joonho]

At Koji's request, we disassembled 2 of the old Green suspension towers that have been sitting along the X-arm forever (read that last word in a 'Sandlot' voice.  Then you'll know how long the suspensions have been sitting there).

They are now hanging out in plastic trays, covered with foil.  They will now be much easier to store.

We should remember that we have these, particularly because the tables at the top are really nice, and have lots of degrees of freedom of fine adjustment.

 

Steve:

Atm1, there is one more of these old suspension towers

Atm2, disassembled

Attachment 1: P1070014.JPG
P1070014.JPG
Attachment 2: P1070015.JPG
P1070015.JPG
  3825   Fri Oct 29 16:03:35 2010 kiwamuUpdatePSLwideband EOM : installed the triple resonant box

 

 small_DSC_2654.jpg

The box is electrically isolated from the optical bench.

Underneath the box there are four rubber legs and two Delrin plates (black and white) on the top of the box. 

As everyone knows this box is a prototype, so I will make another nicer box with a PCB in this November.

  3824   Fri Oct 29 14:16:26 2010 JenneUpdateSUSPRM baking

[Suresh, Jenne]

We took a look-see at the PRM after the gluing from last night.  The balance is still okay.  The reflected beam is a teeny bit below the laser aperture (center of the beam maybe ~2mm below, so ~1mRad low).  This is within our okay range, since the DC offset that the OSEMs will give will be even more, and the coils can definitely handle this kind of offset.

We took the optic out of the tower, and gave it to Bob and Daphen to bake over the weekend.

  3823   Fri Oct 29 14:06:12 2010 kiwamuUpdateGreen LockingRe: 80MHz VCO for green PLL : VCO calibration

P.S. There is a document about the 80MHz VCO box. This may be helpful. 

link to LIGO DCC

  3822   Fri Oct 29 11:29:29 2010 josephbUpdateCDSHow I broke the frame builder yesterday

Problem:

Long before Yuta came along and deleted daqd, I had done something to prevent the framebuilder code from running at all.

Cause:

Alex pointed out via e-mail that the corresponded to the inability to access certain frame files due to their permissions being only for root. 

Turns out when I had run the code under the inittab, I forgot to make it use controls, instead of root (which is the default).  This later on caused problems for the code when it tried to access those files, resulting in the wierd errors we saw.

Solution:

Use chown to change the offending frame files back to controls.

Future:

Write a proper inittab script which uses "su controls" before running the daqd code.

  3821   Fri Oct 29 11:25:15 2010 josephb, yutaSummaryCDS[EMERGENCY] accidentally deleted daqd

Problem:

Missing daqd file, i.e. the framebuilder executable.

Solution:

1) Go to /opt/rtcds/caltech/c1/core/advLigoRTS/

2) Look in the Makefile for a likely build suspect.  In this case it was build dc, which stands for data concentrator.

3) So we ran "make dc"

4) Go to the sub-directory build/dc/ and then copy the daqd file there to the /opt/rtcds/caltech/c1/target/fb directory

5) Test it to ensure we're getting channels (Yay!)

Future Safeguards:

Place the new target directory under SVN control.

 

  3820   Fri Oct 29 06:20:20 2010 kiwamuUpdateGreen Locking80MHz VCO for green PLL : VCO calibration

 I calibrated the VCO frequency as a function of the applied input voltage.

The range is approximately +/- 5 MHz, which is large enough to cover the arm's FSR of 3.75MHz.

calibration.png 

======== measured parameters ======

center frequency: 79.5 MHz

VCO range: 74MHz - 84MHz

coefficient : 1.22MHz/ V (+/- 2V range)

nominal RF power: -0.66 dBm

(Note: The measurement was done by using Giga-tronics hand-hold power meter.)

Quote from #3803

Tomorrow I will check the VCO part, especially I am curious about the VCO range.

  3819   Fri Oct 29 05:40:51 2010 kiwamuUpdatePSLwideband EOM aligned : AM decreased by 24dB

At the PSL table I aligned the wideband EOM more carefully.

Amplitude modulation (AM) components in the main beam at 29.5MHz were successfully diminished by 24 dB. 

Last night when we were locking the MC, we noticed that the reflected light had AM which somewhat disturbes the Pound-Drever-Hall locking of the MC.

So I aligned the wideband EOM to reduce the AM components.

 


(method)

  In order to observe AMs I put a photodiode PDA255 whose bandwidth is 50MHz after the wideband EOM.

Before the PD I also put a convex lens together with a stack of ND filters and put a steering mirror to control the beam spot on the PD.

 EOMalign.png

First I aligned the EOM such that the DC voltage from the PD was maximized. This process corresponds to a coarse alignment.

And then I tried reducing a peak at 29.5MHz seen in the spectrum analyzer. 

 

(results)

At the beginning the AM peak in the spectrum analyzer was at about -48 dBm.

After the alignment of the EOM it went down below the PD's dark noise floor of -72 dBm.

I checked the alignment also with an IR viewer, it looks quite good.

  3818   Fri Oct 29 04:58:04 2010 KevinUpdatePSLPBS Optimization

[Koji and Kevin]

Since there was still a lot of power being reflected from the PBS before the Faraday rotator, I placed another PBS at the reflection from the first PBS to investigate the problem. If everything was ideal, we would expect the PBS to transmit P polarization and reflect S polarization. Thus, if the laser was entirely in the TEM00 mode, with the quarter and half wave plates we should be able to rotate the polarizations so that all of the power is transmitted through the PBS. In reality, some amount of P is reflected in addition to S reducing the power transmitted. (We are not sure what the PBS is since there are no markings on it but CVI says that their cubes should have less than 5% P reflection).

For the following measurements, the laser crystal temperature was 31.8° C, the current was 2.1 A, the half wave plate was at 267° and the quarter wave plate was at 330°. I first measured the power reflected from the first PBS then added the second PBS to this reflected light and measured the transmitted and reflected powers from this PBS with the following results:

reflection from first PBS 127 mW
reflection from second PBS 48 mW
transmission from second PBS 81 mW

This shows that approximately 81 mW of P polarization was being reflected from the first PBS and that there is approximately 48 mW of S polarization that could not be rotated into P with the two wave plates. Attachment 1 shows the shape of the reflected (S polarization) beam from the second PBS. This shows that the S polarization is not in TEM00 and can not be rotated by the wave plates. The transmitted P polarization is in TEM00.

We then rotated the first PBS (in yaw) to minimize the amount of P being reflected. Repeating the above measurement with the current alignment gives

reflection from first PBS 59 mW
reflection from second PBS 52 mW
transmission from second PBS 8.5 mW

Thus by rotating the cube to minimize the amount of P reflected, ~70 mW more power is transmitted through the cube. This adjustment moved the beam path slightly so Koji realigned the Faraday rotator and EOM. The PMC was then locked and the beam was realigned on the PMC. At 2.1 A, the transmission through the PMC is 6.55 V and the reflection is 178 mV. With the PMC unlocked, the reflection is 312 mV. This gives a visibility of 0.43.

Note by KA:
We realigned the beam toward the PMC at 1.0A at first so that we don't cook any parts. Once we get the TEM00 resonance, the steering mirrors were aligned to maximize the PMC transmission. Then the pumping current was increased to 2.1A.

  3817   Fri Oct 29 04:24:34 2010 KojiUpdateIOOPMC output increased: need attention

[Kevin Koji]

- The PBS alignment increased the transmitted power

- The first faraday and the PMC EOM were realigned.

- The transmission of the PMC increased from ~5.4V to ~6.5V.

Thus we need to pay attention to the incident beam power on to the MC
so that it does not exceed the power of 20-40mW.

Kevin will give us the detail of the work.

  3816   Fri Oct 29 01:18:03 2010 KojiSummarySUSPRM standoff glued

[Suresh Koji]

The standoff glued. The incandescent lamp set for curing the epoxy.


Jenne and Suresh did the balancing job. The next job was to glue it.

They ran out of the clear epoxy, and tried to use the grey epoxy which we used on the other suspensions for the upgrade.
They found that the solution A with grey color one was dried out and grainy.

We made a test piece of the grey epoxy (mixed with the solution B) in order to see the glue is still usable or not.
After the PMA party, we found that the glue was not stiffening but brittle. We judged that the grey epoxy is no longer useful.

Steve found a pack of Vac Seal in the chemical fridge. We decided to use this one for the gluing of the standoff.

After the gluing, we set an incandescent lamp to make the glue warm. 

Finally, we wrapped the suspension tower with Al foils and turned the HEPA fans again.

Attachment 1: IMG_3674.jpg
IMG_3674.jpg
  3815   Thu Oct 28 23:17:15 2010 yutaSummaryCDS[EMERGENCY] accidentally deleted daqd

Rana showed me that if c1sus machine runs c1mcs stuff(and c1x02 stuff) only, we can use dataviewer without crashing fb.
Also, if we set correct NDS server and port(fb/8088), we can use diaggui on every machine.


During my investigation on what he did, I accidentally deleted daqd......
I am very very sorry.

I don't know if it helps or not, but all I have is the following information:

[Backup?]
    /opt/rtcds/caltech/c1/target/fb/daqd.25sep10


[What I deleted]
   -rwxr-xr-x 1 controls controls 6583071 Oct  1 11:57 daqd


[help message for daqd existed]
CDS Data Acquisition Server, Frame Builder, version 2.0
California Institute of Technology, LIGO Project
Client communication protocol version 11.4

Usage:
        daqd [-f <input frame file name>]
        [-c <configuration file (default -- $HOME/.daqdrc)>]

        [-s <frame writer pause usec (default -- 1 sec)>]


This executable compiled on:
        Fri Oct  1 10:33:18 PDT 2010
        Linux fb 2.6.34.1 #7 SMP Fri Sep 24 14:09:53 PDT 2010 x86_64 Dual-Core AMD Opteron(tm) Processor 8220 AuthenticAMD GNU/Linux



Please help me, Joe.

  3814   Thu Oct 28 21:20:11 2010 yutaUpdateCDSFlaky fb, tried DAQ re-install, but no help

Summary:
  Unfortunately, fb is flakier than normal. We can't use dataviewer and diaggui now.
  I thought it might be because editting .ini files(list of DAQ channels) in /cvs/cds/rtcds/caltech/c1/chans/daq/ without using GUI was doing something wrong.
  So, I re-installed DAQ, but it didn't help.

What I did:
1. ssh c1sus, went to /opt/rtcds/caltech/c1/core/advLigoRTS/ and ran
  make uninstall-daq-c1SYS
  make install-daq-c1SYS

It didn't help.
More than that, MC suspension damping went wrong. So;

2. Rebooted c1sus machine.
 I restored MC suspension damping by doing this.
 (Similar thing happened Tuesday when we were trying to lock MC)

Conclusion:
  Editting .ini DAQ channel list file wasn't wrong. (or, I failed in finding anything wrong right now)

Quote:

Attempted Fixes:

Yuta may try restoring the old DAQ channel choices and see if that makes a difference.

 

  3813   Thu Oct 28 20:08:26 2010 yutaUpdateGreen Lockingrevised RF amp cascading

Background:
  Yesterday, I said I will use ZHL-32A for amplifying beat note signal, but as Koji pointed out, ZHL-32A is for medium high power.
  So I changed my mind to use ZFL-1000LN instead. ZFL-1000LN is a low noise RF amp whose maximum power is 3dBm.
  Also, we included a splitter in our consideration.

What I did:

1. Set up a new setup. ZFL-1000LN has a gain of +24dB at 80MHz and splitter ZFRSC-42 has a loss of -6dB. So;

beat note signal -> ZFL-1000LN -> ZFL-1000LN -> ZFRSC-42 => SR620 and VCO

2. Measured frequency-output relation. When the input signal was 80MHz -48dBm, the output was -8.7dBm. For other frequencies;
       60MHz  -3.3dBm
       70MHz  -5.7dBm
       80MHz  -8.7dBm
       90MHz  -5.5dBm
      100MHz  -3.5dBm
  So, we can see frequency up to >100MHz by SR620 using this setup.

3. Checked harmonics peak levels of the output using an RF spectrum analyzer. When the input signal was 80MHz -48dBm, the height of the peaks were;
     80MHz -8.8dBm
    160MHz -30dBm
    240MHz -42dBm
  Other peaks were smaller than the 3rd harmonics. Also, RF PD that detects beat note signal has a cut-off frequency at around 100MHz. So, we don't need to worry about wave transformation for this setup.

Quote:

ZHL-32A is a high power (well..., actually middle power) amplifier with the max output power of +29dBm (~1W!).
It seems to be overkill.
Your signal is so small so you don't need ZHL-32A, but can use small amp which we may have somewhere in the lab.

And the description:
"RF amplifier ZHL-32A has around +28dBm gain at 80MHz"
The unit is wrong.

Yes. I corrected my previous elog.

  3812   Thu Oct 28 19:10:26 2010 taraUpdateElectronicsTTFSS for 40m

I keep a set of new TTFSS for 40m in electronic cabinet along the North arm.

The set number is #6. It is working and has not been modified by me.

Other two sets,# 5 and #7, are kept at PSL lab.

  3811   Thu Oct 28 16:38:54 2010 josephbUpdateCDSFlaky fb, reverted inittab changes on fb

Problem:

Yuta reported many of the signals being displayed by dataviewer "fuzzier" than normal.  And diaggui was not working.

Running "diag -i" reported:

Diagnostics configuration:
awg 21 0 192.168.113.85 822095893 1 192.168.113.85
awg 36 0 192.168.113.85 822095908 1 192.168.113.85
awg 37 0 192.168.113.85 822095909 1 192.168.113.85
tp 21 0 192.168.113.85 822091797 1 192.168.113.85
tp 36 0 192.168.113.85 822091812 1 192.168.113.85
tp 37 0 192.168.113.85 822091813 1 192.168.113.85

This seems to be missing an nds type line between the 3 awgs and the 3 tp lines.

The daqd code (the framebuilder) is being especially flaky today, and I'm starting to see new errors.

[Thu Oct 28 16:13:46 2010] Couldn't open full trend frame file
`/frames/trend/second/9723/C-

T-972342780-60.gwf' for writing; errno 13
epicsThreadOnceOsd epicsMutexLock failed.
epicsThreadOnceOsd epicsMutexLock failed.
epicsThreadOnceOsd epicsMutexLock failed.
epicsThreadOnceOsd epicsMutexLock failed.
epicsThreadOnceOsd epicsMutexLock failed.
Segmentation fault (core dumped)

or

[Thu Oct 28 16:17:06 2010] Couldn't open full frame file
`/frames/full/9723/.C-R-972343024-16.gwf' for writing; errno 13
CA client library tcp receive thread terminating due to a C++ exception
FATAL: exception not rethrown
CA client library tcp receive thread terminating due to a C++ exception
CA client library tcp receive thread terminating due to a C++ exception
FATAL: exception not rethrown
cac: tcp send thread received an unexpected exception - disconnecting
Aborted (core dumped)

What was done today that might have affected it:

A new c1ioo chassis from Downs was connected to c1ioo.  I also connected c1ioo to the DAQ network (192.168.114.xxx) which talks to the frame builder.

I started downloading the necessary files to be able to follow Keith's instructions for a standard control / teststand setup in /opt/apps , /opt/rtapps, etc.  However, it has not actually been installed yet.

Yuta added additional OL channels to the DAQ config for being recorded.

Attempted Fixes:

I reverted the inittab changes I made in this elog.  Didn't help.

I disconnected c1ioo from the DAQ network.  Didn't help.

Rebooted the frame builder machine.  Didn't help.

I've sent an e-mail to Alex describing the problem to see if he has any idea where we went wrong.

Yuta may try restoring the old DAQ channel choices and see if that makes a difference.

Current Status:

daqd framebuilder code still won't stay up.  So no channels at the moment.

  3810   Thu Oct 28 13:01:34 2010 steveUpdatePEMcrane repair guys left for the day

Quote:

Fire-smoke sensors in the vertex area #2-31, 2-30 east, 2-32 south/MC2 and 2-37 old control room area are turned off to accommodate the welding

activity of folding crane. These sensors will be reactivated at 3:30pm today.

Stay out of the 40m lab: IFO room till 6 pm today.

 The new cord wheel was to big. They be back tomorrow?

The lab is open.

  3809   Thu Oct 28 11:54:31 2010 KojiUpdateGreen Lockingchecked frequency counter SR620

ZHL-32A is a high power (well..., actually middle power) amplifier with the max output power of +29dBm (~1W!).
It seems to be overkill.
Your signal is so small so you don't need ZHL-32A, but can use small amp which we may have somewhere in the lab.

And the description:
"RF amplifier ZHL-32A has around +28dBm gain at 80MHz"
The unit is wrong.

Quote:

(Kiwamu, Yuta)

Background:
  For green locking, we are planning to feedback frequency differential signal to ETM suspension for the final configuration.
  We don't have ETM suspension control system right now, so we are going to feedback the signal to X-end laser frequency for a test.
  We have two loops for the servo;
    1. coarse locking using frequency counter, feeding back to the laser temperature
    2. using VCO, feeding back to the laser PZT
  Today, we checked frequency counter SR620 and see how to get the small beat note signal(-48dBm; see elog #3771).

What we did:
  1. Using Marconi(RF signal generator), put RF signals to SR620 and see how small signal SR620 can see.
    It depends on the frequency. For 80MHz signal, you need more than about -9dBm.
       60MHz  >-12dBm
       70MHz  >-10dBm
       80MHz  >-9dBm
       90MHz  >-8dBm
      100MHz  >-7dBm

Since we are going to lock the frequency difference between X-end and PSL to 80MHz, we need at least +40dBm amp before putting the signal into SR620.

RF amplifier ZHL-32A has around +28dBm gain at 80MHz, so we need 2 of them.

  2. Marconi -> ZHL-32A -> ZHL-32A -> SR620 and see how small 80MHz signal SR620 can see.
    Around -68dBm. This should be enough.

  3. SR620 has "STRIP CHART" output on the rear panel. The output voltage is proportional to the mean frequency of the input.
    The output range is 0-8V. So in order to get 4V for 80MHz, set SCALE to 20MHz.

Plan:
 - find green beat again and see if SR620 can see it with double ZHL-32A configuration

 

  3808   Thu Oct 28 09:16:17 2010 steveUpdatePEMwelding in the vertex area

Fire-smoke sensors in the vertex area #2-31, 2-30 east, 2-32 south/MC2 and 2-37 old control room area are turned off to accommodate the welding

activity of folding crane. These sensors will be reactivated at 3:30pm today.

Stay out of the 40m lab: IFO room till 6 pm today.

  3807   Thu Oct 28 04:28:50 2010 yutaUpdateGreen Lockingchecked frequency counter SR620

(Kiwamu, Yuta)

Background:
  For green locking, we are planning to feedback frequency differential signal to ETM suspension for the final configuration.
  We don't have ETM suspension control system right now, so we are going to feedback the signal to X-end laser frequency for a test.
  We have two loops for the servo;
    1. coarse locking using frequency counter, feeding back to the laser temperature
    2. using VCO, feeding back to the laser PZT
  Today, we checked frequency counter SR620 and see how to get the small beat note signal(-48dBm; see elog #3771).

What we did:
  1. Using Marconi(RF signal generator), put RF signals to SR620 and see how small signal SR620 can see.
    It depends on the frequency. For 80MHz signal, you need more than about -9dBm.
       60MHz  >-12dBm
       70MHz  >-10dBm
       80MHz  >-9dBm
       90MHz  >-8dBm
      100MHz  >-7dBm

Since we are going to lock the frequency difference between X-end and PSL to 80MHz, we need at least +40dBm amp before putting the signal into SR620.

RF amplifier ZHL-32A has around +28dBm +28dB gain at 80MHz, so we need 2 of them.

  2. Marconi -> ZHL-32A -> ZHL-32A -> SR620 and see how small 80MHz signal SR620 can see.
    Around -68dBm. This should be enough.

  3. SR620 has "STRIP CHART" output on the rear panel. The output voltage is proportional to the mean frequency of the input.
    The output range is 0-8V. So in order to get 4V for 80MHz, set SCALE to 20MHz.

Plan:
 - find green beat again and see if SR620 can see it with double ZHL-32A configuration

  3806   Thu Oct 28 04:23:38 2010 ranaUpdateIOOA2L prep

To get the angle to length signal before the c1ioo processor gets going, we need a length signal. We can use either the error signal or the control signal.

I recommend using the control signal since its not puny. The 4-pin LEMO inputs to the OSEM ADC that Suresh has wired are differential so we can, in principle, use either the BNC output of the SERVO plug or the 2-pin LEMO output.

The analog whitening on the OSEM Whitening board should be engaged via the SUS MEDM screen so that we get a good SNR at the A2L dither frequencies.

If the ADC saturates, then we should use a pomona box RC low pass to cut everything off above 100 Hz.

Also, a comment about Yuta's elog: we estimated that the seismic motion was ~1e-7 - 1e-6 meters. The MC linewidth ought to be ~lambda/(2*Finesse) ~ 1e-9.

So, the MC servo as it was was not giving us enough gain (1/f above 50 Hz; UGF ~5-10 kHz) to get the error signal to stay in the linear PDH region. Kevin's filter gave us ~10x more gain at the seismic frequencies (1-3 Hz) of concern.

  3805   Thu Oct 28 03:39:58 2010 yutaUpdateIOOgot very stable MC locking

(Rana, Suresh, Jenne, Kiwamu, Kevin, Yuta)

Summary:
  Last night we locked MC by feeding back the signal to NPRO PZT.
  But it was not so stable.
  We wanted more gain to lower the seismic motion, but we don't need high gain in high frequency part(>~1kHz) because it may cause something bad(NRPO PZT oscilatting, PMC not able to catch up with the NPRO frequency change, etc).
  So, we put DC gain boost today.
  It successfully made MC locking stable!

What we did:
1. Lowered the main laser temperature from 32.2° C to 31.8° C.
  When we increased the laser temperature, PMC transmission get lower.  32.2° C was on the cliff, so we put it to plateau region.

2. Lowered the gain of PMC servo (2dB instead of 8dB last night), because PMC was oscillating.
  We got 5.3V OMC transmission.

3. Made 3Hz pole, 30Hz zero filter and put in NPRO PZT servo loop.
  0dB at DC, -20dB at high frequency (see Kevin's elog #3802)

4. Put more gain to NPRO PZT servo loop to compensate -20dB at high frequency.
  In a word, we put DC gain boost.
  Attachment #1 is the MEDM screen screenshot for MC servo.

5. Aligned the beam into QPD at MC2 trans.
  We put lens in front of the QPD.
  Now, we can see the actual motion of the beam, and resonance peaks(Attachment #2; not locked at the highest).
    (We added 30Hz LPF after each 4 quadrant inputs to reduce noise)

Plan:
 - optimize MC suspension alignments
 - activate OL DAQ channels
 - reduce RFAM
 - install tri-mod box
 - QPD signal at MC2 should be more high(currently, ~7counts which equals to ~4mV)
 - change temperature of X-end laser to get green beat

Attachment 1: C1IOO_MC_SERVO20101028.png
C1IOO_MC_SERVO20101028.png
Attachment 2: MCrocks!.png
MCrocks!.png
  3804   Thu Oct 28 03:21:35 2010 SureshUpdateLockingAligned the MC2 transmission photodiode

Yuta and Suresh

The MC2 transmission is seen on the QPD

Once the laser was locked to the cavity, and the PMC was able to follow the laser (ref: elogs by Yuta and Rana today)  we had a steady TEMoo mode in the MC.  This gave us sufficient transmission through MC2 to be easily visible with an IR viewer and we were able to guide the beam on to the QPD.  The beam however seemed to over fill the QPD, a lens (f=180mm) was placed before the beam folding mirror and the spot sized reduced.   The the QPD was found to be not fixed to the table and this was also recitified.  The signal level is still low: total signal is just about 7 DAQ steps amounting to about 5mV.  Tomorrow we plan to work on the alignment of the PSL and MC and thus increase this signal.

A new channel to observe the length variations in the MC.

A long BNC cable was laid from the MC locking electronics next (southwards) to the PSL table to the DAQ cards picking up the signals from the PRM OSEMS.  This is to pick up one of the MC locking signals and collect it on a DAQ channel.  However as there are no spare DAQ channels currently available one of the PRM OSEM (UL and LL) photodiode channels was unplugged and replaced with the signal from the long BNC cable.   For identifying the correct DAQ channel we put in a 2 Vpp 10Hz signal with a function generator into this BNC.  Tow signals can be picked up in this fashion and they are available on PRM_LLSEN_IN1 and PRM_ULSEN_IN1. We plan to use this for improving the alignment of the MC tomorrow. 

The algorithm for this alignment is that if the beam from the PSL is not centered on the MC1 then tilting MC1 would result in a change in the length of the cavity as seen by the light.  Using this as feedback the spot could be precisely centered on the MC1 and then the MC alignment could be completed by moving MC2 and MC3 to reobtain TEM_oo within the cavity.

  3803   Thu Oct 28 03:07:53 2010 kiwamuUpdateGreen Locking80MHz VCO for green PLL : a health check

 I did a health check for a 80MHz VCO box. 

I started taking care with the black VCO box, which has been sitting on the SP table and will be used for converting the green beat signal from frequency to voltage.

The circuit in the box basically consists of three parts: low pass filters (LPFs), a VCO and RF amplifiers.

Today I checked the LPF stage. It looks pretty healthy.

Tomorrow I will check the VCO part, especially I am curious about the VCO range.

 


 (soldering)

 Since somebody ( surf students ?) removed some resistors, the VCO was just freely running without being applied any voltage.

I put some resistors back on the circuit board by soldering them.

Now the resistors are placed in the same configuration as the original schematic (link to LIGO DCC) except for the wideband signal path, which has a differential input.

I left the wideband path disconnected from the VCO.

 

(transfer function measurement)

The LPF part in 'external mod' path contains two stages in series:

one is for cutting off demodulated signals above fc=80MHz and the other one is for PLL servo with pole=1Hz, zero=40Hz.

In order to activate this path I shorted 10th pin of the analog switch: MAX333A.

During the transfer function measurement I injected signals to 'external mod' input and took the output signal from a test point pin TP7.

The plot below shows a fitting result of the measured transfer function of the whole LPF stage. I used liso for the fitting.

The measured filter's shape agreed with the design. (though I haven't checked 80MHz cut off)

VCO_LPF_fit.png

  3802   Thu Oct 28 02:01:51 2010 KevinUpdatePSLFilter for 2W Laser

[Rana and Kevin]

I made a low pass filter for the piezo driver for the 2W laser that is now installed. The filter has a pole at 2.9 Hz. The transfer function is shown in attachment 1.

Attachment 2 shows the outside of the filter with the circuit diagram and attachment 2 shows the inside of the filter.

Attachment 1: tf.PDF
tf.PDF
Attachment 2: outside.jpg
outside.jpg
Attachment 3: inside.jpg
inside.jpg
  3801   Wed Oct 27 21:51:29 2010 SureshUpdatePSLAttenuation of PSL NPRO removed

The laser power was attenuated to 40 mW yesterday for ensuring that the power built up within the MC does not damage the optics. 

This however stopped us from the doubling work and besides also reduced the power available for locking the PMC. 

Therefore, today the laser attenuation was removed and once again 500mW is available at the exit of the PMC .  

However the power sent to the MC has been reduced to 60mW by changing one of the mirrors in the zig-zag to a 33% beam splitter.  Though about 450mW is incident on the beam splitter the reflected beam is only about 55mW since the mirror reflectance is specified for P polarised light incident at 45deg while ours is S-polarised incident at less than 45deg.   The light transmitted through the beam splitter has been blocked by a beam dump.

 

 

ELOG V3.1.3-