40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 318 of 344  Not logged in ELOG logo
ID Date Author Typedown Category Subject
  660   Fri Jul 11 20:16:01 2008 EricDAQCamerasTaking data from the GC 750 Camera
Mafalda has been set up with a background process to constantly take data from the GC 750 camera (at the end of the x-arm) for the weekend. This camera will otherwise be inoperable until then.

In the small chance that this slows either Mafalda or the network to a crawl, the process to kill should have PID 26265.
  671   Tue Jul 15 10:09:42 2008 EricDAQCamerasDid anyone kill the picture taking process on Mafalda?
Did anyone kill the process on Mafalda that was taking pictures of the end mirror of the x-arm last Friday? I need to know whether or not it crashed of its own accord.
  673   Tue Jul 15 11:47:56 2008 JenneDAQPEMAccelerometer channels in ASS Adapt MEDM screen
Jenne, Sharon

We have traced which accelerometers correspond to which channels in the C1ASS_TOP MEDM screen.

Accelerometer Channel
------------- --------------------------
MC1-X C1:ASS-TOP_PEM_2_ADAPT_IN1
MC1-Y C1:ASS-TOP_PEM_3_ADAPT_IN1
MC1-Z C1:ASS-TOP_PEM_4_ADAPT_IN1
MC2-X C1:ASS-TOP_PEM_5_ADAPT_IN1
MC2-Y C1:ASS-TOP_PEM_6_ADAPT_IN1
MC2-Z C1:ASS-TOP_PEM_7_ADAPT_IN1

SEISMOMETER C1:ASS-TOP_PEM_1_ADAPT_IN1
  684   Wed Jul 16 17:36:51 2008 JohnDAQPSLFSS input offset
I changed the nominal FSS input offset to 0 from 0.3. Tolerance remains unchanged at +/-0.05.
  700   Fri Jul 18 19:43:55 2008 YoichiDAQComputersPSL fast channels cannot be read by dataviewer
At this moment only the PSL fast channels have trouble.
Rob restarted fb40m, c1IOVME, but no effect.
  826   Mon Aug 11 19:09:28 2008 JenneDAQPEMSeismometer DAQ is being funny
While looking at the Ranger seismometer's output to figure out what our max typical ground motion is, Rana and I saw that the DAQ output is at a weird level. It looks like even though the input to the DAQ channel is being saturated, the channel isn't outputing as many counts as expected to Dataviewer.

Sharon and I checked that the output of the seismometer looks reasonable - sinusoidal when I tap on the seismometer, and the the output of the SR560 (preamp) is also fine, and not clipping. If I stomp on the floor, the output of the SR560 goes above 2V (to about 3V ish), so we should be saturating the DAQ, and getting the max number of counts out. However, as you can see in the first figure, taken when I was tapping the seismometer, the number of counts at saturation is well beneath 32768counts. (16 bit machine, so the +-2V of the DAQ should have a total range of 65536. +2V should correspond to +32768counts.) The second figure shows 40 days of seismometer data. It looks like we saturate the DAQ regularly.

