40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 252 of 327  Not logged in ELOG logo
ID Date Author Type Category Subject
  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.

 

 

  3800   Wed Oct 27 21:33:42 2010 SureshUpdateLockingGreen from the far end re-obtained

 

The mirror which was moved during the mode matching of PSL light to the MC (ref elog #3791) has been repositioned.  We once again have the green light from the NPRO on the X (south) arm available on the PSL table. 

This light was supposed to be collimated by the two plano convex lenses (f=200mm and f=50mm  ref to elog #3771) but it was converging.  So I moved the f=50mm lens backwards to make the beam collimated.  I checked the beam collimation by introducing an Al coated mirror infront of th PD and diverting the beam temporarily in a free direction.  I could then check the collinearity and collimation of both the green beams over a meter.  After alignment the mirror was removed and the light is now incident on the PD once again.  We can now proceed to look for green beats.

The power from the PSL NPRO was attenuated for the MC locking work of yesterday.  It has now been increased to the maximum by rotating the Half Wave Plate (HWP).  The power after the PSL is now about 450mW  (500mW - 10% picked off for the doubling).

 

 

 

  3799   Wed Oct 27 17:06:48 2010 josephbUpdateCDSMoved c1iscey chassis and host interface board to c1ioo

Problem:

Need a working IO chassis connected to c1ioo in order to bring the MC_L into the digital realm, and then via RFM transmit to the c1sus machine.

Attempted Solution:

Move the c1iscey IO chassis to c1ioo while the c1ioo chassis is at downs.

The c1iscey chassis however doesn't seem to be talking to the c1ioo computer.  I tried changing the host interface card on the c1ioo chassis.  I took out One Stop Systems HIB2-x4-H interface card with serial number 26638 from the c1ioo computer and put in the One Stop Systems HIB2-x4-H with serial number 35242 in from c1iscey into c1ioo.  Still didn't work.

All the lights are red on the interface card on the actual chassis and its cooling fan isn't spinning. 

Using dmesg on c1ioo shows that it does not see any of the ADC/DAC/BO cards.

Status:

I'm going to  wait until tomorrow morning when Rolf gets a chance to look at the c1ioo chassis over at Downs to determine the next step.  If we fix the c1ioo chassis, I'm move the c1iscey chassis and its host interface board back to the end.

  3798   Wed Oct 27 16:15:35 2010 SureshUpdateSUSRe-glued magnet to the PRM

Thanh and I re-glued the magnet to the PRM following the procedure outlined by Jenne

The PRM in the gluing fixture has been placed in the little foil house and left to cure for a day.

If all goes well the balancing the PRM will be done tomorrow.

 

 

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

Problem:

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

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

Action:

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

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

 

  3796   Wed Oct 27 12:32:53 2010 josephbUpdateCDSfb rebooted to try and fix testpoints

Problem:

Test points were unavailable last night, even after reboots of c1sus and even restarting the daqd process on the frame builder.

Cause:

Its unclear at this time.  My guess is flaky fb and mx_stream codes.  At the moment, the daqd often requires several restarts as it segfaults within a minute or two of restarting it.

What we did (aka treating the symptoms):

We rebooted the frame builder machine.  I also added the daqd and nds processes to the inittab.  Now when these die, they will automatically be restarted.

Steps to add to the inittab on fb

0) If not on fb, ssh -X fb

1) cd /etc/

2) sudo vi inittab or sudo emacs init

3) Add a line like: id:runlevels:action:process

The id is a unqiue 2-4 letter and number identifier for the process

Run levels is the run level of linux that it will start at. 345 will cover the normal cases

action is what to do with the process. Respawn makes it run at startup and also restarts it everytime it dies.

process is the command you want to run

See "man inittab" for more details

In this case we added

daq:345:respawn:/opt/rtcds/caltech/c1/target/fb/daqd -c /opt/rtcds/caltech/c1/target/fb/daqdrc > /opt/rtcds/caltech/c1/target/fb/daqd.log


nds:345:respawn:/opt/rtcds/caltech/c1/target/fb/nds pipe > /opt/rtcds/caltech/c1/target/fb/nds.log

4) Save.

5) Run "sudo /sbin/telinit q".  This forces init to rexamine the inittab file

daqd and nds will now automatically restart when they die.

Continuing issues:

When the frame builder dies, the mx_stream processes on the front ends die as well.  These need to be restarted manually at the moment by using "sudo /etc/restart_streams" while on c1sus.

