40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 35 of 344  Not logged in ELOG logo
IDup Date Author Type Category Subject
  1715   Thu Jul 2 16:45:06 2009 ClaraUpdatePEMBonnie and Clyde are officially in operation! (Butch Cassidy and the Sundance Kid are in temp position)

I hooked up Bonnie and Clyde last night and tested it today. First I tried some loud noises to make sure I could identify them on the readout. Then, Steve suggested I try to look for some periodic stuff. I set up Butch Cassidy and the Sundance Kid on the cabinets by the MC2 optic. Now for graphs!

 

bonnie_test_marked.png

I tapped on the microphone a few times. I also yelled a bit, but this is sampling by seconds, so perhaps they got overwhelmed by the tapping.

bonnie_test2_marked.png

This time I tried some more isolated yells. I started with a tap so I'd be sure to be able to recognize what happened. Apparently, not so necessary.

bonniebutch_2sbeat_marked.png

Here, it looks like a pretty strong periodic pattern on the second mic (Butch Cassidy). I replaced the lines with dashed ones where the pattern was a little less clear. Possibility interference from something. Mic1 (Bonnie) seems to show a pretty regular beat pattern, which seems reasonable, as it isn't particularly close to any one instrument fan.

 

So, anyway. I thought those were neat. And that I wanted to share.

 

  1716   Thu Jul 2 17:37:36 2009 steveUpdateVACV1 interlock test

Joe, Alberto and Steve

We tested gate valve V1 interlock by :

1, decelerated rotation by brake from maglev controller unit.

2, turned maglev  controller off from controller unit.

3, unpluged 220VAC plug from wall socket

None of the above action triggered V1 to close. This needs to be corrected in the future.

The MEDM monitor screen of maglev indicated the correct condition changes.

 

 

  1717   Tue Jul 7 15:08:49 2009 KojiSummaryPhotos40 high school students visited 40M

Alan and Alberto conducted a tour of 40 high-school students.
It may be the same tour that Rana found a spare PMC during the tour explanation as far as I remember...

  1718   Tue Jul 7 16:06:59 2009 ClaraUpdateComputer Scripts / ProgramsDTT synchronization errors, help would be appreciated

I am attempting to use the DTT program to look at the coherence of the individual accelerometer signals with the MC_L signal. Rana suggested that I might break up the XYZ configuration, so i wanted to see how the coherence changed when I moved things around over the past couple of weeks, but I keep getting a synchronization error every time I try to set the start time to more than about 3 days ago. I tried restarting the program and checking the "reconnect" option in the "Input" tab, neither of which made any kind of difference. I can access this data with no problem from the Data Viewer and the Matlab scripts, so I'm not really sure what is happening. Help?

EDIT: Problem solved - Full data was not stored for the time I needed to access it for DTT.

  1719   Wed Jul 8 10:56:04 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

This week, I've been working on adapting the last week's circuit to make it buildable. Mostly this has involved picking components that are already in the lab, adding tunable components when necessary, and planning roughly how the components should be laid out on a board. I then built the circuit and put it in a box with BNC connectors for easy connection during testing. A picture of the built circuit is attached.

For initial testing, the transformer was removed from the design; since this changed the response of the circuit, I added two resistors to correct the response. A figure showing a schematic of the built circuit is attached. The expected responce of the circuit is also shown; the magnitude (solid) and phase (dashed) of the voltage across the EOM are shown in green, and the impedance of the circuit is shown in blue. While this response has sharp peaks and 50 Ohms (34 dB) of impedance at resonances, the gain is low compared to the circuit with the transformer. This means that, as is, this circuit cannot be used to drive the EOM; it is simply for testing purposes.

  1720   Wed Jul 8 11:05:40 2009 Chris ZimmermanUpdateGeneralWeek 3/4 Update

The last week I've spent mostly working on calculating shot noise and other sensitivities in three michelson sensor setups, the standard michelson, the "long range" michelson (with wave plates), and the proposed EUCLID setup.  The goal is to show that there is some inherent advantage to the latter two setups as displacement sensors.  This involved looking into polarization and optics a lot more, so I've been spending a lot of time on that also.  For example, the displacement sensitivity/shot noise on the standard michelson is around 6:805*10^-17 m/rHz at L_=1*10^-7m, as shown in the graph.  NSD_Displacement.png

  1721   Wed Jul 8 11:08:43 2009 ZachUpdateCamerasGigE Phase Camera