I did a check of the DAQ using an HP6236B power supply. I sent in 1V, 2V and 2.2V (measuring the output of the power supply with a 'scope), and measured the number of counts output on the DAQ.

Input Voltage [V]Counts on DataviewerExpected counts from 16 bit machine
11898316384
22933132768
2.22934732768


I'm not sure why the +1V output more than the expected number of counts (unless I mis-measured the output from the power supply).

Moral of the story is...when the DAQ is saturated, it is not outputting the expected number of counts. To be explored further tomorrow...
Attachment 1: SeisDAQ.png
SeisDAQ.png
Attachment 2: SeisData.png
SeisData.png
  917   Wed Sep 3 19:09:56 2008 YoichiDAQComputersc1iovme power cycled
When I tried to measure the sideband power of the FSS using the scan of the reference cavity, I noticed that the RC trans. PD signal was not
properly recorded by the frame builder.
Joe restarted c1iovme software wise. The medm screen said c1iovme is running fine, and actually some values were recorded by the FB.
Nonetheless, I couldn't see flashes of the RC when I scanned the laser frequency.
I ended up power cycling the c1iovme and run the restart script again. Now the signals recorded by c1iovme look fine.
Probably, the DAQ boards were not properly initialized only by the software reset.
I will re-try the sideband measurement tomorrow morning.
  1028   Mon Oct 6 12:45:41 2008 AlbertoDAQLSCC1LSC in coma
Alberto, Joe,

The C1LSC medm screen is frozen and the C1LSC computer is down. We tried to reboot and to restart it first turning off the power and then just rebooting remotely. None of them worked. We check whether any of the cable was unplugged but they were ok. Also all the led turned on to green after rebooting.
Trying to reboot we get the following error message: init_module: device or resource busy.

We called Alex who first suggested to check all the connection and then to swap the timing cable between two Pentek boards but the computer was still down.
It is possible that the board is dead. Alex and Rolf are going to look into this problem and for any spare board.

by now we can't lock any DOF of the IFO.
  1029   Mon Oct 6 16:41:33 2008 AlbertoDAQLSCC1LSC in coma

Quote:
Alberto, Joe,

The C1LSC medm screen is frozen and the C1LSC computer is down. We tried to reboot and to restart it first turning off the power and then just rebooting remotely. None of them worked. We check whether any of the cable was unplugged but they were ok. Also all the led turned on to green after rebooting.
Trying to reboot we get the following error message: init_module: device or resource busy.

We called Alex who first suggested to check all the connection and then to swap the timing cable between two Pentek boards but the computer was still down.
It is possible that the board is dead. Alex and Rolf are going to look into this problem and for any spare board.

by now we can't lock any DOF of the IFO.


Alex, Rob, Alberto,

Alex replaced the Pentek board used by C1LSC with a spare one that they had at the Wilson house. That fixed the DMA failure but since the board had a channel broken, one of the channels (POY) was still not available.

Looking at the wiring diagram of the ASC crate, we found that one of the Pentek boards in it was actually not used by anything and thus available to replace the bad one in LSC. We switched the two boards so that now the one that Alex installed is mounted in the ASC crate and it is connected to the cable labeled 1x2-ASC 6.

C1LSC is up again and all the channels in the C1LSC screen, including POY, now seem to be working properly.
  1066   Wed Oct 22 09:42:41 2008 AlbertoDAQComputersc1iool0 rebooted and MC autolocker restarted
This morning I found the MC unlocked. The MC-Down script didn't work because of network problems in communicating with scipe7, a.k.a. c1iool0. Telneting to the computer was also impossible so I power cycled it from its key switch. The first time it failed so I repeated it a second time and then it worked.
Yoichi then restarted c1iovme. It was also necessary to restart the MC autolocker script according to the following procedure:
- ssh into op440m
- from op440m, ssh into op340m
- restart /cvs/cds/caltech/scripts/scripts/MC/autolockMCmain40
  1114   Tue Nov 4 17:58:42 2008 AlbertoDAQPSLMC temperature sensor
I added a channel for the temperature sensor on the MC1/MC3 chamber: C1:PSL-MC_TEMP_SEN.
To do that I had to reboot the frame builder. The slow servo of the FSS had to get restarted, the reference cavity locked and so the PMC and MZ.
  1124   Fri Nov 7 18:38:19 2008 AlbertoDAQPSLMC temperature sensor hooked up
Alberto, Rana,
we found that the computer handling the signals from ICS-110B was C1IOVME so we restarted it. We changed the name of the channel to C1:PEM_TEMPS and the number to 16349. We tracked it up to the J14 connector of the DAQ.
We also observed the strange thing that both of the differential pairs on J13 are read by the channle. Also, if you connect a 50 Ohm terminator to one of the pairs, the signal even get amplified.

(The name of the channel is PEM-MC1_TEMPS)
  1130   Wed Nov 12 11:14:59 2008 CarynDAQPSLMC temp sensor hooked up incorrectly
MC Temperature sensor was not hooked up correctly. It turns out that for the 4 pin LEMO connections on the DAQ like J13, J14, etc. the channels correspond to horizontal pairs on the 4 pin LEMO. The connector we used for the temp sensor had vertical pairs connected to each BNC which resulted in both the differential pairs on J13 being read by the channel.
To check that a horizontal pair 4 pin LEMO2BNC connector actually worked correctly we unlocked the mode cleaner, and borrowed a connector that was hooked up to the MC servo (J8a). We applied a sine wave to each of the BNCs on the connector, checked the J13 signal and only one of the differential pairs on J13 was being read by the channel. So, horizontal pairs worked.
  1143   Tue Nov 18 13:28:08 2008 CarynDAQIOOnew channel for MC drum modes
Alberto has added a channel for the Mode Cleaner drum modes.
C1:IOO-MC_DRUM1
sample rate-2048
chnum-13648
  1228   Wed Jan 14 15:53:32 2009 steveDAQPSLMC temperature sensor

Quote:
I added a channel for the temperature sensor on the MC1/MC3 chamber: C1:PSL-MC_TEMP_SEN.
To do that I had to reboot the frame builder. The slow servo of the FSS had to get restarted, the reference cavity locked and so the PMC and MZ.


Where is this channel?
  1246   Thu Jan 22 14:38:41 2009 carynDAQPSLMC temperature sensor

Quote:

Quote:
I added a channel for the temperature sensor on the MC1/MC3 chamber: C1:PSL-MC_TEMP_SEN.
To do that I had to reboot the frame builder. The slow servo of the FSS had to get restarted, the reference cavity locked and so the PMC and MZ.


Where is this channel?


That's not the name of the channel anymore. The channel name is PEM-MC1_TEMPS. It's written in a later entry.
  1349   Tue Mar 3 11:39:50 2009 OsamuDAQComputers2 PCs in Martian

 Kiwamu and I brought 2 SUPER MICRO PCs from Willson house into 40m.

Both PCs are hooked up into Martian network. One is named as bscteststand for BSC which has been set up by Cds people and another one is named kami1 for temporary use for CLIO which is a bland new, no operating installed PC. This bland new PC will be returned Cds or 40m once another new PC which we will order within several days arrives.

IP address for each machine is 131.215.113.83 and 131.215.113.84 respectively.

We have installed CentOS5.2 into the new PC.

  1381   Mon Mar 9 23:55:38 2009 OsamuDAQComputersbscteststand and kami1 outside martian

This morning there was a confliction of tpman running on fb40m and kami1. Alex fixed it temporary but Rana suggested it was better to move both PCs outside martian. We moved both PCs physically to the control room and connected to general network with a local router. I believe it won't conflict anymore but if you guess these PC might have trouble please feel free to shutdown.

 

Today's work summary:

 *connected expansion chassis to bscteststand

 *obtained signals on dataviewer, dtt for both realtime and past data on bscteststand with 64kHz timing signal

 

Questions:

Excitation channels are not shown, only "other" is shown.

qts.mdl should run with 16kHz but 16kHz timing causes a slow speed on dataviewer and failing data aquisition on dtt. We are using 64kHz timing but is it really correct?

  1407   Mon Mar 16 15:19:52 2009 OsamuDAQElectronicsSR785

I borrowed SR785 to measure AA, AI noise and TF.

  1417   Sun Mar 22 23:16:41 2009 ranaDAQComputer Scripts / Programstpman restart
Could get testpoints but couldn't start excitations. Restarted tpman on daqawg. Works now.

Still no log file. Mad
  1528   Tue Apr 28 12:55:57 2009 CarynDAQPEMUnplugged Guralp channels

For the purpose of testing out the temperature sensors, I stole the PEM-SEIS_MC1X,Y,Z channels.

I unplugged Guralp NS1b, Guralp Vert1b, Guralp EW1b cables from the PEM ADCU(#10,#11,#12) near 1Y7 and put temp sensors in their place (temporarily).

  1540   Sat May 2 16:34:31 2009 carynDAQPEMGuralp channels plugged back in

I plugged the Guralp cables back into the PEM ADCU

       Guralp NS1b ---> #11

       Guralp Vert1b --->#10

       Guralp EW1b --->#12

  1643   Tue Jun 2 23:53:12 2009 peteDAQComputersreset c1susvme1

rob, alberto, rana, pete

we reset this computer, which was out of sync (16384 in the FE_SYNC field instead of 0)

  1661   Mon Jun 8 18:22:27 2009 AlbertoDAQLSCAdded PD11 I amd Q slow channels

I just added two slow channels to C0EDCUEPICS to monitor the input of PD11. The names are:

[C1:LSC-PD11_I_INMON]
[C1:LSC-PD11_Q_INMON]

  1733   Sun Jul 12 20:06:44 2009 JenneDAQComputersAll computers down

I popped by the 40m, and was dismayed to find that all of the front end computers are red (only framebuilder, DAQcontroler, PEMdcu, and c1susvmw1 are green....all the rest are RED).

 

I keyed the crates, and did the telnet.....startup.cmd business on them, and on c1asc I also pushed the little reset button on the physical computer and tried the telnet....startup.cmd stuff again.  Utter failure. 

 

I have to pick someone up from the airport, but I'll be back in an hour or two to see what more I can do.

  1735   Mon Jul 13 00:34:37 2009 AlbertoDAQComputersAll computers down

Quote:

I popped by the 40m, and was dismayed to find that all of the front end computers are red (only framebuilder, DAQcontroler, PEMdcu, and c1susvmw1 are green....all the rest are RED).

 

I keyed the crates, and did the telnet.....startup.cmd business on them, and on c1asc I also pushed the little reset button on the physical computer and tried the telnet....startup.cmd stuff again.  Utter failure. 

 

I have to pick someone up from the airport, but I'll be back in an hour or two to see what more I can do.

 I think the problem was caused by a failure of the RFM network: the RFM MEDM screen showed frozen values even when I was power recycling any of the FE computers. So I tried the following things:

- resetting the RFM switch
- power cycling the FE computers
- rebooting the framebuilder
 
but none of them worked.  The FEs didn't come back. Then I reset C1DCU1 and power cycled C1DAQCTRL.
 
After that, I could restart the FEs by power recycling them again. They all came up again except for C1DAQADW. Neither the remote reboot or the power cycling could bring it up.
 
After every attempt of restarting it its lights on the DAQ MEDM  screen turned green only for a fraction of a second and then became red again.
 
So far every attempt to reanimate it failed.
  1736   Mon Jul 13 00:53:50 2009 AlbertoDAQComputersAll computers down

Quote:

Quote:

I popped by the 40m, and was dismayed to find that all of the front end computers are red (only framebuilder, DAQcontroler, PEMdcu, and c1susvmw1 are green....all the rest are RED).

 

I keyed the crates, and did the telnet.....startup.cmd business on them, and on c1asc I also pushed the little reset button on the physical computer and tried the telnet....startup.cmd stuff again.  Utter failure. 

 

I have to pick someone up from the airport, but I'll be back in an hour or two to see what more I can do.

 I think the problem was caused by a failure of the RFM network: the RFM MEDM screen showed frozen values even when I was power recycling any of the FE computers. So I tried the following things:

- resetting the RFM switch
- power cycling the FE computers
- rebooting the framebuilder
 
but none of them worked.  The FEs didn't come back. Then I reset C1DCU1 and power cycled C1DAQCTRL.
 
After that, I could restart the FEs by power recycling them again. They all came up again except for C1DAQADW. Neither the remote reboot or the power cycling could bring it up.
 
After every attempt of restarting it its lights on the DAQ MEDM  screen turned green only for a fraction of a second and then became red again.
 
So far every attempt to reanimate it failed.

 

After Alberto's bootfest which was more successful than mine, I tried powercycling the AWG crate one more time.  No success.  Just as Alberto had gotten, I got the DAQ screen's AWG lights to flash green, then go back to red.  At Alberto's suggestion, I also gave the physical reset button another try.  Another round of flash-green-back-red ensued.

When I was in a few hours ago while everything was hosed, all the other computer's 'lights' on the DAQ screen were solid red, but the two AWG lights were flashing between green and red, even though I was power cycling the other computers, not touching the AWG at the time.  Those are the lights which are now solid red, except for a quick flash of green right after a reboot.

I poked around in the history of the curren and old elogs, and haven't found anything referring to this crazy blinking between good and bad-ness for the AWG computers.  I don't know if this happens when the tpman goes funky (which is referred to a lot in the annals of the elog in the same entries as the AWG needing rebooting) and no one mentions it, or if this is a new problem.  Alberto and I have decided to get Alex/someone involved in this, because we've exhausted our ideas. 

  1752   Wed Jul 15 17:18:24 2009 JenneDAQComputersDAQAWG gone, now back

Yet again, the DAQAWG flipped out for an unknowable reason.  In order of restart activities listed on the Wiki, I keyed the crate and nothing really happened, then I hit the physical reset button and nothing happened, and then I did the 'telnet....vmeBusReset', and a couple minutes later, it was all good again.

  1769   Tue Jul 21 17:01:18 2009 peteDAQDAQtemp channel PEM-PETER_FE

I added a temporary channel, to input 9 on the PEM ADCU.    Beware the 30, 31, and 32 inputs.  I tried 32 and it only gave noise.

 

 

  1831   Wed Aug 5 07:33:04 2009 steveDAQComputersfb40m is down
  1832   Wed Aug 5 09:25:57 2009 AlbertoDAQComputersfb40m is up

FB40m up and running again after restarting the DAQ.

  1836   Wed Aug 5 15:33:05 2009 rob, albertoDAQGeneralcan't get trends

We can't read minute trends from either Dataviewer or loadLIGOData from before 11am this morning. 

 

fb:/frames>du -skh minute-trend-frames/
 106G   minute-trend-frames

So the frames are still on the disk.  We just can't get them with our usual tools (NDS).

 

 Trying to read 60 days of minute trends from C1:PSL-PMC_TRANSPD yields:

Connecting to NDS Server fb40m (TCP port 8088)
Connecting.... done
258.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=09-06-06-22-34-02; Length=5184000 (s)
No data output.

 

Trying to read 3 seconds of full data works.

Second trends are readable after about 4am UTC this morning, which is about 9 pm last night.

 


  1841   Thu Aug 6 09:22:17 2009 AlbertoDAQGeneralcan't get trends

Quote:

We can't read minute trends from either Dataviewer or loadLIGOData from before 11am this morning. 

 

fb:/frames>du -skh minute-trend-frames/
 106G   minute-trend-frames

So the frames are still on the disk.  We just can't get them with our usual tools (NDS).

 

 Trying to read 60 days of minute trends from C1:PSL-PMC_TRANSPD yields:

Connecting to NDS Server fb40m (TCP port 8088)
Connecting.... done
258.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=09-06-06-22-34-02; Length=5184000 (s)
No data output.

 

Trying to read 3 seconds of full data works.

Second trends are readable after about 4am UTC this morning, which is about 9 pm last night.

 


 Yesterday Alex started transferring the data records to the new storage unit. That prevented us from accessing the trends for a fe hours.

The process had been completed and now we can read the trends again.

  2365   Tue Dec 8 10:20:33 2009 AlbertoDAQComputersBootfest succesfully completed

Alberto, Kiwamu, Koji,

this morning we found the RFM network and all the front-ends down.

To fix the problem, we first tried a soft strategy, that is, we tried to restart CODAQCTRL and C1DCUEPICS alone, but it didn't work.

We then went for a big bootfest. We first powered off fb40m, C1DCUEPICS, CODAQCTRL, reset the RFM Network switch. Then we rebooted them in the same order in which we turned them off.

Then we power cycled and restarted all the front-ends.

Finally we restored all the burt snapshots to Monday Dec 7th at 20:00.

  2874   Mon May 3 19:21:43 2010 AlbertoDAQEnvironmentBoot fest

[Alberto, Koji, Rana]

The RFM network failed today. We had to reboot the frame builder anf restart all the front end following the instructions for the "Nuclear Option".

Burt-restoring to May 1st at 18:07, or April 30 18:07 made c1sosvme crash. We had to reset the front ends again and restore to April 15th at 18:07 in order to make everything work.

Everything seems fine again now.

  3038   Wed Jun 2 18:36:20 2010 valeraDAQCDSNoise generators in LSP

Alex wrote a new code to implement LSP noise generator. The code is based on 64 bit random number generator from Numerical Recipes 3rd ed ch 7.1 (p 343).

Joe made two instances in the LSP model.

The attached plot shows the spectra and coherence of two generators. The incoherence is ~1/Navg - statistically consistent with no coherence.

Attachment 1: noisegenerators.pdf
noisegenerators.pdf
  3090   Sat Jun 19 17:31:48 2010 ranaDAQCDSExcess Noise in C1:IOO-MC_DRUM1 fixed by reboot

I was getting an excess noise in the C1:IOO-MC_DRUM1 channel - it was a flat spectrum of 10 cts/rHz (corresponding to 600 uV/rHz).

I tried a few things, but eventually had to power cycle the crate with c1iovme in order to recover the standard ADC noise level of 3x10^-3 cts/rHz with a 1/sqrt(f) knee at 10 Hz.

I checked the gain of the channel by injecting a 2 Vpp sine wave at 137.035 Hz. 2Vpp as measured on a scope gives 31919 cts instead of the expected 32768, giving a 2.5% error from what we would have naively calculated.

Even so, the noise in this channel is very surprisingly good: 0.003 / (31919 / 2) = 187 nV /rHz.  The best noise I have previously seen from an ICS-110B channel is 800 nV/rHz. What's going on here?

  3117   Thu Jun 24 18:47:26 2010 FrankDAQIOOVME crate rebooted

we had to reboot the IOO VME crate right before lunch as the DAQ wasn't working correct meaning showing no real signals anymore, only strange noise. The framebuilder and everything else was working fine at that time.

  • The channel used for the phase noise measurement stopped showing any useful signal right after midnight, so all the other IOO-MC signals.
  • The data taken with those channels showed something like a 140 counts or so of steady offset with something which looked like the last bit fluctuating.
  • Whatever signal we connected to the input it didn't change at all, floating/shorted input, sine wave etc.
  • the other channels for the MC which we checked showed the same strange behaviour

As the other channels showed the same effect we decided to reboot the crate and everything was fine afterwards.

  1   Wed Oct 17 18:46:33 2007 ranaConfigurationGeneraleLog Change
This is the first entry in the new 40m eLog.

Its GWs or bust now! Big grin



[Hnull][/Hnull]
  20   Fri Oct 26 21:48:40 2007 waldmanConfigurationOMCFiber to 056
I set up a 700 mW NPRO in Rana's lab and launched it onto a 50m fiber. I got a few mW onto the fiber, enough to see with a card before disabling the laser. The fiber now runs along the hallway and terminates in rm 056. Its taped down everywhere someone might trip on it, but don't go out of your way to trip on it or pull on it because you are curious. Tomorrow I will co-run a BNC cable and attenuate the NPRO output so it can only send a few mW and so be laser safe. Then we can try to develop a procedure to align the beam to a suspended OMC and lock our suspended cavity goodness.

Notes to self: items needed from the 40m
  • ND10 and ND20 neutral density filter
  • EOM and mount set for 4 inch beam height
  • Post for fiber launch to get to 4 inch
  • Mode matching lens at 4in
  • 3x steering mirror at 4in
  • RF photodiode at 4in
  • Post for camera to 4in
  • Light sheild for camera
  • Long BNC cable
Some of these exist at 056 already
  21   Sat Oct 27 19:00:44 2007 waldmanConfigurationOMCHanging, locked OMC with REFL extracted.
I got the OMC locked to the fiber output today. It was much more difficult than I expected and I spent about 30 minutes or so flailing before stopping to think. The basic problem is that the initial alignment is a search in 4-dimensional space and there is naturally only one signal, the reflected DC level, to guide the alignment. I tried to eyeball the alignment using the IR card and "centering" the beams on mirrors, but I couldn't get close enough to get any light through. I also tried to put a camera on the high reflector transmission, but with 1.5 mW incident on the cavity, there is only 1.5 microwatts leaking through in the best case scenario, and much, much less during alignment.

I resolved the problem by placing a high reflector on a 3.5 inch tall fixed mount and picking off the OMC transmitted beam before it reaches the DC diodes. I took the pickoff beam to a camera. The alignment still sucked because even though the beam cleanly transmitted the output coupler, it wasn't anywhere close to getting through the OTAS. To resolve this problem, I visually looked through the back of M2 at M1 and used the IR card to align the beam to the centers of each mirror. That was close enough to get me fringes and align the camera. With the camera aligned, the rest was very easy.

I restored the PDH setup we know and love from the construction days and locked the laser to the OMC with no difficulty. The laser is in Rana's lab so I send the +/- 10V control signal from the SR560 down a cable to 058E where it goes into the Battery+resistor box, the Throlabs HV amplifier, and finally the FAST channel of the NPRO. BTW, a simple experiment sows that about 35 +/- 3 V are required to get an FSR out of the NPRO, hence the Thorlabs HV. The EOM, mixer, splitter, etc is on the edge of the table.

With this specific OMC alignment, ie. the particular sitting on EQ stops, it looks like all of the ghost beams have a good chance of coming clear. I can fit a 2 inch optic in a fixed mount in between the end of the breadboard and the leg of the support structure. A picture might or might not be included someday. One of the ghost beams craters directly into the EQ stop vertical member. The other ghost barely misses M2 on its way down the length of the board. In its current configuration, the many REFL beam misses the leg by about 1.5 inches.
  22   Sun Oct 28 03:03:42 2007 ranaConfigurationIOOThree Way Excitement
We've been trying to measure the MC mirror internal mode frequencies so that we can measure
their absorption before and after drag wiping.


It looked nearly impossible to see these modes as driven by their thermal excitation level;
we're looking at the "MC_F" or 'servo' output directly on the MC servo board.

Today, I set up a band limited noise drive into the 'Fast POS' inputs of the 3 MC coil
driver boards (turns out you can do this with either the old HP or the SR785).

Frequencies:
MC1     28.21625 kHz
MC2     28.036   kHz
MC3     28.21637 kHz

I don't really have this kind of absolute accuracy. These are just numbers read off of the SR785.

The other side of the setup is that the same "MC_F" signal is going into the SR830 Lock-In which
is set to 'lock-in' at 27.8 kHz. The resulting demodulated 'R" signal (magnitude) is going into
our MC_AO channel (110B ADC).

As you can see from the above table, MC1 and MC3 are astonishingly and annoyingly very close in
frequency. I identified mirrors with peaks by driving one at a time and measuring on the spectrum
analyzer. I repeated it several times to make sure I wasn't fooling myself; it seems like they
are really very close
but distinct peaks. I really wish we had chipped one of these mirrors
before installing them.



Because of the closeness of these drumhead modes, we will have to measure the absorption by making long
measurements of this channel.
  26   Mon Oct 29 12:20:15 2007 waldmanConfigurationOMCChanged OMS filters
I changed the OMS configuration so that some of the OMC-SUS LED channels go to a breakout box so that we can input the PDH error signal. After lunch, we will try to lock the cavity with a PDH error signal and digital filters. Then its on to dither locked stuff. Note that this LED business will have to be changed back some day. For now, it should be extremely visible because there are dangling cables and a hack job interface lying around.
  27   Mon Oct 29 23:10:05 2007 waldmanConfigurationOMCLost in DAQspace
[Pinkesh, Sam]

In setting up a Digital based control of the hanging OMC, we naively connect the Anti-Imaging filter output to an Anti-Aliasing input. This led to no end of hell. For one thing, we found the 10 kHz 3rd order butterworth at 10 kHz, where it should be based on the install hardware. One wonders in passing whether we want a 10 kHz butter instead of a 15 kHz something else, but I leave that for a later discussion. Much more bothersome is a linear phase shift between output and input that looks like ~180 microseconds. It screams "What the hell am I!?" and none of us could scream back at it with an answer. I believe this will require the Wilson House Ghost Busters to fully remedy on the morrow.
Attachment 1: SS.pdf
SS.pdf
Attachment 2: SS.gif
SS.gif
  30   Tue Oct 30 13:58:07 2007 ajwConfigurationIOOMC Ringdowns
Here's a quick fit-by-eye to the latter part of the data from tek00000.xls.

The prediction (blue) is eqn 41 of
http://www.ligo.caltech.edu/docs/P/P000017-A.pdf

T1 = T2 = 0.002. Loss1 = Loss2 = 150 ppm.
MC3 assumed perfectly reflecting.
Velocity = 320 um/s (assumed constant), 2 usec into the ringdown.

OK, there's one little fudge factor in the prediction:
I multiplied D by 2.
Attachment 1: CavityRingdown.png
CavityRingdown.png
Attachment 2: CavityRingdown.m
% CavityRingdown.m
% Eqn 41 of 
% "Doppler-induced dynamics of fields in Fabry–Perot
% cavities with suspended mirrors", Malik Rakhmanov (2000).
% http://www.ligo.caltech.edu/docs/P/P000017-A.pdf

clear all

% read in ringdown timeseries:
at = importdata('tek00000.csv');
... 121 more lines ...
  40   Wed Oct 31 15:22:59 2007 robConfigurationIOOMode Cleaner transfer function
I measured the transfer function of the input mode cleaner using a PDA255 and the ISS. First I put the PD in front of the ISS out-of-loop monitor diode and used an SR785 to measure the swept sine transfer function from the Analog IN port of the ISS to the intensity at the PD. Then I moved the PD to detect the light leaking out from behind MC2, using ND filters to get the same DC voltage, and measured the same transfer function. Dividing these two transfer functions should take out the response of the ISS and the PD, and leave just the transfer function of the MC. A plot of the data, along with a single-pole fit, are attached.

The fit is pretty good for a single pole at 3.79 kHz. There's a little wiggle around 9kHz due to ISS weirdness (as Tobin has not been giving it the attention it requires), but this shouldn't affect this result too much. Using the known MC length of 27.0955m, and assuming that MC1 and MC3 have a power transmissivity of 2000ppm and MC2 is perfectly reflecting, the total round trip loss should be about 300ppm. The fitted finesse is 1460.
Attachment 1: MCtf.pdf
MCtf.pdf
  45   Thu Nov 1 11:45:30 2007 tobinConfigurationIOOMode cleaner drag-wiping
Andrey, Bob, David, John Miller, Rana, Rob, Steve, Tobin

Yesterday we vented the vacuum enclosure and opened up the chamber containing MC1 & MC3 by removing the access connector between that chamber and the OMC chamber. Rana marked MC1's location with dogs and then slid the suspension horizontally to the table edge for easy drag-wiping access. The optic was thoroughly hosed-down with the dionizer, in part in an effort to remove dust from the cage and the top of the optic. Drag-wiping commenced with Rob squirting (using the 50 microliter syringe) and Tobin dragging (using half-sheets of Kodak lens tissue). We drag-wiped the optic many (~10) times, concentrating on the center but also chasing around various particles and a smudge on the periphery. There remains one tiny speck at about the 7:30 position, outside of the resonant spot area, that we could not dislodge with three wipes.

Today we drag-wiped MC3. First we slid MC1 back and then slid MC3 out to the edge of the table. We disconnected the OSEM cables in the process for accessibility, and MC1 is perched at an angle, resting on a dog. We did not blow MC3 with the deonizer, not wanting to blow particles from MC3 to the already-cleaned MC1. We drag-wiped MC3 only three times, all downward drags through the optic center, with Steve squirting and Tobin dragging. Some particles are still visible around the periphery, and there appears to be a small fiber lodged near the optic center on the reverse face.

Andrey and Steve have opened up MC2 in preparation for drag-wiping that optic after lunch.
  67   Tue Nov 6 10:42:01 2007 robConfigurationIOOmode cleaner locked
Increased the power exiting the PSL by turning the half-wave plate after the MOPA, opened the PSL shutter, and aligned the mode cleaner to the input beam. It wasn't that hard to find the beam with the aperture open all the way on the MC2 camera. The transmitted power is now 2.9 arbitrary units, while the input power is 1.2 arbitrary units. Not sure yet if that's an increase or decrease in efficiency, since no one posted numbers before the vent. Also turned on the input-steering PZTs and saw a REFL beam on the camera.
  70   Tue Nov 6 15:37:34 2007 robConfigurationSUSrampdown script
/cvs/cds/caltech/scripts/SUS/rampdown.pl is now in the crontab for op340m, running every half-hour at 15&45. It checks the suspension watchdog trip levels, and reduces them by 20 if they are above 150.
  71   Tue Nov 6 16:48:54 2007 tobinConfigurationComputersscopes on the net
I configured our two 100 MHz Tektronix 3014B scopes with IP addresses: 131.215.113.24 (scope0) and 113.215.113.25 (scope1). Let the scripting commence!

There appears to be a Matlab Instrument Control Toolbox driver for this scope.
ELOG V3.1.3-