The framebuilder code shouldn't be this flaky.

  3795   Wed Oct 27 11:52:45 2010 josephbUpdateelogElog needed to be restarted

I had to restart the elog on Nodus because it was no longer responding.

  3794   Wed Oct 27 11:34:40 2010 josephbUpdateCDSModified rc.local for front end machines

What was the problem:

On reboot, c1sus was in a strange state.  The epics IOC was running, along with tpman, but there were no loaded front ends.

People had to manually run sudo insmod c1SYSfe.ko.

What was the cause:

Awhile back Alex had commented out the line in the rc.local file which actually loaded the front end modules (i.e. c1x02fe.ko, c1susfe.ko, etc).  This was while debugging.  He never put it back.

What was the solution:

I uncommented the following line in /diskless/root/etc/rc.local file on the fb machine:

/opt/rtcds/caltech/c1/target/$i/scripts/startupC1rt

Now on reboot, the c1sus machine should start up all the front ends listed in the rtsystab file, located in /diskless/root/etc/ on the fb machine.

 

  3793   Wed Oct 27 10:53:03 2010 josephbConfigurationComputersWhy doesn't DTT work?!?

Test points for the SUS channels should be there.  They have been working previously this week.  Possibly break down points include awgtpman, mx_streams, and the fb itself.  I'll look into that.

As far as other fast channels, there are no other fast front ends running than the suspensions ones we have.  Until additional channels get connected to the front ends and the models updated, those are the channels we have available.  However I am working on getting c1ioo up and running, and we can try connecting in some PEM channels today to the c1sus front end's 4th ADC.

 

Edit:

I tried starting a fresh instance of the frame builder, but when I brought the old copy down, it left a pair of zombie or dead mx_stream processes running on c1sus . Basically c1mcs and c1rms were still running, while c1x02 and c1sus came down.  I tried to kill the processes but this caused the c1sus machine to crash.  In the past I've killed left over mx_stream processes running after the frame builder has gone down, but I've never seen them crash the computer.  I'm unsure why this happened since we haven't done any updates of the code, just updated models and daq configuration files.

Quote:

DTT has only SUS and "X02" channels under C1 in the drop down channel selection menu.  Basically, we can't measure any fast channels with DTT.  I keep getting the error: "Unable to select testpoints."  Sadface.

Similar things are true for DataViewer.  The same limited number of fast channels, and no data found:

Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Is this a framebuilder problem?  Is this something that the CDS team has on the to-do list?

 

  3792   Wed Oct 27 09:02:29 2010 steveUpdateElectronicsHP4195A is NOT fixed

www.avalontest.com has fixed the 25MHz oscillation.  Contact: Jim Burnham 760-536-0191

Actually, NOT FIXED.

  3791   Wed Oct 27 02:26:15 2010 kiwamuUpdateIOOMC locked

(Rana, Koji, Suresh, Yuta, Thanh, Kiwamu)

 MC was locked successfully !

 Instead of feeding back the signal to the MC length we just injected it to the NPRO pzt with a high voltage (HV) amplifier.

So now we can move on to an in-vac work which needs the main beam to align the stuff.

 


(mode matching to MC)

Suresh and Thanh (a visitor from ANU) improved the mode matching to the MC. 

As written in the entry #3779  the beam after the mode matching lenses were diverging.

It is supposed to converge from 1.7mm radius at the last lens to 1.6 mm radius at the middle point of MC1 and MC2.

They slided the last lens toward the MC to make it more collimated and roughly measured the beam size using a sensor card.

As a fine tuning, they looked at some higher order modes showing up in the MC2 camera, and tried reducing the higher order modes by slightly sliding the last lens.