The plan for the optical setup has been corrected after it was realized that it would be impossible to isolate a 29.501 MHz frequency from a 29.499 MHz one because they are so close in value.  Instead, we decided to adopt the setup pictured below.  In this way, the low-pass filter should have no trouble isolating 29.501-29.5 MHz from 29.501 + 29.5 MHz.  Also, we decided to scrap the idea of sending Alberto's laser through a fiber optic cable after hearing rumors of extra lasers.  Since I shouldn't have to share a beam when the second laser comes in, I plan on setting up both lasers on the same optics bench.  I've been working on the software while waiting for supplies, but I should be able to start building the trigger box today (assuming the four-pair cable is delivered).

  1722   Wed Jul 8 11:13:36 2009 AlbertoOmnistructureComputerswireless router disconnected

Once again, this morning I found the wireless router disconnected from the LAN cable. No martian WiFi was available.

I wonder who is been doing that and for what reason.

  1723   Wed Jul 8 12:36:15 2009 ClaraUpdatePEMCoherences and things

After setting up the microphones last week, I modified the Wiener filtering programs so as to include the microphone signals. They didn't seem to do much of anything to reduce the MC_L signal, so I looked at coherences. The microphones don't seem to have much coherence with the MC_L signal at all. I tried moving Bonnie to near the optical table next to the PSL (which isn't in a vacuum, and thus would, presumably, be more affected by acoustic noise), but that didn't seem to make much of a difference. Eventually, I'd like to put a mic in the PSL itself, but I need to work out how to mount it first.

DSC_0564.JPG

Bonnie's new location.

You can see in bonnie_butch.pdf that none of the mic signals are giving very good coherence, although they all seem to have a peak at 24 Hz. (In fact, everything seems to have a peak there. Must be a resonant frequency of something in the mode cleaner.)

I've also attached plots of the coherences for all six accelerometers and the three Guralp seismometer axes. I plotted the most coherent traces together in the last pdf: the y-axes of the MC2 accelerometer and the two seismometers (the Ranger measures ONLY y) and, interestingly, the z-axis of the MC2 accelerometer. Unsurprisingly, the seismometers are most coherent at the low frequencies, and the MC2-Y accelerometer seems to be coherent at very similar frequencies. The MC2-Z accelerometer, on the other hand, seems to be coherent at the higher frequencies, and is highly complementary to the others. I am not really sure why this would be...

Finally, I was curious about how the noise varies throughout the day, because I didn't want to mistakenly decide that some particular configuration of accelerometers/seismometers/whatever was better than another b/c I picked the wrong time of day to collect the data. So, here is a plot of Wiener filters (using only accelerometer data) taken over 2-hour intervals throughout the entirety of July 6, 2009 (midnight-midnight local).

2hr_allday_1.png

It's a little bit confusing, and I should probably try to select some representative curves and eliminate the rest to simplify things, but I don't have time to do that before the meeting, so this will have to suffice for now.

  1724   Wed Jul 8 18:46:56 2009 DmassAoGElectronicsBeam Scan Funky

The beam scan (which has been living in the bridge subbasement for a bit now) is in a state of imperfection.

I noticed that:

  • The waist reading seems to change by not insignificant amounts as you move the spot across the head, even for just small perturbations about the center.
  • None of the features which require two slits seem to be working (unsure if this is software or hardware related)

I took some pictures to try and illuminate the situation - The inverted images are included to make it easier to see the flecks (?) in the slits

I am not sure how to figure out if any bit of the scan is/has been fried.

 

Pending further investigation, enjoy large error bars in your scan measurements!

 

PICTURES OF BOTH SLITS ON THE BEAMSCAN HEAD:

  1725   Wed Jul 8 19:13:19 2009 AlbertoUpdatePSLPSL beam aligned to the Mode Cleaner

Today I tuned the periscope on the PSL table to align the beam to the Mode Cleaner. With the Wave Front Sensor control off, I minimized the reflection from the MC and maximized the transmission. While doing that I also checked that the transmitted beam after the MC didn't lose the alignment with the interferometer's main Faraday isolator.

In this way, I've got a reflection, as read from the MC_REFLPD_MC, of about 0.6. Then I centered the WFS on the AS table. After that the WFS alignment control brought the reflection to 0.25 and a nice centered bull-eye spot showed on the monitor.

  1726   Wed Jul 8 19:42:37 2009 ClaraUpdatePEMBonnie moved to PSL, getting some coherence with the PMC_ERR channel

In her position overlooking whichever table it is that is next to the PSL, Bonnie drummed up some decent coherence with the PSL-PMC_ERR channel, but not so much with the MC_L. I moved her into the PSL itself, and now there is rather good coherence with the PMC_ERR channel, but still not so great for MC_L.

DSC_0567.JPG

Bonnie's new home in the PSL.

  1727   Thu Jul 9 02:18:09 2009 ranaUpdatePEMBonnie moved to PSL, getting some coherence with the PMC_ERR channel
My guess is that we need a different acoustic strategy. The microphones are mainly for high frequencies,
so you should not expect any coherence with MC_L (or even better, MC_F) below 100 Hz. I expect that the
main coherence for MC_F will come from the PSL in that band.

After subtracting that one out, we should look at the signal from the lock of the X or Y arm, and see
if we can nail that by putting a mic right above the AS table (leaving enough room to take the lid off).
If that works OK, we can find a spot under the lid and se if it gets better.
  1728   Thu Jul 9 19:05:32 2009 ClaraUpdatePEMmore mic position changes; mics not picking up high frequencies

Bonnie has been strung up on bungees in the PSL so that her position/orientation can be adjusted however we like. She is now hanging pretty low over the table, rather than being attached to the hanging equipment shelf thing. Butch Cassidy has been hung over the AS table.

Moving Bonnie increased the coherence for the PMC_ERR_F signal, but not the MC_L. Butch Cassidy doesn't have much coherence with either.

I noticed that the coherence would drop off very sharply just after 10 kHz - there would be no further spikes or anything of the sort. I used my computer to play a swept sine wave (sweeping from 20Hz to 10kHz) next to Butch Cassidy to see if the same drop-off occurred in the microphone signal itself. Sure enough, the power spectrum showed a sharp drop around 10kHz. Thinking that the issue was that the voltage dividers had too high impedance, I remade one of them with two 280 Ohm and one 10 Ohm resistor, but that didn't make any difference. So, I'm not sure what's happening exactly. I didn't redo the other voltage divider, so Bonnie is currently not operating.

 

  1729   Thu Jul 9 19:24:50 2009 ranaUpdatePEMmore mic position changes; mics not picking up high frequencies
Might be the insidious 850 Hz AA filters in the black AA box which precedes the ADC.

Dan Busby fixed up the PSL/IOO chassis. WE might need to do the same for the PEM stuff.
  1730   Fri Jul 10 17:32:08 2009 ranaUpdateEnvironmentseisBLRMS & mafalda restarted
Rana, Alberto

Mafalda's ethernet cable had fallen out of the connector on the hub-side. We reconnected it and rebooted mafalda and restarted seisBLRMS.

Mafalda didn't mount /cvs/cds on start up for some reason. I mounted it using 'sudo mount linux1:/home/cds /cvs/cds' and it took at least
30 seconds, so maybe there's a timeout issue. Seems OK now.
  1731   Fri Jul 10 19:56:23 2009 rana, kojiOmnistructureEnvironmentChanged office temp

I have increased the temperature setpoint in the office area by ~0.75 deg F. Figure attached. Also a few days ago I increased the setpoint of the AC in the control room. Looks like the Laser is able to handle the changes in office area temperature so far, but lets see how it fares over the weekend.

  1732   Sun Jul 12 20:05:06 2009 ranaOmnistructureEnvironmentChanged office temp
This is a 7-day minute trend. There's no obvious effect in any of the channels looking back 2 days.

Seems like the laser chiller fix has made the laser much more immune to the office area temperature.
  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.

  1734   Sun Jul 12 23:14:56 2009 JenneOmnistructureGeneralWeb screenshots aren't being updated

Before heading back to the 40m to check on the computer situation, I thought I'd check the web screenshots page that Kakeru worked on, and it looks like none of the screens have been updated since June 1st.  I don't know what the story is on that one, or how to fix it, but it'd be handy if it were fixed.

  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. 

  1737   Mon Jul 13 15:14:57 2009 AlbertoUpdateComputersDAQAWG

Today Alex came over, performed his magic rituals on the DAQAWG computer and fixed it. Now it's up and running again.

I asked him what he did, but he's not sure of what fixed it. He couldn't remember exactly but he said that he poked around, did something somewhere somehow, maybe he tinkered with tpman and eventually the computer went up again.

Now everything is fine.

  1738   Mon Jul 13 15:48:05 2009 ranaOmnistructureEnvironmentRemoval of the cold air deflection device for the MOPA chiller
Around 2 PM today, I removed the blue flap which has been deflecting the cold air from the AC down into the laser chiller.
Let's watch the laser trends for a few days to see if there's any effect.
  1739   Mon Jul 13 16:59:10 2009 ZachUpdate GigE Phase Camera

Today, I moved the router from on top of the PSL into the control room in order to perform dark field tests on the GC650 (which I also moved).  The GC750 along with the lens that was on it and the mount it was on has been lent to Ricardo's lab for the time being.  I successfully triggered the GC650 externally and I also characterized the average electronic noise.  For exposure times less than 1 microsecond, the average noise contribution appears to be a constant 15 on a 12-bit scale.

  1740   Mon Jul 13 23:03:14 2009 rob, albertoOmnistructureEnvironmentRemoval of the cold air deflection device for the MOPA chiller

Quote:
Around 2 PM today, I removed the blue flap which has been deflecting the cold air from the AC down into the laser chiller.
Let's watch the laser trends for a few days to see if there's any effect.


Alberto has moved us to stage 2 of this experiment: turning off the AC.

The situation at the control room computers with the AC on minus the blue flap is untenable--it's too cold and the air flow has an unpleasant eye-drying effect.
  1741   Tue Jul 14 00:32:46 2009 rob, albertoOmnistructureEnvironmentRemoval of the cold air deflection device for the MOPA chiller

Quote:

Quote:
Around 2 PM today, I removed the blue flap which has been deflecting the cold air from the AC down into the laser chiller.
Let's watch the laser trends for a few days to see if there's any effect.


Alberto has moved us to stage 2 of this experiment: turning off the AC.

The situation at the control room computers with the AC on minus the blue flap is untenable--it's too cold and the air flow has an unpleasant eye-drying effect.


I turned the AC back on because the temperature of the room was going up so also that of the laser chiller.
  1742   Tue Jul 14 00:57:11 2009 AlbertoUpdateLockingphotodiode alignment check

Since lately the alignment of the input beam to the interferometer has changed, I went checking the alignment of the beam on the photodiodea. They were all fine except for pd9, that is AS DD 199. Here the DC is totally null. The beam seems to go right on the diode but the scope on the PD's DC output shows no power. This is really strange and bad.

  1743   Tue Jul 14 14:54:19 2009 steveConfigurationComputersfb40m2 in 1Y6

Alex and Steve,

SunFire x4600 ( not  MEGATRON 2 , it is fb40m2 ) and JetStor ( 16 x 1 TB drives ) were installed on side rails at the bottom of 1Y6

We cleaned up the fibres and cabling in 1Y7 also

  1744   Tue Jul 14 16:31:46 2009 ClaraUpdatePEMFrequency Response of Microphone (Bonnie)

So, I actually took these measurements last week, but I didn't get around to making nice plots and things until now. I figured the time while I wait for the spectrum analyzer to do its thing was a good time.

Having been unable to locate the SR785 and also unsure how to connect it to a computer speaker (and also unable to find a free one), I downloaded a demo of a function generator onto my computer and just used that. (Same thing I used to do the swept sine that created the frequency power response plots I posted last week.) I set the program to a number of different frequencies and had the other end of the cable hooked into the oscilloscope to see a) if I could pick out the frequency and b) see how the magnitude of the microphone output varied with the frequency.

