40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 130 of 350  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  4095   Thu Dec 23 18:51:37 2010 ranaUpdateGreen Lockinginstalled doubling oven base at PSL table

This is not such a bad base design, but remember that we have to get a couple of parts with the purple anodize to see if there is a difference between black and purple in terms of the 532 nm reflectivity.

  4096   Thu Dec 23 22:13:50 2010 KojiUpdateGeneralPZT HV turned on

The four IOO PZTs have been turned on in order to confirm the alignment of the IFO.

Once they are turned on, the spots (ITMX/ITMY/PRM/SRM) on the REFL CCD have been easily found.

When the X-arm was aligned to the green beam, it is easily locked to TEM00. Also some LG modes were visible.
i.e. There is some room to improve the mode matching.
The transmitted green at the PSL table is a bit too high and clipped by the first mirror on the table.

No IR flashes were found in either arms.

------------------

The below are the range and the set values of the strain gauge readback for the PZTs.
When the closed loop buttons are activated the PZTs are fixed at those values, if no one touches the set point dials.

            Min   Max   SetP | Display on the module
PZT1 Yaw    2.20  9.95  6.08 | Broken
PZT1 Pitch -0.011 8.89  4.40 | 1.58

PZT2 Yaw    0.737 9.94  5.37 | 2.17
PZT2 Pitch  0.010 9.42  4.71 | 1.89

  4097   Fri Dec 24 09:01:33 2010 josephbUpdateCDSBorrowed ADC

Osamu has borrowed an ADC card from the LSC IO chassis (which currently has a flaky generation 2 Host interface board).  He has used it to get his temporary Dell test stand running daqd successfully as of yesterday.

This is mostly a note to myself so I remember this in the new year, assuming Osamu hasn't replaced the evidence by January 7th.

  4099   Fri Dec 31 12:41:02 2010 ranaUpdateGeneralIR flashes

I came in today to check up on the StripTool and burn the Ubuntu LTS (new CDS OS) DVD. I was pretty excited to see the PRM flashes on Mon1.

I waggled the PRM/BS alignments and got a good contrast MICH and then bright flashes in the PRM that totally overload Mon1's CCD.

Now I can see flashes of some IR junk in the X Arm; its way off on the left edge of the mirror, but there's a beam.

For the short term, we can hook up the IO PZTs to some old EPICS channels (like one of the AUX guys in the LSC area), but eventually it has to get hooked up to the new ASC or ASS. We have to bug Joe to see where this shows up in his master diagram.

**Note: if you get lost sometimes when doing the alignments, remember that you can use time_machine_conlog.

Ex:

rossa:general>./time_machine_conlog 2010/12/31,11:00:00 PDT C1:SUS-ITMX_PIT_COMM
Issuing the conlog command:
/cvs/cds/caltech/conlog/bin/conlog +epics -interp at 2010/12/31,11:00:00 PDT "C1:SUS-ITMX_PIT_COMM"


Conlog Replied:

LIGO controls: values at 2010 12/31 11:00:00 pst
 __Epics_Channel_Name______   __value_____
 C1:SUS-ITMX_PIT_COMM         0.406100



Restoring now...

Restoration Successful

Attached is the last 8 days of Vacuum Pressure trend which includes the pumpdown.

Attachment 1: Untitled.png
Untitled.png
  4101   Sat Jan 1 19:13:40 2011 ranaUpdateCDSc1pem now recording data

 I found that there was no PEM data nor any other data (no SUS or otherwise. No testpoints, no DAQ).

I went through the procedure that Jenne has detailed in the Wiki but it didn't work.

1) Firstly, the 'telnet fb 8088' step doesn't work. It says "Connected to fb.martian" but then just hangs. To replicate the effect of this step I tried ssh'ing to fb and doing a 'pkill daqd'. That works to restart the daqd process.

2) The wiki instructions had a problem. In the GUI step, it should say 'Save' after the Acquire bit has been set to 1. Even so, this works to get the .ini file right and the DTT can see the correct channel list, but none of the channels are available. There are just 'Unable to obtain measurement data'.

3) I tried running 'startc1pem', but no luck. I also tried rebooting c1sus from the command line. That worked so far as to come back up with all the right processes running, but still no data. The actual /frames directory shows that there are frames, but we just can't see the data. I also tried to get data usind the DTT-NDS2 method, but still no luck. (*** ITMX and ITMY both came back with all their filters off; worth checking if their BURTs are working correctly.)

Using DataViewer, however, I AM able to see the data (although the channel name is RED). In fact, I am able to see the trend data ever since I changed the Acquire bit to 1. Plot attached as evidence. Why does DTT not work anymore???

Attachment 1: Untitled.png
Untitled.png
  4103   Tue Jan 4 02:58:53 2011 JenneUpdateIOOPower into Mode Cleaner increased

What was the point:

I twiddled with several different things this evening to increase the power into the Mode Cleaner.  The goal was to have enough power to be able to see the arm cavity flashes on the CCD cameras, since it's going to be a total pain to lock the IFO if we can't see what the mode structure looks like.

Summed-up list of what I did:

* Found the MC nicely aligned.  Did not ever adjust the MC suspensions.

* Optimized MC Refl DC, using the old "DMM hooked up to DC out" method.

* Removed the temporary BS1-1064-33-1025-45S that was in the MC refl path, and replaced it with the old BS1-1064-IF-2037-C-45S that used to be there.  This undoes the temporary change from elog 3878.  Note however, that Yuta's elog 3892 says that the original mirror was a 1%, not 10% as the sticker indicates. The temporary mirror was in place to get enough light to MC Refl while the laser power was low, but now we don't want to fry the PD.

