The cause is apparent! The connectors on the cables are wrong!
Currently only 50% of the pin length goes into the connector!

Please remember to cover the optical tables !

I just wanted to remind you that the most up to date resource about the RF system upgrade, including photodiodes, is the SVN.

https://nodus.ligo.caltech.edu:30889/svn/trunk/alberto/40mUpgrade/RFsystem/

https://nodus.ligo.caltech.edu:30889/svn/trunk/alberto/40mUpgrade/RFsystem/RFPDs/REFL11/REFL11Schematics/40mUpgradeREFL11schematic.pdf

Because I was doing new things all the time, the wiki is not up to date. But the SVN has all I've got.

(Suresh, Yuta)

Background:
  Previous A2L measurement is based on the assumption that actuator efficiencies are identical for all 4 coils.
  We thought that the unbelievable "tilt" may be caused by imbalance of the coils.

Method:
  1. Setup an optical lever.
  2. Dither the optic by one coil and demodulate oplev outputs(OL_PIT or OL_YAW) in that frequency.
  3. Compare the demodulated amplitude. Ideally, the amplitude is proportional to the coil actuation efficiency.

What we did:
[MC2]
  MC2 is the least important, but the easiest.
  1. Placed a red laser pointer at MC2 trans table. During the installation, I moved the mirror just before QPD.
  2. Made a python script that measures coil actuation efficiency using the above method. I set the driving frequency to 20Hz.
  It is /cvs/cds/caltech/users/yuta/scripts/actuatorefficiency.py.
  The measurement result is as follows. Errors are estimated from the repeated measurement. (Attachment #1)

MC2_ULCOIL 1
MC2_URCOIL 0.953 ± 0.005
MC2_LRCOIL 1.011 ± 0.001
MC2_LLCOIL 0.939 ± 0.006

[MC1]
  For MC1, we can use the main laser and WFS1 QPD as an oplev.
  But we only have slow channels for QPD DC outputs(C1:IOO_WFS1_SEG#_DC).
  So, we intentionally induce RF AM by EOM(see Kiwamu's elog #3888) and use demodulated RF outputs of the WFS1 QPD(C1:IOO_WFS1_I/Q#) to see the displacement.
  1. Replaced HR mirror in the MCREFL path at AP table to BS so that we can use WFS1.(see Koji's elog #3878)
    The one we had before was labeled 10% pick-off, but it was actually an 1% pick-off.
  2. Checked LO going into WFS1 demodulator board(D980233 at 1X2).
    power: 6.4dBm, freq: 29.485MHz
  3. Turned on the hi-voltage(+100V) power supply going into the demodulator boards.
  4. Noticed that no signal is coming into c1ioo fast channels.
    It was because they were not connected to fast ADC board. We have to make a cable and put it in.

[MC3]
  Is there any place to place an oplev?

Plan:
 - prepare c1ioo channels and connections
 - I think we'd better start A2L again than do oplev and coil balancing.

(Koji, Jenne, Yuta)

We found one of DAC cables had a poor contact.
That probably caused our too much "tilt" of the beam into MC.

Story:
  From the previous A2L measurement and MC aligning, we found that the beam is somehow vertically "tilted" so much.
  We started to check the table leveling and the beam height and they looked reasonable.
  So, we proceeded to check coil balancings using optical levers.
  During the setup of optical levers, I noticed that VMon for MC1_ULCOIL was always showing -0.004 even if I put excitation to coils.
  It was because one of the DAC cables(labeled CAB_1Y4_88) had a poor contact.
  If I push it really hard, it is ok. But maybe we'd better replace the cable.

What caused a poor connection?:
  I don't know.
  A month ago, we checked that they are connected, but things change.

How to prevent it:
  I made a python script that automatically checks if 4 coils are connected or not using C1:IOO_LOCKIN oscillator.
  It is /cvs/cds/caltech/users/yuta/scripts/coilchecker.py.
  It turns off all 3 coils except for the one looking at, and see the difference between oscillation is on and off.
  The difference can be seen by demodulating SUSPOS signal by oscillating frequency.
  If I intentionally unplug CAB_1Y4_88, the result output for MC1 will be;

==RESULTS== (GPS:973512733)
MC1_ULCOIL      0.923853382664 [!]
MC1_URCOIL      38.9361304794
MC1_LRCOIL      55.4927575177
MC1_LLCOIL      45.3428533919

Plan:
 - Make sure the cable connection and do A2L and MC alignment again
 - Even if the cables are ok, it is better to do coil balancings. See the next elog.

[Koji and Kevin]

I was trying to characterize the REFL11 photodiode by shining a flashlight on the photodiode and measuring the DC voltage with an oscilloscope and the RF voltage with a spectrum analyzer. At first, I had the photodiode voltage supplied incorrectly with 15V between the +15 and -15 terminals. After correcting this error, and checking that the power was supplied correctly to the board, no voltage could be seen when light was incident on the photodiode.

We looked at the REFL55 photodiode and could see ~200 mV of DC voltage when shining a light on it but could not see any signal at 55 MHz. If the value of 50 ohm DC transimpedance is correct, this should be enough to see an RF signal. Tomorrow, we will look into fixing the REFL11 photodiode.

[Suresh, Jenne]

We have put together the new-old ETM towers.  These are the ones which were hanging out on the flow bench down the arm for years and years, and have recently been re-baked.  Interestingly, these are predominantly steel, whereas the newer ones are mostly aluminum.  This caused momentary drama while we scrounged for the correct screws (we needed more silver-plated screws than anticipated, since we were screwing into steel and not aluminum), however the miscellaneous clean hardware collection came to the rescue.  We did however use up all of the 1/4-20 3/4" silver plated screws, so hopefully no one else needs more later...

We only found 5 (enough for one of the two towers) spring plungers which are used to hold the OSEMs in place.  Suresh is sending an email to Steve to ask him to buy some more, so we can get them cleaned in time for use.  This is important, but not super urgent, since we have ~ 2 weeks before the ETMs will be ready for installation. 

Koji has not yet had a chance to inspect the ETM data sheets and choose for us which pair of ETMs to use (ATF sent the 4 ETMs in matched pairs).  So we will not begin the "arts and crafts" until tomorrow-ish.

For Yuta's business, I intentionally misaligned the wideband EOM slightly to Yaw direction.  Good luck.

It should show a big AM component at photo detectors.

I touched only the top right knob on the EOM mount and tweaked it by exactly  2 turns in counterclockwise direction.

1. Look at the Faraday.

2. Look at the wiki. There is the optical layout in PNG and PDF.

3. 5% (0.8mm) and 2.5%(0.4mm) sounds a big difference for the difficulty, but if you say so, it is not so different.

Actualy, if you can get to the 5% level, it is easy to get to the 1-2% level as I did last time.
The problem is we are at the 15-20% level and can not improve it.

1. We didn't measure the aperture size last night. We have to check that.

2. We have to measure the length of FI. Or find a document on this FI.

3. Yes, 5%/sqrt(4). But I didn't think the factor of 2 is important for this kind of estimation.

It didn't make sense in several points.

1. Is the Faraday aperture really 3mm? The beam has the gaussian radius of ~1.5mm. How can it be possible to go through the 3mm aperture?

2. Why the MC3-FT distance is the matter? We have the steering mirror after MC3. So we can hit the center of the Faraday.
But if we have VERTICAL TILT of the beam, we can not hit the center of the Faraday entrance and exit at the same time.
That would yield the requirement.

3. If each coil has 5% variance in the response, variance of the nodal point (measured in % of the coil imbalance) by those four coils will be somewhat better than 5%, isn't it?

(Suresh, Yuta)

Summary:
  We need MC to be locked and aligned well to align other in-vac optics.
  We continued to align the incident beam so that the beam passes the actuation nodes of MC1 and MC3.
  From the previous measurement, we found that beam height at IM1 has to be increased by ~3cm.
  Today, we increased it by ~1cm and achieved about 1/3 of the required correction.
  But we cannot proceed doing this because the beam is hitting IM1 at the edge already.

What is the goal of this alignment?:
  If the beam doesn't hit MC optics in the center, we see angle to length coupling, which is not good for the whole interferometer.
 
  Also, if the beam is tilted so much, transmitted beam though MC3 cannot go into FI at right after MC3.
  Say, FI has an aparture of 3mm and MC3-FT distance is 300mm. The beam tilt should be smaller than 3/300 rad. MC1-MC3 distance is 200mm, so the displacement at each mirror should be smaller than ~1mm.
  1mm is about 7% (see Koji's elog #2863) TO_COIL gain imbalance in A2L measurement.
 
  We are currently assuming that each coils are identical. If they have 5% variance, it is meaningless to try to reduce the beam displacement less than ~5%.

  So, we set the goal to 7%.

What we did:
  1. Leveled the MC table.

  2. Measured the table height using DISTO D3 laser gauge.
    PSL table 0.83m (+-0.01m)
    OMC table 0.82m
    MC table  0.81m

  3. Using the last steering mirror(SM@PSL) and IM1, tilted the beam vertically

Result:


  At t=0 (this morning), the beam tilt was ~40%/(MC1-MC3 distance). Now, it is ~30%/(MC1-MC3 distance).
  30%/(MC1-MC3 distance) is ~5/200 rad.

Plan:
 We have to somehow come up with the next story. Too much vertical tilt. What is wrong? Table leveling seems OK.
 - measure in-vac beam height
 - maybe OSEMs are badly aligned. we have to check that.

(Suresh, Yuta)

Background:
  Last week, we reduced the common mode displacement of the beam through MC1 to MC3. 
  Next work is to tilt the beam and center it.

What we did:
  1. Changed the offset going into 1201 Low Noise Amplifier(1201 is for adding +5V offset so that the feedback signal will be in the range of 0-10V)
  2. Using the last steering mirror(SM@PSL) and IM1, tilted the beam
  3. As the beam height changed alot(~0.5cm higher at IM1), MC1 reflection could not reach MCREFL PD. So, we tilted the mirror just after MC1, too.

Result:


Plan:
  - continue to tilt IM1 in small increments in order to reduce PIT/YAW to length coupling
      If large increments, it takes so much time re-aligning MC to get flashing!

By the way:
    The signal we kept saying "MCL" was not the error signal itself. It was a feed back signal(output of the mode cleaner servo board). The cable labeled "MC REFL" is the error signal. Compare MEDM screen C1IOO_MC_SERVO.adl and the mode cleaner servo board at 1X2. You will be enlightened.

Increased the transimpedance gain of the MC-Trans-Mon QPD ckt

The gain of this QPD was insufficient to see the light transmitted through the MC2.  The resulting voltage output was about  10 steps of the 16-bit ADC card.  As the input power, which is currently held at about 40mW may be increased to the vicinity of 2W (total output of the NPRO) we would have 500 ADC steps.  But the dynamic range of the ADC is 64k and  increasing the gain of this QPD ckt by a factor of 50 would enable us to utilise this dynamic range effectively.  However as we do not need a response faster than 10Hz from this ckt its response time has been limited by increasing the feedback capacitance value.

The ckt diagram for the QPD ckt is D980325-Rev-C1  .  The particular unit we are dealing with has the Serial No. 110.  The resistors R1, R2, R3, R4 are now 499 kOhm.  As per the guidelines in the ckt diagram, we increased the capacitance values C3,C4,C5,C6 to 2.2 nF.  The current cut off frequency for the MC-Trans-Mon is 145 Hz (computed).

Initially, while reassembling the QPD unit, the IDC 16 connector to the ckt board was reversed by mistake and resulted in the OP497 chip over-heating.  Consequently one of the opamps on the chip was damaged and showed monotonously increasing ouput voltage.  Todd Etzel gave us a spare OP497 and I replaced the damaged chip with this new one. The chips are also available from  Newark Stock No. 19M8991 . The connector has been marked to indicate the correct orientation. The ckt was checked by temporarily connecting it in the place of the PRM Optical lever QPD.  It worked fine and has been put back in its place at the MC2 Transmission.  The QPD was wiped with a lens tissue+Methanol  to remove dust and finger prints from its surface.

It may need to be repositioned since the beam would have shifted under the MC realignment procedure.

Bad; there should be a passive ~1 MHz LP filter between the mixer and anything that comes after. The SR560 + mixer does not equal a demodulator.

We added the following line to the cshrc.40m file in the 64-bit linux and 32-bit linux sections:

setenv LIGONDSIP fb

This allows codes like tdsdmd to work properly on the linux machines (seemed to already work fine on the solaris op440m without this change).

I measured the open loop transfer function of the 80MHz VCO's PLL while locking it to Marconi.

 This measurement is for a health check and a characterization of the PLL

The transfer function looks good, it agrees with the designed filter shape.

(measurement setup) 

 The frequency of Marconi is set to 79.5MHz which is the center frequency of the VCO.

The signal from Marconi is mixed down with the VCO signal at a mixer ZLW-3SH.

Then the demodulated signal goes to a 80MHz LPF to cut off high frequency components.

And it goes through a control filter which has 1Hz pole and 40Hz zero (see this entry).

The 80MHz LPF, the controls filter, the VCO and the RF amplifier are all built in the box.

 In order to measure the open loop transfer function I inserted SR560 before the 80MHz LPF.

Using T-splitters the input and the output of SR560 are connected to a spectrum analyzer SR785.

(results)

 Exciting the system using a source channel of SR785, I measured the open loop transfer function.

The unity gain frequency was measured to about 20 kHz.

It agrees with the designed filter shape (though the gain factor is a little bit underestimated).

Apparently there is a phase delay at high frequency above 10kHz, but it is okay because the phase margin is quite acceptable up to 100kHz.

However I found that the control range was quite narrow.

The PLL was able to be kept in only +/- 1MHz range, this fact was confirmed by shifting the frequency of Marconi during it's locked.

I will post another elog entry about this issue.

 (notes)

 Marconi power = 6dBm

 VCO power after RF amp. = -0.6 dBm

 Marconi frequency = 79.5 MHz

 Phase detection coefficient = 0.4 V/rad (measured by using an oscillo scope)

As MC2 Trans mon QPD is temporary removed for fixing, we needed a reference for the MC alignment.

I replaced the 10% pick-off in the MCREFL path to the HR mirror.
Now the MCREFL DC with MC unlock is ~2.2, while it is ~0.29 in lock.
i.e. The visibility is 87%.

This means that the MCWFS were disabled for the moment.

As part of the effort to debug what was happening with the slow computers, I disabled the auto MEDM snapshots process that Yoichi/Kakeru setup some long time ago:

https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

We have to re-activate it now that the MEDM screen locations have been changed. To do this, we have to modify the crontab on nodus and also the scripts that the cron is calling. I would prefer to run this cron on some linux machine since nodus starts to crawl whenever we run ImageMagick stuff.

Also, we should remember to start moving the old target/ directories into the new area. All of the slow VME controls are still not in opt/rtcds/.

(Koji, Suresh, Yuta)

Summary:
  We need MC to be locked and aligned well to align other in-vac optics.
  By using a new python script A2L.py(see elog #3863), we are measuring A2L coupling and centering the beam.
  Tonight's goal was to reduce common mode displacement of the beam through MC1 to MC3, and we succeeded.

Strategy of beam centering:
  We first ignore the beam position at MC2 and focus on MC1,MC3. If MC1,MC3 alignments are given, MC2 alignment is determined.

  For MC1 and MC3, we first reduce the common mode displacement using the last steering mirror at PSL table.
  The last steering mirror makes translation of the incident beam because it is far (~m) from the MC.
  So,
    1. Rotate the steering mirror nob a little
    2. Lock MC so that MC beam axis will be the same as the incident beam axis
    3. A2L measurement
    4. To 1-3 over until the beam crosses MC1 center to MC3 center axis
        The amount of vertical/horizontal displacements of the beam spot at MC1 and MC3 should be the same.
        From our convention, for vertical, MC1 and MC3 should have opposite sign. For horizontal, same sign. (see picture below)

Result:

 
  From the A2L measurement, now the beam spot is lower right at MC1 and upper right at MC3.
 

  The directions of the beam spot motion agree with the steering mirror tilts.
  Also, the amount of the motion seems reasonable.
    1 tooth rotation of the steering mirror nob makes ~1e-3 inch push which equals to ~0.5mrad rotation.
    The steering mirror to MC is like ~2m and 0.5mrad mirror tilt makes ~2mm displacement at the MC optics.
    2mm displacement is ~15% at the mirror (see Koji's elog #2863;note that coil-coil distance is 1/sqrt(2) of the mirror diameter).
    The measured vertical spot motion is ~15%/1tooth. Horizontal is sqrt(2) times bigger because of the angle of the MC1, MC3 and they are about that much, too.

Plan:
 - Use IM1 to make beam tilt and finally center the beam
 - Improve the script so that it features weighting in fitting
 - Write a script that balances actuation efficiency of the 4 coils.
     We are currently assuming that 4 coils are well balanced.
     In order to do the balancing, we need to balance OSEMs too.

i took some pictures with the dinocam this afternoon. I used the laptop computer next to it using wireless lan connection to the caltech network to send the pictures to me.

The installed anti virus software was bitching about the old database and wanted to update that. As the installed virus definition database was from mid last year i agreed and started downloading the update. As the file was huge (~100MB) it wasn't finished when i left. computer is still running and probably waiting for instructions.

Will come back on the weekend to finalize the new virus definition file database installation.

[Suresh, Koji]

- Removed MCT optics in the IMC chamber

- Rotated MC1 and MC3 in clock-wise to debias the YAW bias offsets (-5V and -8V to -1.5V and -0.5V).

- Adjusted insertion of the MC1 OSEMs so as to have the outputs of about 1.0V.

- Locked to TEM00. Trying to get the beams at the center of the mirror using Yuta's A2L.

We like to have the MC TRANS channels so that we can run all of our old scripts and trends on it. This is the usual BROWN

channel that's on the LockMC screen. Its also the thing that we use for thresholding to activate the MC Autolocker Daemon.

I modified the ioo.db file in the target/c1iool0/ directory so that the MC_TRANS_SUM, _P, and _Y channels are all now just

CALC records of the MC2 OL channels (where the calculation is MC_TRANS_SUM = MC2 OL_SUM + 0.001, etc.). I then

rebooted c1iool0 a few times to get the syntax right. It SEEMS to be working now. I'm sure that this won't effect anything.
I've committed the new file to the SVN repo. Once Suresh is done hacking the QPD circuit, we can set the threshold in the Autolocker.

The moral of the story is, PUT THINGS IN THE ELOG. This wild process is one of those things where people say 'this won't effect anything', but in fact it wastes several hours of time.

Joon Ho and I took a look at the RF stuff that Alberto left, and we determined that we've got most everything that we need.  On Monday, Joon Ho will list off the stuff that we're missing, and we'll have Steve order it.

Joon Ho also replaced the temporary front panel to the RF generation box with Alberto's fancy new panel.  Pics are here (although you have to sign in as foteee to see them). 

Work on the frequency distribution box will continue on Monday.

Problem:

We couldn't set testpoints on the c1ioo machine.

Cause:

Awgtpman was getting into some strange race condition.  Alex added an additional sleep statement and shifted boot order slightly in the rc.local file.  This apparently is only a problem on c1ioo, which is a Sun X4600.  It was using up 100% of a single CPU for the awgtpman process.

Status:

We now have c1ioo test points working.

Future:

Need to examine the startc1ioo script and see if needs a similar modification, as that was tried at several points but yielded a similar state of non-functioning test points. For the moment, reboot of c1ioo is probably the best choice after making modifications to the c1ioo or c1x03 models.

Current CDS status:

Problem:

The 40m computers were responding sluggishly yesterday, to the point of being unusable.

Cause:

The mx_stream code running on c1iscex (the X end suspension control computer) went crazy for some reason.  It was constantly writing to a log file in /cvs/cds/rtcds/caltech/c1/target/fb/192.168.113.80.log.  In the past 24 hours this file had grown to approximately 1 Tb in size. The computer had been turned back on yesterday after having reconnected its IO chassis, which had been moved around last week for testing purposes - specifically plugging the c1ioo IO chassis in to it to confirm it had timing problems.

Current Status:

The mx_stream code was killed on c1iscex and the 1 Tb file removed.

Computers are now more usable.

We still need to investigate exactly what caused the code to start writing to the log file non-stop.

Update Edit:

Alex believes this was due to a missing entry in the /diskless/root/etc/hosts file on the fb machine.  It didn't list the IP and hostname for the c1iscex machine.  I have now added it.  c1iscex had been added to the /etc/dhcp/dhcpd.conf file on fb, which is why it was able to boot at all in the first place.  With the addition of the automatic start up of mx_streams in the past week by Alex, the code started, but without the correct ip address in the hosts file, it was getting confused about where it was running and constantly writing errors.

Future:

When adding a new FE machine, add its IP address and its hostname to the /diskless/root/etc/hosts file on the fb machine.

(Suresh, Kiwamu, Yuta)

Summary:
  Lastnight, we locked the MC and tried angle to length(A2L) measurement using my new python script (see elog #3863).
  Although the amount of position script shows looks too big, the response seemed somewhat reasonable.
  Using the results of A2L measurement, we managed to reduce the displacement from the center of the MC optics, but we lost TEM00 mode after changing the incident beam direction and PMC lock got off .
  We restored the alignments and now it is 00, but the displacements got worse than the best we achieved last night.

  I think I have to rethink how to align MC. Even if I could somehow get exact position of the beam, how to align the beam to the center of the optics?

What we did:
  1. At first we tried to align by changing the direction of the incident beam. We found that A2L.py shows opposite direction(lower <-> upper). It was because of my misunderstanding and we agreed that the direction is opposite.

  2. Aligned MC optics without changing the direction of the incident beam. We could understand which directions decrease the displacements from the center, and managed to decrease them.

  3. There seemed to be a limit in aligning the MC optics without changing the incident beam direction. So, we started to change the incident beam direction again by steering mirrors at PSL table.

  4. During the change, PMC lock got off. We restored it, but we lost MC's 00 mode.

  5. We restored MC 00 mode, and measured the final A2L. The result was worse than we achieved by step #2.

Result:
  The final result from last night using my script was as follows;

  % is the length compared to the half of coil to coil length. Low / right are positive.
  We can see the beam position got better by looking at the monitor from MC2, and the A2L measurement result agrees with that.

  Here's some pictures from the measurement last night. Each plots are not taken at the same time.

   (It was painful using slow computers to make measurement. The StripTool graph shows straight lines when computers got frozen)

Plan:
 - Plan a strategy
 - The script needs self-estimation of the measurement. Now, the script fits the plot assuming every data has the same error.
 - When the beam is near the center, the signal gets smaller and the result will be unreliable. One thing I can do is to change TO_COIL gains radically so that the axis of rotation go far from the center.

Physical Electronics: Vac-Seal #288-6000 arriving Monday. Our last bag used last week had a p/n 1002003 with expiration date   .....2009 ? and it was stored in the

refrigerator all times. We are getting 68 small bags.

We should have precision gluing notes of epoxies/procedures used on our sus upgrade.

All the temporary changes to the video cables and the video MUX ( 3843 ) have been reversed and the system returned to its original state.

The Fluke Visual Fault locator (Visifault) arrived and I used it to couple 1064nm light into the single mode fibre at the south-end-table.

Procedure used:

When the output end of the fiber is plugged into the Visifault the light emerges from at the south end (input side for 1064nm).  This light is collimated with the fiber coupler at that end and serves as a reference for the optical axis along which the 1064 light must be directed.  Once the two beams (red and 1064) are overlapped with the beam steering mirrors, the Visifault was disconnected from the fiber and the  fibre output ( 1064 at the PSL table) is maximized by walking the beam at the input end and adjusting the collimation at the input.

The output of the fiber has been collimated with a fiber coupler.

7.5mW are incident on the input end and 1.3mW have been measured at the output.    This output power is adequate for the observing the beats with PSL NPRO.

Koji, Suresh and Steve,

The beam scanner is back from repair.  Koji and Suresh helped to move the I/O address jumpers on the interface card from default position  300 to 320

It is working again.

Summary:
  I wrote a python script for A2L measurement.
 Currently it is really primitive, but I tested the basic functionality of the script.
 We already have A2L script(at /cvs/cds/rtcds/caltech/c1/scripts/A2L) that uses ezlockin, but python is more stable and easy to read.

A2L measurement method:
  1. Dither a optic using software oscillator in LOCKIN and demodulate the length signal by that frequency.
  2. Change coil output gains to change the pivot of the dithering and do step 1.
  3. Coil output gain set that gives the smallest demodulated magnitude tells you where the current beam spot is.

  Say you are dithering the optic in PIT and changing the coil gains keeping UL=UR and LL=LL.
  If the coil gain set UL=UR=1.01, LL=LR=-0.99 gives you demodulated magnitude 0, that means the current beam spot is 1% upper than the center, compared to 1/2 of UL-LL length.
  You do the same thing for YAW to find horizontal position of the beam.

Description of the script:
  Currently, the script lives at /cvs/cds/caltech/users/yuta/scripts/A2L.py
  If you run;
     ./A2L.py MC1 PIT
  it gives you vertical position of the beam at MC1.

  It changes the TO_COIL matrix gain by "DELTAGAINS", turns on the oscillator, and get X_SIN, X_COS from C1IOO_LOCKIN.
  Plots DELTAGAINS vs X_SIN/X_COS and fit them by y=a+bx+cx^2.(Ideally, c=0)
  Rotates (X_SIN, X_COS) vectors to get I-phase and Q-phase.
    (I,Q)=R*(X_SIN,X_COS)
  Rotation angle is given by;
    rot=arctan(b(X_COS)/b(X_SIN))
  which gives Q 0 slope(Ideally, Q=0).
  x-intercept of DELTAGAINS vs I plot gives the beam position.

Checking the script:
  1. I used the same setup when I checked LOCKIN(see elog #3857). C1:SUS-MC2_ULCOIL output goes directly to C1:IOO-LOCKIN_SIG input.

  2. Set oscillator frequency to 18.13Hz, put 18.13Hz band-pass filter to C1:IOO-LOCKIN_SIG filter module, and put 1Hz low-pass filter to C1:IOO-LOCKIN_X_SIN/X_COS filter modules.
        Drive frequency 18.13Hz is same as the previous script(/cvs/cds/rtcds/caltech/c1/scripts/A2L/A2L_MC2).

  3. Ran the script. Checked that Q~0 and rot=-35deg.

  4. Put phase shifting filter to C1:IOO-LOCKIN_SIG filter module and checked Q~0 and rotation angle.
     fitler rot(deg)
     w/o    -35
     +90deg  45
     -90deg  56
     -45deg -80

  5. Put some noise in C1:SUS-MC2_ULCOIL by adding SUSPOS feedback signal and ran the script.(Attachment #1)
      During the measurement, the damping servo was off, so SUSPOS feedback signal can be treated as noise.

Conclusion:
  The result from the test measurement seems reasonable.
  I think I can apply it to the real measurement, if MCL signal is not so noisy.[status: yellow]

Plan:
  - add calculating coherence procedure, averaging procedure to the script
  - add setting checking procedure to the script
  - apply it to real A2L measurement

Bay the way:
  Computers in the control room is being so slow (rossa, allegra, op440m, rosalba). I don't know why.

8 pieces of 10" CF blanks were shipped to MIT

Problem:

We can't access any of the c1ioo computer testpoints.  Dataviewer and DTT both fail to read any data from them.

According to diag -l (when run on Rosalba in /opt/apps), the testpoints are not being set.  Also at some point during the day when debugging, we also somehow messed up all the front end connections to the framebuilder.

Errors reported by dataviewer:

Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek
Server error 12: no such net-writer
Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek
Server error 12: no such net-writer
read(); errno=0
Server error 6532: invalid channel name
Server error 16080: unknown error
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Error reported by daqd.log:

[Thu Nov  4 13:29:35 2010] About to request `C1:IOO-MC1_PIT_IN1' 10022
on node 34
[Thu Nov  4 13:29:35 2010] Requesting 1 testpoints; tp[0]=10022; tp[1]=32531

[Thu Nov  4 13:29:35 2010] About to request `C1:SUS-MC2_SUSPOS_IN1'
10094 on node 36
[Thu Nov  4 13:29:35 2010] Requesting 1 testpoints; tp[0]=10094; tp[1]=32531

[Thu Nov  4 13:29:38 2010] ETIMEDOUT: test point `C1:IOO-MC1_PIT_IN1'
(tp_num=10022) was not set by the test point manager; request failed
[Thu Nov  4 13:29:38 2010] About to clear `C1:IOO-MC1_PIT_IN1' 10022 on node 34

Attempted Fixes:

Remove all daq related files: /opt/rtcds/caltech/c1/target/gds/param/tpchn_c1ioo.par and /opt/rtcds/caltech/c1/chans/daq/C1IOO.ini.  Rebuilt the front end code.

Double checked ethernet connection between c1ioo and the daq router and fb. 

Confirmed open mx was running on c1ioo. Confirmed awgtpman was running (although at one point I did find duplicate awgtpman running for c1x03, the IOP associated with c1ioo).

Rebooted the c1ioo machine. Confirmed all necessary codes came back.

Restarted the daqd process several times on the fb machine.

Current Status:

Framebuilder is running, and c1sus testpoints are available.  c1ioo test points are not.  Waiting to hear back from Alex on possible ideas.

Feature Requested:

Have the CPU_meter change change color at various alarm levels.  These alarm levels have been set at 2/3 maximum for Minor alarm (yellow) and 9/10 maximum for Major alarm (red).

Implementation:

Rather than hand code each EPICS .db file to add the alarm files each time we rebuild the front ends, I decided to modify it at the source (since it strikes me as a generally useful alarm level for all front end codes).

First, I modified the feCodeGen.pl script.

I changed

print EPICS "OUTVARIABLE FEC\_$dcuId\_CPU_METER epicsOutput.cpuMeter int ai 0 field(HOPR,\"$rate\") field(LOPR,\"0\")\n";

to

print EPICS "OUTVARIABLE FEC\_$dcuId\_CPU_METER epicsOutput.cpuMeter int ai 0 field(HOPR,\"$rate\") field(LOPR,\"0\") field(HIGH,\"$two_thirds_rate\") field(HSV,\"MINOR\") field(HIHI,\"$     nine_tenths_rate\") field(HHSV,\"MAJOR\")\n";

I added the following two lines just before it as well:

$two_thirds_rate = int($rate * 2 / 3);

$nine_tenths_rate = int($rate * 9 / 10);

However, only the first four fields were actually added to the database file.  Apparently fmseq.pl, which populated the database, was hard coded to only handle up to 4 fields.

I modified the fmseq.pl script in /opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/util/ so as to be able to handle up to 6 field values when writing EPICS .db files.

This change was accomplished by simply changing the following line

($junk, $v_name, $v_var, $v_type, $ve_type, $v_init, $v_efield1, $v_efield2, $v_efield3, $v_efield4 ) = split(/\s+/, $_);

to 

($junk, $v_name, $v_var, $v_type, $ve_type, $v_init, $v_efield1, $v_efield2, $v_efield3, $v_efield4, $v_efield5, $v_efield6 ) = split(/\s+/, $_);

everywhere it occurred.  There were something like 10 instances of it. Also, I added the two lines

        $vardb .= "    $v_efield5\n";
        $vardb .= "    $v_efield6\n";

after each set of

         $vardb .= "    $v_efield1\n";
         $vardb .= "    $v_efield2\n";
         $vardb .= "    $v_efield3\n";
         $vardb .= "    $v_efield4\n";

Lastly, I modified the CPU_METER bar graph on the C1SUS_DEFAULTNAME.adl screen (located in /opt/rtcds/caltech/c1/medm/master/) to use alarm levels, and then ran generate_master_screens.py.

[Kiwamu, Suresh]

We decided to use the 1064nm beam reflected from the Y1-1037-45-P mirror after the collimation lens following the doubling crystal for coupling into the optical fiber (ref 3843 and 3847 ).

We replaced a beam dump which was blocking this beam with a Y1-1037-45-P mirror and directed the beam into the fiber coupler with another Y1-1037-45-P.  The power in this beam was about 1W.  This has been stepped down to 10mW by introducing a reflective ND filter of OD=2.  The reflected power has been dumped into a blade-stack beam dump.

Steve has ordered the The Visual Fault Locator from Fluke.  It is expected to arrive within a day or two.

I looked at this web page: http://www.teledyne-cougar.com/Index.asp for the RF company that Rich has recently started using.

There are ~15 amplifiers that they sell which have a NF < 2 dB and work in the 10-100 MHz band. We should call them to find out if they will package some amps for us or at least sell us a few with eval. boards so that we can make our own.

(Joe, Yuta)

Summary:
  LOCKIN(consists of oscillator and demodulator) is needed for A2L measurement.
  So, we put LOCKIN to c1ioo model, whose outputs goes to c1mcs ASC.
  After that, I checked the functionality of LOCKIN by directly connecting DAC output for a coil to ADC input for MCL with BNC cable.

What we did:
[Putting LOCKING to c1ioo model]
1. Copied Simulink LOCKIN stuff(cdsOsc, Product, cdsPhase ...) from /cvs/cds/caltech/cds/rward-advLigo/src/epics/simLink/omc.mdl and put it into c1ioo model.

2. Copied MEDM screen file /cvs/cds/caltech/medm/c1/omc/C1OMC_LSC_LOCKIN.adl and modified it for our use.

[Checking LOCKIN]
3. Disconnected MC2_ULCOIL input to SOS Coil driver at 1X4-1-6A and checked the signal from software oscillator at c1ioo is coming.

4. Disconnected the cable labeled "MC OUT1" at 1X2 (which is MCL signal to ADC) and put MC2_ULCOIL output directly using long BNC cable.

5. Checked the functionality of LOCKIN by StripTool.
   The cable wiring did not conflict with my expectation.
   Software mixer is working.(frequency is doubled. X_SIN has offset and X_COS doesn't)

6. Put the cables back.

Result:
  Thanks to c1rfm, c1ioo and c1sus are talking without ADC timeout.
  Also, LOCKIN is working fine.

I moved the lens just before the PMC to check the mode matching landscape. The PMC trans went up from ~6.5 to ~6.8. That's 5% with ~1 hour of work.

As per the micrometer, this took ~7-8 mm of travel. Since there's so much power left in the HOMs, we we we will have to do a proper mode scan and re-calculate the solution.

The measured transmission is now ~610 mW. The power reflected from the PMC with it unlocked is ~1400 mW.

Problem:

RFM reads are slow.  Rolf has said it should take 2-3 microseconds per read. 

c1sus is taking about 7 microseconds per read, twice as slow as Rolf's claim.

Hypothesis:

The RFM card is in the IO chassis, and is sharing the PCIe bus with 4 ADC cards, 3 DAC cards, 4 BO cards, and a BIO card.  Its possible this crowded bus is causing the reads to take even longer.

Test Results:

Compare read times between the c1sus computer, which has its RFM card in the IO chassis, to c1ioo, which has its RFM card in the computer.

c1ioo:

No RFM reads: 8 microseconds

3 RFM reads: 20 microseconds (~4 per read)

6 RFM reads: 32 microseconds (~4 per read)

c1sus:

No RFM read: 25 microseconds (bigger model)

1 RFM read: 33 microseconds (~8 per read)

3 RFM read: 45 microseconds (~7 per read)

6 RFM read: Over 62 microseconds, doesn't run.

Conclusion:

It looks like moving the RFM card may help by about a factor of 2 in read speed, although its still not quite what Alex and Rolf claim it should be.

The c1mcs and c1ioo models have been reverted to their normal operations.

The south end of IFO room 104 was reshuffled. The flow bench was moved all the way to the south end to create more room for the crane reach. The old  large drawing cabinet  was moved under the vacuum tube.

The new clear view through  Acrylic-plexyglass cabinet is anchored. It has powder finished coating so it will not out-gas too much.The back side shelf mounting holes are sealed off with kapton tape. The doors still needs some gaskit seals.

Problem:

Each RFM read in the c1mcs model is adding ~7 microseconds to the cycle time.  Adding too many pushes it over the 62 microsecond limit.

RFM writes do not have this problem.

Temporary Solution:

The fastest fix was to create a new front end model, called c1rfm, which does nothing but read in the MC1, MC2, MC3 PIT and YAW signals from the c1ioo machine, and then passes them along to the c1mcs model via shared memory, which is fast.

This means the data being sent is 2 cycles slow, one to go over the RFM, and one to go over shared memory.  It is running at 16384 cycles/second, so it shouldn't have much impact at the frequencies we use those channels for.

MC_L is still being sent directly to the c1mcs front end code via RFM.

Current Status:

The c1mcs model is running at  30-33 microseconds for CPU time.

The c1rfm model is running at 45-47 microseconds for CPU time.

All 7 channels, MC_L, MC1_PIT, MC1_YAW, MC2_PIT, MC2_YAW, MC3_PIT, MC3_YAW are responding.

The c1rfm model was added to the /diskless/root/etc/rtsystab file on the fb machine so that it automatically starts on the reboot of c1sus.

The USR and CPU time channels for c1rfm were added to the MCS_SLOW.ini file in /opt/rtcds/caltech/c1/chans/daq/ so that the framebuilder records them, namely:

[C1:FEC-38_USR_TIME]
[C1:FEC-38_CPU_METER]

The framebuilder was restarted to take these new channels into account.

Future:

Finish implementing and debugging the "round robin" RFM reader so as to not require a seperate model to be doing RFM reads in parallel.

Look into improving read speed by either merging timestamps and data into a single  or reading time stamp once every tenth or hundreth cycle, although this at best provides a factor of 2 improvement.

Check to see if RFM card being on the IO chassis or directly in the computer chassis makes a difference.

Get Alex and Rolf to improve RFM read speed.

When swapping Eurocard boards, it is safest to first turn down the power supplies and then do the swapping.

Otherwise, it is sometimes the case that people plug in the board slowly and/or asymmetrically. This can cause the opamp to see one of the power supply rails without the other (e.g. +15 but not -15).

This can destroy some opamps. The true danger is that there may be damage to the board which you do not notice for several months, thereby leaving a timebomb for the next person.

Don't be an electronics terrorist!

Wow! Great guys!!

Can I expect to see the spectra of the frequency counter output with and without the servo?

RA: I think the SBP-70 is a bad idea. It limits the capture range. So does the SHP-25. You should instead just use a DC-block; the SR620 should work from 1-200 MHz with no problems.

Also, we have to figure out a better solution for the DAC at the ends: we cannot steal the QPD gain slider in the long run and the 4116 DAC at the ends has all 8 channels used up. Should we get the purple box for testing or should we try to use the fast DAC in the EX IO chassis as the actuator?

(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;
 

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

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

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!

[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.

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.