(assuming the lens position doesn't so much change the alignment)

During the work we removed a steering mirror for green locking because it was on the way of the lens slider.

 

- - measured optics' distances - - 

25.5 cm  from 1st lens to the front surface of the EOM

5.5 cm  length of the EOM

24.5 cm from the front surface of the EOM to the 2nd lens (concave)

15.5 cm  from the 2nd lens to the 1st steering mirror in the zig-zag path

20.5 cm  from the steering mirror to the last lens

 

(preparation for locking) 

Rana, Yuta and Koji prepared an old instant amplifier which can produce +/-13V output instead of usual SR560s.

We added an offset (~5V) on the signal to make it within 0-10V which is the input range of the HV amplifier.

If we take SR560, it's probably not sufficiently wide range because they can handle handle only about +/-4V.

 

We strung a cable from Marconi via the RF stabilizer to the wideband EOM in order to drive the EOM at 24.5MHz.

SInce the EOM doesn't have 50 Ohm input impedance we had to put a 50 Ohm load just before the EOM in order to drive it efficiently.

From a medm screen we set the driving RF amplitude slider (C1:IOO_MCRF_AMPADJ) to 0.0, which provides the maximum RF power on it.

 

(locking mode cleaner)

At first we unlocked the PMC to see an offset in the error signal without any lights on the MC_REFL PD.

Then we adjusted the offset to zero on the MC servo screen.

At the beginning of the locking the PMC was not stable for some reasons during the MC was locked.

But after increasing the laser power to the MC twice bigger, it looks like the PMC and the MC are quite stable.

 

 

  3790   Tue Oct 26 22:57:37 2010 JenneConfigurationComputersWhy doesn't DTT work?!?

DTT has only SUS and "X02" channels under C1 in the drop down channel selection menu.  Basically, we can't measure any fast channels with DTT.  I keep getting the error: "Unable to select testpoints."  Sadface.

Similar things are true for DataViewer.  The same limited number of fast channels, and no data found:

Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Is this a framebuilder problem?  Is this something that the CDS team has on the to-do list?

  3789   Tue Oct 26 21:27:02 2010 JenneUpdateCDSfixed OPLEV stuff and MCL filters

Since MC2_TRANS is, in fact, MC2 Transmission, and not an oplev at all (it's not red, and it's not a lever, although it does use a QPD), I propose that the name be changed to something sensical, since calling it an oplev is completely non-sensical.  The name change should happen sooner rather than later, to avoid confusion.

Quote:

(Joe, Yuta)

Background:

 Today, we fixed OPLEV stuff, MCL filters, and time stamps.

What we did:
 5. Checked OPLEV for MC2 by pointing a laser pointer to QPD. (For MC2, OPLEV is just a transmission beam position monitor)
  Each quadrant looked like they are connected to the right channel numbers.

 

  3788   Tue Oct 26 17:31:17 2010 yutaUpdateCDSfixed OPLEV stuff and MCL filters

(Joe, Yuta)

Background:

 We are currently working on getting rid of "white stuff" in MEDM screens.
 Today, we fixed OPLEV stuff, MCL filters, and time stamps.

What we did:
 1. Plugged in OPLEV cables to ADC2. (See this wiki page for wiring)

 2. Connected ADC2 and OPLEV in Simulink model and fixed MEDM screens for OPLEVs (Attached #1).

 3. Put MCL filters for BS,ITMX,ITMY,PRM,SRM.
  They don't need them, but just for getting rid of "white stuff."
  They are connected to the ground, so the outputs are always 0.

 4. Fixed "TIME_STRING"s in MEDM screens so that they show current time correctly.
  You only need to put text monitor with channel "C1:FEC-DCU_NODE_ID_TIME_STRING" into master files(DEFAULTNAME things) and run generate_master_screens.py.
  It will automatically sets DCU ID correctly!! (Great work, Joe!)
  See this wiki page for more info on making MEDM screens.

 5. Checked OPLEV for MC2 by pointing a laser pointer to QPD. (For MC2, OPLEV is just a transmission beam position monitor)
  Each quadrant looked like they are connected to the right channel numbers.

Plan:
 - figure out what C1:SUS-NAME_MODE_SW1 does and fix
 - fix Whitening, Dewhitening ON/OFF button in main MEDM screens, so that they switch every channels' filters
 - make a new screen for MC (like the old one C1IOO_ModeCleaner.adl)
 - create a new mark for new MEDM screens

Attachment 1: optlevMC2.png
optlevMC2.png
  3787   Tue Oct 26 16:02:55 2010 yutaHowToCDSthings to do after making a new Simulink model

(Joe,Yuta)

Things to do after making a new Simulink model.

1. ssh c1sus, go to /opt/rtcds/caltech/c1/core/advLigoRTS/ and run
 bash ./makestuff.sh c1SYS

 makestuff.sh does;

  make uninstall-daq-$*
  make clean-$*
  make $*
  make install-$*
  make install-daq-$*
  make install-screens-$*
  sed -i 's/RO \(.*SW[12]R.*\)/\1/' /opt/rtcds/caltech/c1/target/$*/$*epics/autoBurt.req


 If you don't need to re-install DAQs or screens, just run line 2,3,4, and 7 and go to step #6.

2. ssh c1sus, go to /opt/rtcds/caltech/c1/scripts/ and run
 sudo ./startc1SYS

 For now, you have to put "1" in "BURT Restore" in GDS screens with in 5-10 secs.

3. Now the DAQ channel numbers are changed. So, go to /cvs/cds/rtcds/caltech/c1/chans/daq/ and run
 ./activateDAQ.py

 activateDAQ will activate the following DAQ channels for every optics with data rate 2048Hz;
  ULSEN_OUT
  URSEN_OUT
  LRSEN_OUT
  LLSEN_OUT
  SDSEN_OUT
  SUSPOS_IN1
  SUSPIT_IN1
  SUSYAW_IN1

4. Restart fb. See this wiki page.
 Basically you what have to do is kill and restart daqd in fb and restart mx_streams in c1sus.

5. DONE! Burt restore if you want.


6. If you don't need to re-install DAQs or screens;
  a. Go to /opt/rtcds/caltech/c1/target/c1SYS/c1SYSepics and run
    sudo rmmod c1SYSfe

  b. Go to /opt/rtcds/caltech/c1/target/c1SYS/bin/ and run
    sudo insmod c1SYSfe.ko

  3786   Tue Oct 26 15:57:10 2010 JenneUpdateSUSOne magnet broken, reglued

[Jenne, Suresh, Thanh (Bram's Grad Student)]

When we removed the grippers from the magnets on the PRM, one of the face magnets broke off.  This time, the dumbbell remained glued to the optic, while the magnet came off.  (Usually the magnet and dumbbell will stay attached, and both come off together).  I had 3 spare magnet-dumbbells, but only one of them was the correct polarization.  The strength of the spare magnet was ~128 Gauss, while the other magnets glued to the PRM are all ~180 Gauss.  We considered this too large a discrepancy, and so elected to reuse the same magnet as before. 

We removed the dumbbell from the optic using acetone.  After the epoxy was gently removed, we drag wiped the AR face of the optic (Acetone followed by Iso, as usual), being careful to keep all the solvent away from all the other glue joints.  We cleaned off the magnet with acetone (it didn't really have any glue stuck on it...most of the glue was stuck on the dumbbell), and epoxied it to a new dumbbell. 

The PRM, as well as the magnet-dumbbell gluing fixture are in the little foil house, waiting for tomorrow's activities.  Tomorrow we will re-glue this magnet to the optic, and Thursday we will balance the optic.  

This still leaves us right on schedule for giving the PRM to Bob on Friday at lunchtime, so it can bake over the weekend.

  3785   Tue Oct 26 12:45:20 2010 yutaHowToCDSmaking a new master file for medm screens

(Joe, Yuta)

 In elog #3708, we showed how to edit all the similar medm screens easiliy.
 But if there are no master files you want to edit in /opt/rtcds/caltech/c1/medm/master/ directory, you can make one.
 Say, you want to edit all the similar medm screens named C1SUS_NAME_XXX.adl.

1. Copy one of C1SUS_NAME_XXX.adl to /opt/rtcds/caltech/c1/medm/master/ directory as C1SUS_DEFAULTNAME_XXX.adl.

2. Go to that directory and
  sed -i 's/NAME/DEFAULTNAME/g' C1SUS_DEFUALTNAME_XXX.adl

3. Add "_XXX.adl" to file_array list in generate_master_screens.py

4. Edit C1SUS_DEFUALTNAME_XXX.adl

5. Run ./generate_master_screens.py

That's all!!

  3784   Tue Oct 26 10:50:08 2010 KojiConfigurationelogELOG 2.8.0 -> ELOG 2.7.5 -> ELOG 2.8.0

ELOG restarted with 2.8.0 again.

- moved elog-2.8.0/script dir to elog-2.8.0/script.orig

- copied elog-2.7.5/script to elog-2.8.0/script

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.8.0

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.8.0

- logbooks on 25th and 26th were copied from 2.7.5 to 2.8.0.

 

  3783   Tue Oct 26 07:02:05 2010 AlbertoConfigurationelogELOG 2.8.0 -> ELOG 2.7.5

Quote:

ELOG reverted to 2.7.5 due to editing difficulties

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.7.5

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.7.5

- logbook dir of 2.8.0 was copied in the dir of 2.7.5. The old and obsolete 2.7.5 was discarded.

I think I had the same problem when I switched to 2.75 from 2.65.

Then the problem was FCKeditor.

We should try the solution I put in the elog page of the wiki.

 

  3782   Tue Oct 26 01:53:21 2010 Joonho LeeUpdateElectronicsFuction Generator removed.

Today I worked on how to measure cable impedance directly.

In order to measure the impedance in RF range, I used a function generator which could generate 50MHz signal and was initially connected to the table on the right of the decks.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

 

To test the VIDEO cables, I need a function generator generating signal of frequency 50 MHz.

In the deck on the right of PSL table, there was only one such generator which was connected to the table on the right of the deck.

Therefore, I disconnected it from the cable and took it to the control room to use it because Rana said it was not used.

Then, I tired to find on how to measure the impedance of cable directly but I did not finish yet.

When I finished today works, I put the generator back to the deck but I did not connect to the previous cable which was initially connected to the generator.

 

Next time, I will finish the practical method of measuring the cable impedance then I will measure the cables with unknown impedance.

Any suggestion would be appreciated.

  3781   Tue Oct 26 00:45:08 2010 ranaUpdatePSLNew NPRO Diagnostic Wiring

Untitled.png

I copy section 6.2 into here to share with you all what the diagnostic capabilities of the new NPRO are. Its not a lot.

We'll need to record a sample of the NPRO output beam on a regular photodiode in order to get a real power monitor. My plan is to use a regular 25-pin Dsub and run it fron the NPRO controller over to the PSL rack and hijack the old MOPA monitoring channels (3113 and 3123 ADCs).

  3780   Mon Oct 25 23:59:37 2010 KojiConfigurationelogELOG 2.8.0 -> ELOG 2.7.5

ELOG reverted to 2.7.5 due to editing difficulties

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.7.5

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.7.5

- logbook dir of 2.8.0 was copied in the dir of 2.7.5. The old and obsolete 2.7.5 was discarded.

  3779   Mon Oct 25 23:10:06 2010 KojiUpdateIOOMC is now flashing

[Suresh / Koji]

The MC mirrors are aligned. Now the flashing of the resonances are visible on the MC2 CCD

although the modematching seemed pretty poor.


- The incident power was adjusted to be ~20mW by rotating HWP after the laser source.
The power before the window of the chamber was ~450mW. Where are those missing 1.5W?

- We checked the spot on the last two steering mirrors and the incident beam on MC1.
The beam was too much off from the center of the 1st steering mirror. It was also hitting 1cm north of the MC1.
We adjusted the steering mirrors such that the incident and reflected beams are symmetrically visible at the MC1 tower.

- The MC mirrors are aligned. We first tried to use only MC2 and MC3. And then we used MC1 too as the spot on the MC2 was too high.

- We saw some TEM00 flashes but with many other modes flashing. We checked the beam diameter on the PSL table and on the MC REFL.
The latter one looked twice large as the former one. We concluded the beam is diverging.

- We closed the tank and decided to work on the mode matching tomorrow.

  3778   Mon Oct 25 20:20:59 2010 yuta, JoeUpdateCDSDAQ channel number etc
Summary:
We split the old SDSEN filters to SDSEN, SDSIDE, SDCOIL last week.
Along with this change, the TP channel number changed unfortunately.
So, we fixed them.
Also, we made FM9 do the output filter analog/digital switching.

What we did:
1. Changed the Simulink logic so that FM9 do the output filter switching, and checked the logic by probing
MAX333A for SDCOILs.

2. After making a new Simulink model and rebuilding, run the following incantation to burt restore filter
settings in /opt/rtcds/caltech/c1/target/c1SYS/c1SYSepics/ (See elog #3706)
sed -i 's/RO \(.*SW[12]R.*\)/\1/' autoBurt.req

3. DAQ channel numbers are listed in C1SYS.ini files in /cvs/cds/rtcds/caltech/c1/chans/daq/.
Channels with # signs are not activated. So, we changed, for example,

#[C1:SUS-MC1_LLSEN_IN1_DAQ]
#acquire=0
#datarate=16384
#datatype=4
#chnnum=10208

to

[C1:SUS-MC1_LLSEN_IN1_DAQ]
acquire=1
datarate=2048
datatype=4
chnnum=10208

for all channels we want to look at.

4. Restarted fb.

Plan:
- measure TFs and see if input and output filter switchings are working correctly
- make a switch that does all filter switching for all 5 OSEMS or 5 COILS
- put optical lever stuff
- fix offset sliders and offset switch
- put F2A filters in TO_COIL matrix (see elog #3769)
- make a nice graphical screen for MCs (like /cvs/cds/caltech/medm/c1/ioo/C1IOO_ModeCleaner.adl)
- write a script that activates DAQ we need
- make a plan

* SYS=SUS, RMS, MCS, etc
ELOG V3.1.3-