The first set of measurements I took, I didn't realize that I could increase the output power of the function generator. Because the generated sound at the default setting was relatively quiet, the oscilloscope traces were pretty chaotic, so I usually froze the trace so that I could look at it better. I ended up with a lot of weird jumps in the magnitude, but I later realized that there was a lot of beating going on at some frequencies, and the amplitude changes were probably much more drastic for the -20 dB sounds than the 6 dB sounds, since it was closer in amplitude to the surrounding noises. So, I've included that data set in my plots for the sake of completeness, but I'm pretty sure that it is useless.

Once I realized I could increase the power output for the signal generator, I took a set of data with and without the voltage divider at 6 dB. There was a cluster of frequencies that showed significant beating around 1700-3000 Hz in the data WITH the voltage divider, but I did not see any clear beating in the data WITHOUT. In the plots, I simply plotted up the highest and lowest amplitudes I measured for the frequencies with significant beating, since it was obviously hard to tell what the amplitude would have been without any background noise. In the w/o volt. div. set, although I didn't see any obvious beat patterns, the measured amplitudes did jump slightly at the frequencies that showed beats with the voltage divider. So, perhaps I was just not seeing them, but they influenced my amplitude measurements? I'm not sure if it would be possible for the voltage divider itself to cause beat frequencies.

 (Note: the amplitudes measured were from zero to peak, as the oscilloscope I was using wouldn't show a big enough vertical range to easily measure the peak-to-peak voltage difference.)

I've attached two plots of my measurements. One has a regular x-scale and includes all the measurements. The second has a logarithmic x-scale and omits the 20 Hz points. I had some troubles being able to pick out the 20 Hz signal on the oscilloscope... I don't know if my computer speakers just don't work well at that frequency or what, but either way, those points seemed highly suspect, and omitting them from the log plot allowed me to spread things out more.

One thing I'm not sure about is the 3000 Hz point. It was one of the ones with a beat frequency (~130 Hz), and the amplitudes were pretty low. The corresponding point from the non-voltage-divider data set is also low. So, I'm not sure what's happening there.

The one thing that I do think is quite clear is that the 1000 Hz drop-off in power when the microphone is connected to the ADC has nothing to do with the voltage divider. Beat issues aside, the shapes are very similar (pay no attention to the absolute scale... obviously, the voltage responses with and without the voltage divider were very different, and I just scaled them to fit in the same plot).

Update: Jenne pointed out that I was not absolutely clear about the voltage scale in my plots. The GREEN and BLUE points are on a mV scale, and the RED points are on a 10mV scale. I should probably redo the plots in Matlab in eventuality, since Excel is hard to use if you want to do anything that is not extremely basic with your plots, but this was my solution for the time being. So, the fact that the RED points, which are the data taken WITHOUT the voltage divider, are lower than the GREEN ones does not in any way indicate that I measured lower voltages when the voltage divider was not used.

Also, a to do list:

- Many of the beat frequencies I picked out were veeeeery slow, indicating that something is going at a frequency that is very close to the arbitrary frequencies I chose to sample, which is a little strange. That, combined with the fact that I saw clear beats with the voltage divider but not without leads me to believe that it may be worth investigating the frequency response of the voltage divider itself.

- Redo the measurements near the anomalous 3000 Hz point with a higher density of sampled frequencies to try to see what the heck is going on there.

  1745   Tue Jul 14 17:48:20 2009 JenneOmnistructureEnvironmentRemoval of the cold air deflection device for the MOPA chiller

Quote:

Quote:

Quote:
Around 2 PM today, I removed the blue flap which has been deflecting the cold air from the AC down into the laser chiller.
Let's watch the laser trends for a few days to see if there's any effect.


Alberto has moved us to stage 2 of this experiment: turning off the AC.

The situation at the control room computers with the AC on minus the blue flap is untenable--it's too cold and the air flow has an unpleasant eye-drying effect.


I turned the AC back on because the temperature of the room was going up so also that of the laser chiller.


I reinstalled the blue-flap technology on the AC, because the MOPA power was dropping like a rock. A light-ish rock since it wasn't going down too fast, but the alarms started going a little while ago because PMC trans was too low, because the power was getting a little low. The laser water chiller is reading 21.97C, which is higher than it normally does/did before the AC shenanigans (It usually reads 20.00C).

Attached is a look-back of 18 hours, during which you can see in the AMPMON the time that Rana removed the blue flap around 2pm yesterday and the AMPMON changes a little bit, but not drastically, the time around 11pm when the AC was turned off, and AMPMON goes down pretty fast, and about 12:30am, when Alberto turned the AC back on, and AMPMON starts to recover. I think that the AMPMON starts to go down again in the morning because it's been crazy hot here in Pasadena, so the room might be getting warmer, especially with the laser chiller-chiller not actively chilling the laser chiller (by not being pointed at the water chiller), so the water isn't getting as cold, and the HTEMP started to go up.

In the last few minutes of having put the blue flap back on the AC, the laser chiller is already reading a lower temperature, and the AMPMON is starting to recover.
  1746   Wed Jul 15 08:59:30 2009 steveUpdateComputersfb40m

The fb40m just went out of order with status indicator number 8

It recovered on its own five minutes later.

  1747   Wed Jul 15 11:38:31 2009 robUpdateLockingMC_F channel dead

It's railed.  This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.

 

Attached is a 5 day trend, which shows that the channel went dead a few days ago.  All the channels shown are being collected from the same ICS110B (I think), but only some are dead.  It looks like they went dead around the time of the "All computers down" from Sunday.

  1748   Wed Jul 15 12:11:17 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

This week I've been working on testing the first version of the prototype circuit. Initially, I tested the circuit that I built last week, which had resistors in the place of the transformer. The magnitude and phase of the transfer function, as measured by the Agilent 4395A, are shown in the attached plot (first plot, MeasuredTransferFunction_R.jpg). The transfer function doesn't look like the simulated transfer function (second plot, BuiltCkt_ExpectedResponse.png), but I think I see the three peaks at least (although they're at the wrong frequencies). I spent some time trying to recreate the actual transfer function using LTSpice, and I think it's reasonable that the unexpected response could be created by extra inductance, resistance, capacitance and interaction between components.

When the transformer arrived  yesterday, I replaced the resistors in the circuit with the transformer, and I have measured the following response (last plot, MeasuredTransferFunction.jpg). The gain is much lower than for the circuit with the resistors; however, I am still trying to track down loose connections, since the measured transfer function seems very sensitive to jiggled wires and connections.

Meanwhile, the parts for a flying-component prototype circuit have been ordered, and when they arrive, I'll build that to see if it works a little better.

  1749   Wed Jul 15 12:14:08 2009 AlbertoUpdateLockingphotodiode alignment check

Quote:

Since lately the alignment of the input beam to the interferometer has changed, I went checking the alignment of the beam on the photodiodea. They were all fine except for pd9, that is AS DD 199. Here the DC is totally null. The beam seems to go right on the diode but the scope on the PD's DC output shows no power. This is really strange and bad.

After inspecting PD9 with the viewer and the cards, the beam looks like it is aligned to the photodiode althought there is no signal at the DC output of the photodetector. So I checked the spectrum for PD9_i and Q (see attachments) and it seems that those channels are actually seeing the beam. I'm going to check the alignemtn again and see the efefct on the spectra to make sure that the beam is really hitting the PD.

 

  1750   Wed Jul 15 12:44:28 2009 Chris ZimmermanUpdateGeneralWeek 4/5 Update

I've spent most of the last week working on finishing up the UCSD calculations, comparing it to the EUCLID design, and thinking about getting started with a prototype and modelling in MATLAB.  Attached is something on EUCLID/UCSD sensors.

  1751   Wed Jul 15 14:42:31 2009 ZachUpdateCamerasGigE Phase Camera

Lately, I have been able to externally trigger the camera using a signal generator passing through the op-amp circuit that I built.  The op-amp circuit stabilizes the jitter in the sine wave from the signal generator and rectifies the wave.  I wrote the calculations into the code allowing me to find the phase and amplitude from the images I take.  I still need to develop code that will plot these arrays of phase and amplitude.

The mysterious dark band at the top of the ccd images continues to defy explanation.  However, I have found that it only appears for short exposure times even when the lens is completly covered.  During the next couple of days, I will try to write a routine to correct for this structure in the dark field.

Koji recommended that we use the optical setup pictured below.  This configuration would require fewer optics and we would have to rely on slight misalignments between the carrier and reference beams to test the effectiveness of the phase camera instead of a wavefront-deforming lens.

  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.

  1753   Wed Jul 15 18:22:15 2009 KojiUpdateCamerasRe: GigE Phase Camera

Quote:

Koji recommended that we use the optical setup pictured below.  Although it uses fewer optics, I can't think of a way to test the phase camera using this configuration because any modulation of the wavefront with a lens or whatever would be automatically corrected for in the PLL so I think I'll have to stick with the old configuration.

I talked with Zach. So this is just a note for the others.

The setup I suggested was totally equivalent with the setup proposed in the entry http://131.215.115.52:8080/40m/1721, except that the PLL PD sees not only 29.501MHz, but also 1kHz and 59.001MHz. These additional beating are excluded by the PD and the PLL servo. In any case the beating at 1kHz is present at the camera. So if you play with the beamsplitter alignment you will see not only the perfect Gaussian picture, but also distorted picture which is resulted by mismatching of the two wave fronts. That's the fun part!

The point is that you can get an equivalent type of the test with fewer optics and fewer efforts. Particularly, I guess the setup would not be the final goal. So, these features would be nice for you.

  1754   Wed Jul 15 18:35:11 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

Using FET probes, I was able to measure a transfer function that looks a little more like what I expected. There are only two peaks, but I think this can be explained by a short between the two capacitors (and two tunable capacitors) in the LC pairs, as shown (in red) in the circuit diagram attached. The measured transfer function (black), along with the simulated transfer functions with (red) and without (blue) the short are shown in the attached plot. The measured transfer function doesn't look exactly like the simulated transfer function with the short, but I think the difference can be explained by stray impedances.

  1755   Thu Jul 16 01:00:56 2009 AlbertoUpdateLockingPD9 aligned

Quote:

Quote:

Since lately the alignment of the input beam to the interferometer has changed, I went checking the alignment of the beam on the photodiodea. They were all fine except for pd9, that is AS DD 199. Here the DC is totally null. The beam seems to go right on the diode but the scope on the PD's DC output shows no power. This is really strange and bad.

After inspecting PD9 with the viewer and the cards, the beam looks like it is aligned to the photodiode althought there is no signal at the DC output of the photodetector. So I checked the spectrum for PD9_i and Q (see attachments) and it seems that those channels are actually seeing the beam. I'm going to check the alignemtn again and see the efefct on the spectra to make sure that the beam is really hitting the PD.

 

 I aligned PD9. Here are the spectra confirming that.

p.s.
Ants, theyre everywhere, even inside the AS table. They're taking over the lab, save yourself!
  1756   Thu Jul 16 09:49:52 2009 AlanUpdateComputersfb40m

Quote:

The fb40m just went out of order with status indicator number 8

It recovered on its own five minutes later.

 Backup script restarted, backup of trend frames and /cvs/cds is up-to-date.

 

  1757   Thu Jul 16 10:52:58 2009 ClaraUpdatePEMSingle Channel TRS-RNC Cable

I made and tested a female-to-female TRS(audio)-RNC cable. It only has a single channel, so it won't work for stereo speakers or anything, but I should only need one speaker for testing the microphones. The tip of the plug is the signal, the sleeve is ground, and the ring is null.

  1758   Thu Jul 16 14:41:38 2009 robUpdateLockingMC_F channel dead

Quote:

It's railed.  This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.

 

Attached is a 5 day trend, which shows that the channel went dead a few days ago.  All the channels shown are being collected from the same ICS110B (I think), but only some are dead.  It looks like they went dead around the time of the "All computers down" from Sunday.

 Attached are the channels being recorded from the ICS110B in 1Y2 (the IOO rack).  Channels 12, 13, 16, 17, 22, 24, 25 appear to have gone dead after the computer problems on Sunday.

  1759   Thu Jul 16 14:54:05 2009 robUpdateLockingMC_F channel dead

Quote:

Quote:

It's railed.  This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.

 

Attached is a 5 day trend, which shows that the channel went dead a few days ago.  All the channels shown are being collected from the same ICS110B (I think), but only some are dead.  It looks like they went dead around the time of the "All computers down" from Sunday.

 Attached are the channels being recorded from the ICS110B in 1Y2 (the IOO rack).  Channels 12, 13, 16, 17, 22, 24, 25 appear to have gone dead after the computer problems on Sunday.

 This has been fixed by one of the two most powerful & useful IFO debugging techniques: rebooting.  I keyed the crate in 1Y2.

  1760   Fri Jul 17 18:04:54 2009 ClaraUpdatePEMGuralp Box Fail

I've been trying for most of the week to get noise measurements on the output of the Guralp box as well as scross the AD640 chip. The measurements haven't really been making sense, and, being at a loss as to what else I should try, I decided to redo the resistors on the N/S 2 and E/W 2 channels. (I had been comparing the VERT1 and VERT2 channels, as VERT1 has been restuffed and VERT2 has not.) I don't need all three of the second set of channels to do more measurements, so it seemed like a good use of time.

The first thing I noticed was that the VERT2 channel was missing two resistors (R24 and R25). I probably should have noticed this sooner, as they are right by the output points I had been measuring across, but it didn't occur to me that anyone did anything to the VERT2 channel at all. So, probably the measurements on VERT2 are no good.

VERT2_missing_resistors.png

Note the existence of 100 kOhm resistors on the top channel, and none on the bottom channel (VERT2).

 

Then, while I was soldering in some 100 Ohm resistors, I happened to notice that the resistors I was using had a different number (1001) on them than the corresponding ones on the already redone channels (1003). I checked the resistance, and the ones on the already redone channels turned out to be 100 kOhm resistors, rather than 100 Ohms. So, I double checked the circuit diagram to make sure that I had read it correctly, and there were a number of resistors that had been relabeled as 100 Ohms and several relabeled as 100 kOhms. On the board, however, they were ALL 100 kOhms. Clearly, one of them is wrong, and I suspect that it is the circuitboard, but I don't know for sure.

resistors_diagram.png

resistors_board.png

The diagram clearly shows that R6 should be a 100k resistor, while R5 and R8 should be 100 Ohm resistors, but they are all the same (100k) on the board. I suspect this may have something to do with larger-than-expected noise measurements. But, it's possible the diagram is wrong, not the board. In any case, I didn't really know what to do, since I wasn't sure which was right, so I just replaced all the resistors I was sure about and removed the 100k and 100 Ohm resistors without replacing them with anything. Incidentally, the box of 100kOhm resistors seems to be missing, so I wouldn't have been able to finish those anyway.

  1761   Sat Jul 18 19:49:48 2009 ranaUpdatePEMGuralp Box Fail
That's terrible: R5 & R8 should definitely be 100 Ohm and not 100kOhm. 100k would make it a noise disaster. They should also be metal film (from the expensive box, not from the standard box). This is the same for all channels so might as well stuff them.

The circuit diagram between TP3 and TP4 appears to be designed to make the whitening not work. That's why R6 & R7 should be 100k. And R2 should be metal film too.

Basically, every time we want good low frequency performance we have to use the metal film or metal foil or wirewound resistors. Everything else produces a lot of crackling noise under the influence of DC current.

I'm also attaching the voltage and current noise spectra for the AD620 from the datasheet. These should allow us to compare our measurements to a reasonable baseline.
  1762   Sun Jul 19 22:38:24 2009 robOmnistructureGeneralWeb screenshots aren't being updated

Quote:

Before heading back to the 40m to check on the computer situation, I thought I'd check the web screenshots page that Kakeru worked on, and it looks like none of the screens have been updated since June 1st.  I don't know what the story is on that one, or how to fix it, but it'd be handy if it were fixed.

 Apparently I broke this when I added op540m to the webstatus page.  It's fixed now.

  1763   Mon Jul 20 10:35:06 2009 steveUpdateVACUPS batteries replaced

 APC Smart-UPS (uninterruptible power supply) batteries RBC12 replaced at 1Y8 vacuum rack.

Their life span were 22 months.

  1764   Mon Jul 20 12:35:21 2009 robConfigurationLockingalignment biases funny

I found the alignment biases for the PRM and the SRM in a funny state.  It seemed like they had been "saved" in badly misaligned position, so the restore scripts on the IFO configure screen were not working.  I've manually put them into a better alignment.

ELOG V3.1.3-