* Noticed that the MCWFS path is totally wrong.  Someone (Yuta?) wanted to use the MCWFS as a reference, but the steering mirror in front of WFS1 was switched out, and now no beam goes to WFS2 (it's blocked by part of the mount of the new mirror). I have not yet fixed this, since I wasn't using the WFS tonight, and had other things to get done.  We will need to fix this.

* Realigned the MC Refl path to optimize MC Refl again, with the new mirror.

* Replaced the last steering mirror on the PSL table before the beam goes into the chamber from a BS1-1064-33-1025-45S to a Y1-45S.  I would have liked a Y1-0deg mirror, since the angle is closer to 0 than 45, but I couldn't find one.  According to Mott's elog 2392 the CVI Y1-45S is pretty much equally good all the way down to 0deg, so I went with it.  This undoes the change of keeping the laser power in the chambers to a nice safe ~50mW max while we were at atmosphere.

* Put the HWP in front of the laser back to 267deg, from its temporary place of 240deg.  The rotation was to keep the laser power down while we were at atmosphere.  I put the HWP back to the place that Kevin had determined was best in his elog 3818.

* Tried to quickly align the Xarm by touching the BS, ITMX and ETMX.  I might be seeing IR flashes (I blocked the green beam on the ETMX table so I wouldn't be confused.  I unblocked it before finishing for the night) on the CCD for the Xarm, but that might also be wishful thinking.  There's definitely something lighting up / flashing in the ~center of ETMX on the camera, but I can't decide if it's scatter off of a part of the suspension tower, or if it's really the resonance.  Note to self:  Rana reminds me that the ITM should be misaligned while using BS to get beam on ETM, and then using ETM to get beam on ITM.  Only then should I have realigned the ITM.  I had the ITM aligned (just left where it had been) the whole time, so I was making my life way harder than it should have been.  I'll work on it again more today (Tuesday). 

What happened in the end:

The MC Trans signal on the MC Lock screen went up by almost an order of magnitude (from ~3500 to ~32,000).  When the count was near ~20,000 I could barely see the spot on a card, so I'm not worried about the QPD.  I do wonder, however, if we are saturating the ADC. Suresh changed the transimpedance of the MC Trans QPD a while ago (Suresh's elog 3882), and maybe that was a bad idea? 

Xarm not yet locked. 

Can't really see flashes on the Test Mass cameras. 

  4104   Tue Jan 4 11:06:32 2011 KojiUpdateIOOPower into Mode Cleaner increased

- Previously MC TRANS was 9000~10000 when the alignment was good. This means that the MC TRANS PD is saturated if the full power is given.
==> Transimpedance must be changed again.

- Y1-45S has 4% of transmission. Definitively we like to use Y1-0 or anything else. There must be the replaced mirror.
I think Suresh replaced it. So he must remember wher it is.

- We must confirm the beam pointing on the MC mirrors with A2L.

- We must check the MCWFS path alignment and configuration.

- We should take the picture of the new PSL setup in order to update the photo on wiki.

Quote:

What was the point:

I twiddled with several different things this evening to increase the power into the Mode Cleaner.  The goal was to have enough power to be able to see the arm cavity flashes on the CCD cameras, since it's going to be a total pain to lock the IFO if we can't see what the mode structure looks like.

Summed-up list of what I did:

* Found the MC nicely aligned.  Did not ever adjust the MC suspensions.

* Optimized MC Refl DC, using the old "DMM hooked up to DC out" method.

* Removed the temporary BS1-1064-33-1025-45S that was in the MC refl path, and replaced it with the old BS1-1064-IF-2037-C-45S that used to be there.  This undoes the temporary change from elog 3878.  Note however, that Yuta's elog 3892 says that the original mirror was a 1%, not 10% as the sticker indicates. The temporary mirror was in place to get enough light to MC Refl while the laser power was low, but now we don't want to fry the PD.

* Noticed that the MCWFS path is totally wrong.  Someone (Yuta?) wanted to use the MCWFS as a reference, but the steering mirror in front of WFS1 was switched out, and now no beam goes to WFS2 (it's blocked by part of the mount of the new mirror). I have not yet fixed this, since I wasn't using the WFS tonight, and had other things to get done.  We will need to fix this.

* Realigned the MC Refl path to optimize MC Refl again, with the new mirror.

* Replaced the last steering mirror on the PSL table before the beam goes into the chamber from a BS1-1064-33-1025-45S to a Y1-45S.  I would have liked a Y1-0deg mirror, since the angle is closer to 0 than 45, but I couldn't find one.  According to Mott's elog 2392 the CVI Y1-45S is pretty much equally good all the way down to 0deg, so I went with it.  This undoes the change of keeping the laser power in the chambers to a nice safe ~50mW max while we were at atmosphere.

* Put the HWP in front of the laser back to 267deg, from its temporary place of 240deg.  The rotation was to keep the laser power down while we were at atmosphere.  I put the HWP back to the place that Kevin had determined was best in his elog 3818.

* Tried to quickly align the Xarm by touching the BS, ITMX and ETMX.  I might be seeing IR flashes (I blocked the green beam on the ETMX table so I wouldn't be confused.  I unblocked it before finishing for the night) on the CCD for the Xarm, but that might also be wishful thinking.  There's definitely something lighting up / flashing in the ~center of ETMX on the camera, but I can't decide if it's scatter off of a part of the suspension tower, or if it's really the resonance. 

What happened in the end:

The MC Trans signal on the MC Lock screen went up by almost an order of magnitude (from ~3500 to ~32,000).  When the count was near ~20,000 I could barely see the spot on a card, so I'm not worried about the QPD.  I do wonder, however, if we are saturating the ADC. Suresh changed the transimpedance of the MC Trans QPD a while ago (Suresh's elog 3882), and maybe that was a bad idea? 

Xarm not yet locked. 

Can't really see flashes on the Test Mass cameras. 

 

  4105   Tue Jan 4 13:57:48 2011 kiwamuUpdateIOOincident mirror changed from 45deg to 0 deg

I replaced the final steering mirror (Y1-1037-45-S) in the zig-zag path on the PSL table by a 0 deg mirror Y1-1037-0.

With a sensor card I confirmed the transmission reduced a lot after the replacement.

As we expected, the replacement of the mirror caused a mis-alignment of the incident beam axis to the MC, so I compensated it by touching the angle of the mirror a little bit.

After the alignment of the mirror, the MC is still resonating at TEM00.

We will check the spot positions more accurately by A2L technique.

Quote:

- Y1-45S has 4% of transmission. Definitively we like to use Y1-0 or anything else. There must be the replaced mirror. 

I think Suresh replaced it. So he must remember wher it is.

  4106   Tue Jan 4 15:12:33 2011 SureshUpdateIOOMC Trans Mon QPD gain decreased by 10

 Decreased the gain of MC-Trans-Mon QPD ckt

The resistors R1, R2, R3, R4 are now 49.9 kOhm. The previous elog on this subject 3882 has the ckt details. 

  4107   Tue Jan 4 18:37:18 2011 JenneUpdateIOOMCWFS aligned

I undid Yuta's temporary setup, and put beam back on both WFS.  Since Koji had just aligned the Mode Cleaner, I centered the beam on the WFS using the WFS QPD screen, while watching the WFS Head screen, to make sure that the beam was actually hitting the QPD, and not off in lala land. 

Quote from Koji:

- We must check the MCWFS path alignment and configuration.

Quote from Jenne:

* Noticed that the MCWFS path is totally wrong.  Someone (Yuta?) wanted to use the MCWFS as a reference, but the steering mirror in front of WFS1 was switched out, and now no beam goes to WFS2 (it's blocked by part of the mount of the new mirror). I have not yet fixed this, since I wasn't using the WFS tonight, and had other things to get done.  We will need to fix this.

 

  4108   Tue Jan 4 21:21:57 2011 kiwamuUpdateIOOPZTs are connected to c1iscaux

I connected PZT1 and PZT2 to a slow front end machine c1iscaux.

Now we are able to align these PZTs from the control room via epics.

 

   Since we removed C1ASC that was controlling the voltage applied on the PZTs, we didn't have the controls for them for a long time.

So Rana and I decided to hook them up to an existing slow front end machine temporarily.

(probably the best solution is to connect them to C1LSC, which is fast enough to dither them.)

We actually found that c1iscaux is the proper machine, because it looked like it used to control the PZTs a long long time ago.

Moreover, c1iscaux still has DAC channels named like C1:LSC-PZT1_X, and so on.

 

  Below shows a screen shot of the medm screen for controlling the PZTs, invoked from a button on sitemap.adl ( pointed by a black arrow in the picture below)

The current default values are all zero at the right top sliders.

Screenshot20110104.png

  4110   Wed Jan 5 03:06:02 2011 kiwamuUpdateIOObeam spots on MC mirrors

I checked the spot positions on MC1 and MC3 by running Yuta's A2L script.

The amounts of the off-centering were good except for YAW of MC1.

 So we have to adjust the YAW alignment of the beam axis by steering the mirrors at the PSL table.

- - - (measured off-centering) - - - 

MC1_PIT  =  -0.711 mm

MC1_YAW =  1.62 mm

MC3_PIT  =   -0.0797 mm

MC3_YAW  =  - 0.223 mm

 

Quote:

We will check the spot positions more accurately by A2L technique.

 

  4111   Wed Jan 5 10:45:51 2011 KojiUpdateelogrestarted

Google bot  crashed the elog again. Then, I found that Google bot (and I) can crash elogd by trying to show the threaded view.
There looks similar issue reported to the elog forum, the author did not think this is a true bag.

Note: This happens only for the 40m elog. The other elogs (ATF/PSL/TCS/SUS/Cryo) are OK for the threaded view.

Quote:

Did it again. It seemed that Google bot came to the elog and tried to obtain "http://nodus.ligo.caltech.edu:8080/robots.txt". That was the last of the log.
Bot came from the AJW's homepage. Also Google FeedFecther came to the elog.

 

  4114   Wed Jan 5 21:19:29 2011 ZachUpdateelogrestarted

 Restarted the elog with the script

  4116   Wed Jan 5 23:22:00 2011 JenneUpdateCamerasAligned the Xarm, no big deal

[Kiwamu, Jenne]

We successfully aligned the X arm.  No big deal.  Nothing to write in giant colorful letters about.  If we thought it was tricky, we'd be excited.  But since we're rockstar grad students, we can do this anytime, with one hand behind our back.

The details:

Earlier this evening, Kiwamu put a PD at the dark port.  After starting with the usual steering beams around and approximately centering them by finding the beam on the SUS tower, we saw that we could see the fringes on a 'scope hooked up to the dark port's new PD.  We could make the dip in the scope trace go away by misaligning the ETM, so we were confident that it was due to some kind of resonance in the arm.  We then fine-tuned our beam centering by moving the optics in either pitch or yaw until the fringe went away, wrote down the number, then moved the other direction until the fringe went away, and then put the optic back in the middle of those two numbers.  We did the ETM first, then the ITM (because the beam on the PD is sensitive to the ITM pointing, so we didn't want to have to move the ITM very far).  We saw that the cavity had a visibility of ~56% when we had finished with this method.

We then went to look for the flashes transmitted through the ETM.  We were not able to see them on a card, but when we looked with an IR viewer at the back face of the ETM, we could see the flashes. We stole a spare CCD camera found on the PSL table, and the camera power supply from the RefCav Refl camera, and set up a CCD camera with telephoto lens on the ETMX Trans table, looking directly at the back of the ETM.  We hooked the camera up to the regular ETMX camera cable, so we can see the flashes in the control room.  You can see them here:

DSC_2822.JPG

While the cavity was aligned, here were the slider positions:

KiwamuJenne_5Jan2011_Xarm_Aligned.png

  4117   Wed Jan 5 23:37:12 2011 ranaUpdateCamerasAligned the Xarm, no big deal

Pretty fancy work actually...I wouldn't have guessed that you need to look at the back of the ETM. Does this mean that we can't see the flashes from inside the arm cavity? If so, its a pretty remarkeable statement about the wide angle scatter of the new mirrors. Do we really have 1W going into the MC?

  4118   Wed Jan 5 23:45:33 2011 JenneUpdateCamerasAligned the Xarm, no big deal

Correct.  We can see the flashes clearly on our new ETM camera, but we see absolutely nothing on the ITM.

Unfortunately, the camera is in the path of the green beam, so we'll have to figure out a more permanent plan.  Right now the laser at the end is shuttered.

Measuring the power now....

Quote:

Pretty fancy work actually...I wouldn't have guessed that you need to look at the back of the ETM. Does this mean that we can't see the flashes from inside the arm cavity? If so, its a pretty remarkeable statement about the wide angle scatter of the new mirrors. Do we really have 1W going into the MC?

 

  4119   Thu Jan 6 00:03:05 2011 KojiUpdateCamerasAligned the Xarm, no big deal

Nice, nice!

The power budget for the FPMI is here. The expected Intracavity power and the transmission are at  most ~8W and 100uW, respectively.

 

  4120   Thu Jan 6 00:06:01 2011 JenneUpdateIOOMagical absorbing PZT mirror

[Kiwamu, Jenne]

We have a measely 465mW going into the MC.  We lose a boatload of power on the PZT mirror that is part of the last zigzag for steering into the MC.  Just before this mirror, we measure 1.21W .  Just after this mirror, we measure ~475mW.  Then a teeny bit gets picked off for the PSL POS/ANG.  But we're losing a factor of 3 on this one mirror.  Need to fix!!!!!!!!!

  4121   Thu Jan 6 10:47:11 2011 KojiUpdateelogELOG fixed (re: restarted)

Fixed the 40m elog crashing with the threaded display.

This morning I found that Google bot crashed the elog again. I started the investigation and found the threaded mode is fine if we use the recent 10 entries.

I gradually copied the old entries to a temporary elog and found that a deleted elog entry on August 6 had a corrupted remnant in the elog file. This kept crashed the threaded mode.

Once this entry has been eliminated again, the threaded mode got functional.

I hope this eliminates those frequent elog crashing.

Quote:

Google bot  crashed the elog again. Then, I found that Google bot (and I) can crash elogd by trying to show the threaded view.
There looks similar issue reported to the elog forum, the author did not think this is a true bag.

Note: This happens only for the 40m elog. The other elogs (ATF/PSL/TCS/SUS/Cryo) are OK for the threaded view.

Quote:

Did it again. It seemed that Google bot came to the elog and tried to obtain "http://nodus.ligo.caltech.edu:8080/robots.txt". That was the last of the log.
Bot came from the AJW's homepage. Also Google FeedFecther came to the elog.

 

 

  4122   Fri Jan 7 00:14:36 2011 kiwamuUpdateIOOEOM triple resonant box is working

 I checked the triple resonant box for the broadband EOM this afternoon, and found it was healthy.

So I installed it again together with a power combiner and succeeded in locking the MC.

Since the box has a non-50 Ohm input impedance at 29.5 MHz, so it maybe needed to adjust the phase of the LO for the demodulation of the PDH signal.

A good thing is that now we are able to impose the other sidebands (i.e. 11 MHz and 55MHz) via the power combiner.

  4123   Fri Jan 7 00:49:16 2011 JenneUpdateGreen LockingRecovered Xarm Green Lock, Preparation for Beat Note Measurement

[Kiwamu, Jenne]

We went this evening in search of a beat note signal between the Xarm transmitted green light and the PSL doubled green light. 

First, we removed our new ETMX camera (we left the mount so it should be easy to put back) from the other day.   We left the test masses exactly where they had been while flashing for IR, so even though we can no longer confirm, we expect that the IR beam axis hasn't changed.  We used the steering mirror on the end table to align the green beam to the cavity.  We turned on the loop to lock the end laser to the cavity, and achieved green lock of the arm.

Then we went to the PSL table to overlap the arm transmitted light with the PSL doubled light.  We made a few changes to the optics that take the arm transmitted light over to the PD.  We found that the arm transmitted light was very high, so we changed from having one steering mirror to having 3 (for table space / geometry reasons we needed 3, not just 2) in order to lower the beam axis.  We also found that the spot size of the arm transmitted beam was ~2x too small, so we changed the mode matching telescope from a 4x reducer to a 2x reducer by changing the 2nd lens from f=50mm to f=100mm (the first lens is f=200mm).  We made the arm transmitted beam and the PSL green beam overlap, but we saw no peak on the spectrum analyzer. 

We checked the temperature of the PSL and end lasers, and determined that we needed to adjust the set temp of the end laser.  However, we still didn't find any beat note.

We then tweaked the temperature of the doubling oven at the end station, to maximize the power transmitted, since Kiwamu said that that had worked in the past.  Alas, no success tonight.

We're stopping for the evening, with the success of reacquiring green lock of the Xarm.

  4124   Fri Jan 7 12:01:39 2011 OsamuUpdateComputersc1lsc running

I got a new adapter board for expansion chassis from CDS and exchanged the existing adapter board which was laid on the floor around ETMX to new one.

Then I connected the chassis to c1lcs,  c1lsc seems to be running now. I will return the old board to CDS since Rolf says he wants to return it to manufacture.

 I found an interface box from ADC to D-SUB37pin and a cable to connect them.

I needed to make cables to connect the interface box to existing LSC whitening filters that has a 37 pin female D-SUB connector on one end and a 40pin female flat connector on the other end. We should use shielded cables for them, but unfortunately CDS did not have right one. Temporarily I made one cable for 1-8ch using a ribbon twist cable like Joe did.

I found a saturation at ch5 of ADC0 on c1lsc. I did not check carefully but it seemed to come from the LSC whitening board. Input of ch5 of the whitening board was not terminated and had a huge output voltage, but also ch6 was not terminated and had no big output. I guess something wrong on the LSC whitening board. Needs to be checked. Anyway I unplugged the small ribbon cable between the whitening board and the next LSC AA filter board.

Finally I realized that fiber connection of RFM did not exist. What I saw was the fiber cable of Dolphin. We need a RFM PCIe interface board, and a long fiber cable between c1lsc and RFM hub.

  4125   Fri Jan 7 15:17:37 2011 steveUpdateCamerasITMX video monitor has tower wide view

The Watec 902, 1/2" CCD camera got new Tamron lens: 1/2" 10-40mm F/1.4  manual iris. IR corrective lens. It is designed to have the same focal point in the IR as

in the visible light range. However, as the depth of field in the IR range is very narrow, focus adjustment should be done carefully in the IR.

Now you can see the sus tower that will make alignment easier.

 

  4126   Sat Jan 8 21:12:12 2011 ranaUpdateCDSMegatron is back

 I started reverting Megatron into a standard Ubuntu workstation after Joe/Osamu's attempt to steal it for their real time mumbo jumbo.

First, I installed a hard drive that was sitting around on top of it. That whole area is still a mess; I'm not surprised that we have so many CDS problems in such a chaotic state. There's another drive sitting around there called 'RT Linux' which I didn't use yet.

Second, I removed the ethernet cables and installed a monitor/keyboard/mouse on it.

Then I popped in the Ubuntu 10.04 LTS DVD, wiped the existing CentOS install and started the standard graphical installation of Ubuntu.

megatron.jpg

Megatron's specs attached: 

Attachment 2: sysinfo.text
  4127   Sat Jan 8 23:18:03 2011 ranaUpdateComputersnetwork table

There's, as usual, a disconnect between the real martian host table and the one displayed on the Wiki. Basically, the point is: DO NOT TRUST THE WIKI, because people who update the actual host table only randomly update the wiki table.

The only thing worth trusting is the file

/var/named/chroot/var/named/martian.zone
on linux 1.

You will need to have 'root' or 'sudo' to get into that directory to read the file.

  4129   Mon Jan 10 16:39:36 2011 josephb, alex, rolfUpdateCDSNew Time server for frame builder and 1PPS

Alex and Rolf came over today with a Tempus LX  GPS network timing server.  This has an IRIG-B output and a 1PPS output.  It can also be setup to act as an NTP server (although we did not set that up).

This was placed at waist height in the 1X7 rack.  We took the cable running to the presumably roof mounted antenna from the VME timing board and connected it to this new timing server.  We also moved the source of the 1PPS signal going to the master timer sequencer (big blue box in 1X7 with fibers going to all the front ends) to this new time server.  This system is currently working, although it took about 5 minutes to actually acquire a timing signal from the GPS satellites.  Alex says this system should be more stable, with no time jumps. 

I asked Rolf about the new timing system for the front ends, he had no idea when that hardware would be available to the 40m.

Currently, all the front ends and the frame builder agree on the time.  Front ends are running so the 1 PPS signal appears to be working as well.

  4130   Mon Jan 10 16:47:08 2011 josephb, alex, rolfUpdateCDSFixed c1lsc dolphin reflected memory

While Alex and Rolf were visiting, I pointed out that the Dolphin card was not sending any data, not even a time stamp, from the c1lsc machine.

After some poking around, we realized the IOP (input/output processor) was coming up before the Dolphin driver had even finished loading. 

We uncommented the line

#/etc/dolphin_wait

in the /diskless/root/etc/rc.local file on the frame builder.  This waits until the dolphin module is fully loaded, so it can hand off a correct pointer to the memory location that the Dolphin card reads and writes to.  Previously, the IOP had been receiving a bad pointer since the Dolphin driver had not finished loading.

So now the c1lsc machine can communicate with c1sus via Dolphin and from there the rest of the network via the traditional Ge Fanuc RFM.

  4131   Tue Jan 11 01:05:29 2011 kiwamuUpdateLSCobtained Xarm PDH signal

[Jenne, Zach, Kiwamu]

 

 We made some efforts to lock the X arm cavity with the infrared beam.

We eventually obtained the PDH signal from a photo diode at AS port, we are still in the mid way of the lock.

The PDH signal now is going into c1lsc's ADC.

We have to make sure which digital channel corresponds to our PDH signal,

 

(what we did)

- split the LO signal, which comes from a Marconi, just before the EOM into two path.

     One is going to the EOM and the other is going to the AP table for the demodulation, The driving frequency we are using is 11MHz.

- put RF amplifiers to make the RF signal bigger. The raw signal was small, it was about ~-50 dBm in the spectrum analyzer.

   So we connected two ZLN amplifiers. Now the RF signal is at about 0 dBm

- connected the LO and RF signals to a mixer.  Additionally we put a 9.5-11.5 MHz bandpass filter at the LO path since there was some amounts of 29.5MHz due to the RF reflection at the EOM resonant box.

     After a low pass filter by SR560 the signal shows typical PDH behaviors.

- strung a BNC cable which connects the demodulated signal and c1lsc.

    In order to connect the signal to the current working ADC, we disconnected AS166_I from a whitening board and plug our cable on it.

- tried checking the digital signal but we somehow couldn't configure DAQ setting, So actually we couldn't make sure which channel corresponds to our signal.

 

  4133   Tue Jan 11 11:39:45 2011 steveUpdateVACRGA is turned on

Joe updated the rga procedure in the wiki and we turned on the filament. It will take a few days to reach thermal equilibrium.

TP2 dry fore pump was replaced at 910mTorr

Attachment 1: pd70d22.jpg
pd70d22.jpg
  4134   Tue Jan 11 13:32:52 2011 josephb, kiwamuUpdateCDSUpdated some DAQ channel names

[Joe, Kiwamu]

We modified the activateDAQ.py script which lives in /opt/rtcds/caltech/c1/chans/daq/ and updates the C1SUS.ini, C1MCS.ini, C1RMS.ini, C1SCX.ini and C1SCY.ini files.  These files contain the DAQ channels for all the optics.

It has been modified so that channels like C1:SUS-ITMX_ULSEN_OUT_DAQ become C1:SUS-ITMX_SENSOR_UL.  Similarly the oplev signals go from C1:SUS-ITMX_OLPIT_OUT to C1:SUS-ITMX_OPLEV_PERROR.

After some debugging, we ran the script successfully and checked the output was correct.  We then restarted the frame builder (telnet fb 8088 and then shutdown) and also hit the DAQ reload button for all the front ends.

I tested in dataviewer that I could go back several years as well as going back just 1 hour in the history and see data for C1:SUS-ITMX_SENSOR_LL as well as C1:SUS-ITMX_OPLEV_YERROR.  I also tested realtime is also working for these channels.

 

The contents of the script are below.

 

inputfiles=["C1SUS.ini","C1RMS.ini","C1MCS.ini","C1SCX.ini","C1SCY.ini"]
prefix="[C1:SUS-"
optics=["BS_","ITMX_","ITMY_","PRM_","SRM_","MC1_","MC1_","MC2_","MC3_","ETMX_"]
#channels=["SUSPOS_IN1","SUSPIT_IN1","SUSYAW_IN1","SUSSIDE_IN1","ULSEN_OUT","URSEN_OUT","LRSEN_OUT","LLSEN_OUT","SDSEN_OUT","OL_SUM_IN1","OLPIT_IN1","OLYAW_IN1"]
channels_dict = {'SUSPOS_IN1':'SUSPOS_IN1_DAQ',
'SUSPIT_IN1':'SUSPIT_IN1_DAQ',
'SUSYAW_IN1':'SUSYAW_IN1_DAQ',
'SUSSIDE_IN1':'SUSSIDE_IN1_DAQ',
'ULSEN_OUT':'SENSOR_UL',
'URSEN_OUT':'SENSOR_UR',
'LRSEN_OUT':'SENSOR_LR',
'LLSEN_OUT':'SENSOR_LL',
'SDSEN_OUT':'SENSOR_SIDE',
'OLPIT_OUT':'OPLEV_PERROR',
'OLYAW_OUT':'OPLEV_YERROR',
'OL_SUM_OUT':'OPLEV_SUM'}

suffix="_DAQ]\n"

## set datarate
datarate=2048

## read the ini files
for inputfile in inputfiles:
    print inputfile
    outputfile=inputfile
    ifile = open(inputfile,'r')
    lines = ifile.readlines()
    ifile.close()

    for k in range(len(lines)):
        for op in optics:
            for ch in channels_dict:
                if (prefix+op+ch+suffix) in lines[k]:
                    lines[k]=prefix + op + channels_dict[ch] + "]\n"
                    lines[k+1]=lines[k+1].lstrip("#").rstrip(lines[k+1].split("=")[1])+"1\n"
                    lines[k+2]=lines[k+2].lstrip("#")
                    lines[k+3]=lines[k+3].lstrip("#").rstrip(lines[k+3].split("=")[1])+str(datarate)+"\n"
                    lines[k+4]=lines[k+4].lstrip("#")
    ofile = open(outputfile,'w')
    for k in range(len(lines)):
        ofile.write(lines[k])
        #print lines[k]
    ofile.close()

  4135   Tue Jan 11 14:05:11 2011 josephbUpdateComputersMartian host table updated daily

I created two simple cron jobs, one running on linux1 and one running on nodus, to produce an updated copy of the martian host table linkable from the wiki every day.

The scripts live in /opt/rtcds/caltech/c1/scripts/AutoUpdate/.  One is called  updateHostTable.cron and run on linux1 everyday at 4 am, and the other is called moveHostTable.cron which is run on nodus everyday at 5am.

The new link has been added to the Martian Host table wiki page  here.

 

  4136   Tue Jan 11 16:04:17 2011 josephbUpdateCDSScript to update web views of models for all installed front ends

I wrote a new script that is in /opt/rtcds/caltech/c1/scripts/AutoUpdate/ called  webview_simlink_update.m. 

This m-file when run in matlab will go to the /opt/rtcds/caltech/c1/target directory and for each c1 front end, generate the corresponding webview files for that system and place them in the AutoUpdate directory. 

Afterwards the files can be moved on Nodus to the /users/public_html/FE/ directory with:

mv /opt/rtcds/caltech/c1/scripts/AutoUpdate/*slwebview* /users/public_html/FE/

This was run today, and the files can be viewed at:

https://nodus.ligo.caltech.edu:30889/FE/

Long term, I'd like to figure out a way of automating this to produce automatically updated screens without having to run it manually.  However, simulink seems to stubbornly require an X window to work.

  4138   Tue Jan 11 18:41:43 2011 JenneUpdateIOOPut MC PZT offset onto MC board, instead of on awkward cart

[Larisa and Jenne]

We wanted to get rid of the awkward cart that was sitting behind the 1Y1 rack.  This cart was supplying a +5V offset to the PZT driver, so that we could use the MC length signal to feedback to lock the laser to the MC cavity.  Instead, we put the offset on the last op amp before the servo out on the Mc Servo Board.  Because we wanted +5V, but the board only had +5, +15, -15V as options, and we needed -5 to add just before the op amp (U40 in the schematic), because the op amp is using regular negative feedback, we made a little voltage divider between -15V and GND, to give ourselves -5V.  We used the back side of the voltage test points (where you can check to make sure that you're actually getting DC voltage on the board), and used a 511Ohm and 1.02kOhm resistor as a voltage divider. 

Then we put a 3.32kOhm resistor in ~"parallel" to R124, which is the usual resistor just before the negative input of the op amp.  Our -5V goes to our new resistor, and should, at the output, give us a +5V offset. 

Sadly, when we measure the actual output we get, it's only +2.3V.  Sadface.

We went ahead and plugged the servo out into the PZT driver anyway, since we had previously seen that the fluctuation when the mode cleaner is locked was much less than a volt, so we won't run into any problems with the PZT driver running into the lower limit (it only goes 0-10V).

Suresh has discovered that the op amp that we're looking at, U40 on the schematic, is an AD829, which has an input impedance of a measely 13kOhm.  So maybe the 3.32kOhm resistors that we are using (because that's what had already been there) are too large.  Perhaps tomorrow I'll switch all 3 resistors (R119, R124, and our new one) to something more like 1kOhm.  But right now, the MC is locked, and I'm super hungry, and it's time for some arm locking action.

I've attached the schematic.  The stuff that we fitzed with was all on page 8.

 

Attachment 1: D040180-B.pdf
D040180-B.pdf D040180-B.pdf D040180-B.pdf D040180-B.pdf D040180-B.pdf D040180-B.pdf D040180-B.pdf D040180-B.pdf
  4140   Wed Jan 12 01:38:52 2011 KojiUpdateIOOPut MC PZT offset onto MC board, instead of on awkward cart

I can not think of any reason that the input impedance of 13kOhm between the pos/neg inputs produces such a big change at the output. In any case, the differential voltage between the pos/neg inputs produces a big output. But the output was just 2V or so. This means that the neg input was actually about zero volt. This ensures the principle of the summing amplifier of this kind.

Because the input impedance of the summing node (the additional resister you put at the negative input) is not infinity, the voltage divider is not perfect and shows 10% reduction of the voltge (i.e. the output will have +4.5V offset instead of +5V). But still it is not enough to explain such a small output like 2.3V.

What I can think of is that the earlier stages somehow have the offset for some reason. Anyway, it is difficult to guess the true reason unless all of the nodes around the last stage are checked with the multimeters.

At least, we can remove the voltage divider and instead put a 10k between -15V and the neg input in order to impose +5V offset at the output. This costs 1.5mA instead of 10mA.

Quote:

[Larisa and Jenne]

We wanted to get rid of the awkward cart that was sitting behind the 1Y1 rack.  This cart was supplying a +5V offset to the PZT driver, so that we could use the MC length signal to feedback to lock the laser to the MC cavity.  Instead, we put the offset on the last op amp before the servo out on the Mc Servo Board.  Because we wanted +5V, but the board only had +5, +15, -15V as options, and we needed -5 to add just before the op amp (U40 in the schematic), because the op amp is using regular negative feedback, we made a little voltage divider between -15V and GND, to give ourselves -5V.  We used the back side of the voltage test points (where you can check to make sure that you're actually getting DC voltage on the board), and used a 511Ohm and 1.02kOhm resistor as a voltage divider. 

Then we put a 3.32kOhm resistor in ~"parallel" to R124, which is the usual resistor just before the negative input of the op amp.  Our -5V goes to our new resistor, and should, at the output, give us a +5V offset. 

Sadly, when we measure the actual output we get, it's only +2.3V.  Sadface.

We went ahead and plugged the servo out into the PZT driver anyway, since we had previously seen that the fluctuation when the mode cleaner is locked was much less than a volt, so we won't run into any problems with the PZT driver running into the lower limit (it only goes 0-10V).

Suresh has discovered that the op amp that we're looking at, U40 on the schematic, is an AD829, which has an input impedance of a measely 13kOhm.  So maybe the 3.32kOhm resistors that we are using (because that's what had already been there) are too large.  Perhaps tomorrow I'll switch all 3 resistors (R119, R124, and our new one) to something more like 1kOhm.  But right now, the MC is locked, and I'm super hungry, and it's time for some arm locking action.

I've attached the schematic.  The stuff that we fitzed with was all on page 8.

 

 

  4141   Wed Jan 12 01:39:49 2011 kiwamuUpdateLSClocked X arm

[Suresh, Kiwamu]

 We eventually succeeded in locking X arm with the infrared beam.

The PDH signal is taken at MCL's ADC instead of c1lsc's, and fedback to MC2_POS through the MCL path.

Right now the lock is not so stable for some reasons, so we need to investigate it more.

 

(what we did)

 - strung a long BNC cable to connect the demodulated signal and the ADC of c1ioo.

          We didn't touch anything on the demodulation system, so the setup for the demodulation is exactly the same as that of yesterday (see here).

 - disconnected the actual MCL cable from the ADC breakout board at 1X2 rack. And put the demodulated signal onto it.

 - checked the analog dewhitening filter state for the MC2 coil driver, found the analog filter are always off.

  So we just made simDW and invDW always on.

- changed the gain of the MCL loop to have a stable lock for the X arm.

    right now a reasonable setup in the MCL filters are:

         FM1:ON, FM10:ON, G=0.1

 - In fact the lock of the MC is not so stable compared to before, frequently an attempt of locking the X arm leads to the unlock of the MC.

  4142   Wed Jan 12 02:41:19 2011 kiwamuUpdateGeneraldaytime tasks for tomorrow

[Rana, Kiwamu]

Here is the list for the daytime tasks of tomorrow, Jan. 12th.

The daytime task is a work basically to be done or quitted before the sun goes down.

Along with the tasks, we roughly assigned the people who are responsible for it.

The tasks below are basically separated from each other, so we can work in parallel.

 

 

--- 1.  LSC analog interface check (Joe/Koji)

   * check whitening filter

   * demodulation board check

    * check ADC connections

 

--- 2.  MC2 coil Dewhitening (Joe)

    * fix binary outputs.

    * FM9 must be the trigger of the binary outputs instead of FM10.

 

--- 3. 11MHz modulation depth (Kiwamu)

   * investigate why the depth is so low

 

--- 4. PEM DAQ name issue (Jenne)

   * change the name of seismic channels properly so that we can deal with the calibrated stuff

 

--- 5. phase adjustment for MC-PDH locking (Suresh)

 

--- 6. medm screens for C1LSC ()

    * make screens

 

 

 

  4144   Wed Jan 12 17:50:21 2011 josephbUpdateCDSWorked on c1lsc, MC2 screens

[josephb, osamu, kiwamu]

We worked over by the 1Y2 rack today, trying to debug why we didn't get any signal to the c1lsc ADC.

We turned off the power to the rack several times while examining cards, including the whitening filter board, AA board, and the REFL 33 demod board.  I will note, I incorrectly turned off power in the 1Y1 rack briefly. 

We noticed a small wire on the whitening filter board on the channel 5 path.  Rana suggested this was to part of a fix for the channels 4 and 5 having too much cross talk.  A trace was cut and this jumper added to fix that particular problem.

We confirmed would could pass signals through each individual channel on the AA and whitening filter boards.  When we put them back in, we did noticed a large offset when the inputs were not terminated.  After terminating all inputs, values at the ADC were reasonable, measuring on from 0 to about -20 counts.  We applied a 1 Hz, 0.1 Vpp signal and confirmed we saw the digital controls respond back with the correct sine wave.

We examined the REFL 33 demod board and confirmed it would work for demodulating 11 MHZ, although without tuning, the I and Q phases will not be exactly 90 degrees apart.

The REFL 33  I and Q outputs have been connected to the whitening board's 1 and 2 inputs, respectively.  Once Kiwamu  adds approriate LO and PD signals to the REFL 33 demod board he should be able to see the resulting I and Q signals digitally on the PD1 I and Q channels.

 

In an unrelated fix, we examined the suspensions screens, specifically the Dewhitening lights.  Turns out the lights were still looking at SW2 bit 7 instead of SW2 bit 5.  The actual front end models were using the correct bit (21 which corresponds to the 9th filter bank), so this was purely a display issue.  Tomorrow I'll take a look at the binary outputs and see why the analog filters aren't actually changing.

 

 

 

  4145   Wed Jan 12 22:19:54 2011 KojiUpdateIOOMC flakiness solved

[Koji Suresh Kiwamu]

Suresh modified the MC board to have +5V offset at the output. (To be reported in the separated elog)

The MC lock has not been obtained at this point. An investigation revealed that there was very small (~5mVpp) PDH signal.

Kiwamu removed his triple resonant adapter and put the 50Ohm termination insted.
This restored the signal level normal although this changed the demodulation phase about 20deg.
We left the demodulation phase as it is because this is a temporary setup and the loss of the signal is not significant.

Now the MC is steadily locked with the single super boost.

  4146   Wed Jan 12 22:33:24 2011 kiwamuUpdateCDSMC2 dewhitening are healthy except for UR

I briefly checked the MC2 analog dewhitening filters.

It turned out that the switching of the dewhitening filters from epics worked correctly except for the UR path.

I couldn't get a healthy transfer function for the UR path probably because the UR monitor at the front panel on either the AI filter or the dewhitening filter maybe broken.

Need a check again.

Quote:  #4144

Tomorrow I'll take a look at the binary outputs and see why the analog filters aren't actually changing.

  4147   Wed Jan 12 22:39:16 2011 SureshUpdateIOOPut MC PZT offset onto MC board, instead of on awkward cart

Quote:

I can not think of any reason that the input impedance of 13kOhm between the pos/neg inputs produces such a big change at the output. In any case, the differential voltage between the pos/neg inputs produces a big output. But the output was just 2V or so. This means that the neg input was actually about zero volt. This ensures the principle of the summing amplifier of this kind.

Because the input impedance of the summing node (the additional resister you put at the negative input) is not infinity, the voltage divider is not perfect and shows 10% reduction of the voltge (i.e. the output will have +4.5V offset instead of +5V). But still it is not enough to explain such a small output like 2.3V.

What I can think of is that the earlier stages somehow have the offset for some reason. Anyway, it is difficult to guess the true reason unless all of the nodes around the last stage are checked with the multimeters.

At least, we can remove the voltage divider and instead put a 10k between -15V and the neg input in order to impose +5V offset at the output. This costs 1.5mA instead of 10mA.

Quote:

[Larisa and Jenne]

We wanted to get rid of the awkward cart that was sitting behind the 1Y1 rack.  This cart was supplying a +5V offset to the PZT driver, so that we could use the MC length signal to feedback to lock the laser to the MC cavity.  Instead, we put the offset on the last op amp before the servo out on the Mc Servo Board.  Because we wanted +5V, but the board only had +5, +15, -15V as options, and we needed -5 to add just before the op amp (U40 in the schematic), because the op amp is using regular negative feedback, we made a little voltage divider between -15V and GND, to give ourselves -5V.  We used the back side of the voltage test points (where you can check to make sure that you're actually getting DC voltage on the board), and used a 511Ohm and 1.02kOhm resistor as a voltage divider. 

Then we put a 3.32kOhm resistor in ~"parallel" to R124, which is the usual resistor just before the negative input of the op amp.  Our -5V goes to our new resistor, and should, at the output, give us a +5V offset. 

Sadly, when we measure the actual output we get, it's only +2.3V.  Sadface.

We went ahead and plugged the servo out into the PZT driver anyway, since we had previously seen that the fluctuation when the mode cleaner is locked was much less than a volt, so we won't run into any problems with the PZT driver running into the lower limit (it only goes 0-10V).

Suresh has discovered that the op amp that we're looking at, U40 on the schematic, is an AD829, which has an input impedance of a measely 13kOhm.  So maybe the 3.32kOhm resistors that we are using (because that's what had already been there) are too large.  Perhaps tomorrow I'll switch all 3 resistors (R119, R124, and our new one) to something more like 1kOhm.  But right now, the MC is locked, and I'm super hungry, and it's time for some arm locking action.

I've attached the schematic.  The stuff that we fitzed with was all on page 8.

 

 

 

[Koji, Suresh]

    We looked at the board and found that the resistor R119 (the feed back) is 1.65k instead of the 3.32k that was needed for unity gain.  The gain has been intentionally reduced to 0.5 so that output range would be close to the 0-10V that is required at the input range of the PZT driver which follows.   A note to this effect is already present in the D040180-B, page 8.

    The voltage divider with 1k and 0.5k provides 4.5V (ref Koji's note above) this provides 2.25V at the output due to the gain of 0.5.  To get to the original goal of introducing a 5V offset on the output, we introduced the modification shown in the  'D040180-B with 5V offset.pdf' uploaded below.  Please check page 8, the changes are marked in red.  We checked to make sure that the output is 5V when the input is disconnected. 

D040180-B_with_5V_offset.pdf

The PCB pics at the end are also attached.  The 4.99k resistor is glued onto the PCB with epoxy and placed as close to the opamp possible.

Attachment 1: P1120508.JPG
P1120508.JPG
Attachment 2: P1120509.JPG
P1120509.JPG
  4148   Thu Jan 13 03:00:01 2011 JenneUpdateIOOWFS shenanigans

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

Current status:

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

The Full Story:

Power to WFS:

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

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

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

Quantum Efficiency Measurement:

I refer to Jamie's LHO elog for the equation governing quantum efficiency of photodiodes: LHO 2 Sept 2009

The information I gathered for each quadrant of each WFS was: [1] Power of light incident on PD (measured with the Ophir power meter), [2] Power of light reflected off the PD (since this light doesn't get absorbed, it's not part of the QE), and [3] the photo current output by the PD (To get this, I measured the voltage out of the DC path that is meant to go to EPICS, and backed out what the current is, based on the schematic, attached). 

I found a nifty 25 pin Dsub breakout board, that you can put in like a cable extension, and you can use clip doodles to look at any of the pins on the cable.  Since this was a PD activity, and I didn't want to die from the 100V bias, I covered all of the pins I wasn't going to use with electrical tape.  After turning down the 100V Kepco that supplies the WFS bias, I stuck the breakout board in the WFS.  Since I was able to measure the voltage at the output of the DC path, if you look at the schematic, I needed to divide this by 2 (to undo the 2nd op amp's gain of 2), and then convert to current using the 499 Ohm resistor, R66 in the 1st DC path.  

I did all 4 quadrants of WFS1 using a 532nm laser pointer, just to make sure that I had my measurement procedure under control, since silicon PDs are nice and sensitive to green.  I got an average QE of ~65% for green, which is not too far off the spec of 70% that Suresh found.

I then did all 8 WFS quadrants using the 1064nm CrystaLaser #2, and got an average QE of ~62% for 1064 (58% if I exclude 2 of the quadrants....see below).  Statistics, and whatever else is needed can wait for tomorrow.

Problem with 2 quadrants of WFS2?

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

Attachment 1: D990249-B-1_MCWFS_schematic.pdf
D990249-B-1_MCWFS_schematic.pdf
  4149   Thu Jan 13 12:56:57 2011 ranaUpdateIOOWFS shenanigans

Actually, I just found out that there are different flavors of 'YAG-444'.

There's a YAG-444AH and also a YAG-444-4AH. I'm not sure which one we have or even which is better. The diode's internal resistance is not listed.

They also say explicitly that he 'YAG Enhancement' is just using thicker Silicon. Since the absorption of 1064 nm light in Silicon is very small, most of the light just goes in and then comes back out without depositing much of the power.

Attachment 1: PerkinElmerQPDs.pdf
PerkinElmerQPDs.pdf PerkinElmerQPDs.pdf
  4150   Thu Jan 13 14:21:13 2011 josephbUpdateCDSWebview of front end model files automated

After Rana pointed me to Yoichi's MEDM snapshot script, I learned how to use Xvfb, which is what Yoichi used to write screens without a real screen.  With this I wrote a new cron script, which I added to Mafalda's cron tab to be run once a day at 6am.

The script is called webview_update.cron and is in /opt/rtcds/caltech/c1/scripts/AutoUpdate/.

#!/bin/bash
DISPLAY=:6
export DISPLAY
#Check if Xvfb server is already running
pid=`ps -eaf|grep vfb | grep $DISPLAY | awk '{print $2}'`
if [ $pid ]; then
        echo "Xvfb already running [pid=${pid}]" >/dev/null
else
# Start Xvfb
echo "Starting Xvfb on $DISPLAY"
Xvfb $DISPLAY -screen 0 1600x1200x24 >&/dev/null &
fi
pid=$!
echo $pid > /opt/rtcds/caltech/c1/scripts/AutoUpdate/Xvfb.pid
sleep 3

#Running the matlab process
/cvs/cds/caltech/apps/linux/matlab/bin/matlab -display :6 -logfile /opt/rtcds/caltech/c1/scripts/AutoUpdate/webview.log -r webview_simlink_update

  4151   Thu Jan 13 16:34:02 2011 josephbUpdateComputers32 bit matlab updated

There was a problem with running the webview report generator in matlab on Mafalada.  It complained of not having a spare report generator license to use, even though the report generator was working before and after on other machines such as Rosalba.  So I moved the old 32 bit matlab directory from /cvs/cds/caltech/apps/Linux/matlab to /cvs/cds/caltech/apps/Linux/matlab_old.  I installed the latest R2010b matlab from IMSS in /cvs/cds/caltech/apps/Linux/matlab and this seems to have made the cron job work on Mafalda now.

  4152   Thu Jan 13 16:41:07 2011 josephbUpdateCDSChannel names for LSC updated

I renamed most of the filter banks in the c1lsc model.  The input filters are now labeled based on the RF photodiode's name, plus I or Q.  The last set of filters in the OM subsystem (output matrix) have had the TO removed, and are now sensibly named ETMX, ETMY, etc.

We also removed the redundant filter banks between the LSCMTRX and the LSC_OM_MTRX.  There is now only one set, the DARM, CARM, etc ones.

The webview of the LSC model can be found here.

  4153   Fri Jan 14 01:55:26 2011 kiwamuUpdateLSCX arm locked with C1LSC digital control

 [Koji, Kiwamu]

 We succeeded in locking the X arm with the C1LSC digital control.

As we did on the day before yesterday, the feedback signal goes to MCL (#4141), but this time the signal is transfered from C1LSC through the RFM.

 


 (key points) 

- checking the state of the analog whitening filters at C1LSC rack.

   We took the transfer function of them and found that they were always on regardless of the clicking any buttons on medm.

To cancel the filter shape of the whitening, we put an unWhitening filter so that these transfer functions becomes flat in total.

The whitening filter approximately has : pole:150Hz, pole:150Hz, zero:15Hz, zero:15Hz (although these numbers came from by our eye ball fitting)   

 

 - demodulation phase adjustment

   We performed the same measurement as that of Suresh and Koji did yesterday (#4143) to adjust the phase of the PDH demodulation.

By changing the cable length we roughly adjusted the I-phase to eventually ~10 deg, which is close enough to 0 deg.

(probably some more efforts should be made as a part of daytime tasks)

Note that we are currently using the REFL33 demodulation board for this purpose (#4144). The LO power we put is about 16dBm.

The angle between I and Q at 11MHz is actually almost 90 deg.

This fact has been confirmed by putting a sinusoidal signal with a slightly different frequency (~100Hz) from that of the LO onto the RF input.

 

 - attenuation of RF signal

  Since the PDH signal taken by C1LSC's ADC had been saturated somewhat, we introduced a ND filter of 10 on the photo diode to attenuate the RF signal.

As a result the amplitude of the PDH signal on dataviewer became more reasonable. No more saturations.

 

(some notes)

 unWhitening filter           pole:15Hz. pole:15Hz, zero:150Hz, zero:150Hz

 C1LSC_MC_FM1   pole:1kHz, zero:10Hz

 Gain in digital control       G ~ -1

measured UGF  ~  200-300 Hz

 measured RFM delay ~ 125 usec 

  4154   Fri Jan 14 11:29:00 2011 kiwamuUpdateLSCexpected open loop TF of X arm locking

Here shows a plot of the expected open loop transfer function (TF) for the X arm locking.

xarm_oltf.png

I assume that the delay time of the digital system associated with the ADC/DAC and the digital filtering process is ~100 usec independently from the RFM delay according to Yuta's measurement (#3961).

Also I assume the MC2 pendulum has a pole at 1Hz with Q of ~5, and the X arm has its cavity pole at ~3kHz.

When the lock acquisition takes place, we used the red curve shown above in order to avoid a big DC feedback onto MC2.

Once the X arm became resonant at TEM00, we manually switched FM3 on, which is a boost filter containing a pole at  1Hz and a zero at 50Hz in order to suppress the residual motion below 1Hz.

The expected curve for the boosted state is drawn by the blue curve in the plot. 

With this open loop TF, the UGF can be realized only around 100-300 Hz due to the phase margin condition.

This expectation of the UGF is consistent with our measurement because we obtained the UGF around 200-300Hz.

In fact above 300Hz we observed that the control became unstable and started oscillating.

 

Quote:

 (some notes)

 unWhitening filter           pole:15Hz. pole:15Hz, zero:150Hz, zero:150Hz

 C1LSC_MC_FM1   pole:1kHz, zero:10Hz

 Gain in digital control       G ~ -1

measured UGF  ~  200-300 Hz

 measured RFM delay ~ 125 usec 

 

  4155   Fri Jan 14 12:29:57 2011 KojiUpdateLockingNext steps for the green

These are the next steps for a better operation of the arm locking. They are suitable for the day time activities

Reconfiguration of the X-End table

- End transmission power monitor (CDS model exists, need to configure the PD)

- IR steering mirror for the transmon

- Restore/align end green beam

- Relocate the end trans CCD

- Connect the video output cable for the X-end CRT monitor

LSC Whitening

- LSC Whitening binary IO connection

 


They are not urgent but also good things to do

MC servo characterization

- Error signal: frequency noise

- Loop characterization

Arm cavity characterization with cavity sweep

- Arm finesse for 1064nm and 532nm

- Arm FSR measurement with 1064 (and optionally with 532nm simultaneously)

- Arm g-factor for 1064nm and 532nm

  4156   Fri Jan 14 12:34:08 2011 KojiUpdateLSCX arm locked with C1LSC digital control

My feeling was that the saturation was caused by the LSC whitening filter which was always on.
Once the LSC whitening filter is controlled from C1LSC, we would be able to remove the attenuator.

Quote:

  - attenuation of RF signal

  Since the PDH signal taken by C1LSC's ADC had been saturated somewhat, we introduced a ND filter of 10 on the photo diode to attenuate the RF signal.

As a result the amplitude of the PDH signal on dataviewer became more reasonable. No more saturations.

 

ELOG V3.1.3-