ID |
Date |
Author |
Type |
Category |
Subject |
1755
|
Thu Jul 16 01:00:56 2009 |
Alberto | Update | Locking | PD9 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! |
Attachment 1: 2009-07-15_PD9spectrumPDF02.pdf
|
|
1754
|
Wed Jul 15 18:35:11 2009 |
Stephanie | Update | General | Multiply 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. |
Attachment 1: BuiltCkt1_Final.png
|
|
Attachment 2: BuiltCkt1_TransferFunctions.png
|
|
1753
|
Wed Jul 15 18:22:15 2009 |
Koji | Update | Cameras | Re: 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. |
1752
|
Wed Jul 15 17:18:24 2009 |
Jenne | DAQ | Computers | DAQAWG 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. |
1751
|
Wed Jul 15 14:42:31 2009 |
Zach | Update | Cameras | GigE 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. |
Attachment 1: fig1koji.pdf
|
|
1750
|
Wed Jul 15 12:44:28 2009 |
Chris Zimmerman | Update | General | Week 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. |
Attachment 1: Comparison.pdf
|
|
1749
|
Wed Jul 15 12:14:08 2009 |
Alberto | Update | Locking | photodiode 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.
|
Attachment 1: 2009-07-15_PD9spectrumPDF.pdf
|
|
1748
|
Wed Jul 15 12:11:17 2009 |
Stephanie | Update | General | Multiply 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. |
Attachment 1: MeasuredTransferFunction_R.jpg
|
|
Attachment 2: BuiltCkt_ExpectedResponse.png
|
|
Attachment 3: MeasuredTransferFunction.jpg
|
|
1747
|
Wed Jul 15 11:38:31 2009 |
rob | Update | Locking | MC_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. |
Attachment 1: mcfdead.png
|
|
1746
|
Wed Jul 15 08:59:30 2009 |
steve | Update | Computers | fb40m |
The fb40m just went out of order with status indicator number 8
It recovered on its own five minutes later. |
1745
|
Tue Jul 14 17:48:20 2009 |
Jenne | Omnistructure | Environment | Removal 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. |
Attachment 1: ACeffectonLASER2.png
|
|
1744
|
Tue Jul 14 16:31:46 2009 |
Clara | Update | PEM | Frequency 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. |
Attachment 1: Bonnie_fres_regplot.pdf
|
|
Attachment 2: Bonnie_fres_logplot.pdf
|
|
1743
|
Tue Jul 14 14:54:19 2009 |
steve | Configuration | Computers | fb40m2 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 |
1742
|
Tue Jul 14 00:57:11 2009 |
Alberto | Update | Locking | photodiode 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. |
1741
|
Tue Jul 14 00:32:46 2009 |
rob, alberto | Omnistructure | Environment | Removal 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. |
1740
|
Mon Jul 13 23:03:14 2009 |
rob, alberto | Omnistructure | Environment | Removal 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. |
1739
|
Mon Jul 13 16:59:10 2009 |
Zach | Update | | 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. |
1738
|
Mon Jul 13 15:48:05 2009 |
rana | Omnistructure | Environment | Removal 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. |
1737
|
Mon Jul 13 15:14:57 2009 |
Alberto | Update | Computers | DAQAWG |
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. |
1736
|
Mon Jul 13 00:53:50 2009 |
Alberto | DAQ | Computers | All 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. |
1735
|
Mon Jul 13 00:34:37 2009 |
Alberto | DAQ | Computers | All 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. |
1734
|
Sun Jul 12 23:14:56 2009 |
Jenne | Omnistructure | General | Web 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. |
1733
|
Sun Jul 12 20:06:44 2009 |
Jenne | DAQ | Computers | All 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. |
1732
|
Sun Jul 12 20:05:06 2009 |
rana | Omnistructure | Environment | Changed 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. |
Attachment 1: Picture_3.png
|
|
1731
|
Fri Jul 10 19:56:23 2009 |
rana, koji | Omnistructure | Environment | Changed 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. |
Attachment 1: therm.JPG
|
|
1730
|
Fri Jul 10 17:32:08 2009 |
rana | Update | Environment | seisBLRMS & 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. |
1729
|
Thu Jul 9 19:24:50 2009 |
rana | Update | PEM | more 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. |
1728
|
Thu Jul 9 19:05:32 2009 |
Clara | Update | PEM | more 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.
|
Attachment 1: DSC_0569.JPG
|
|
Attachment 2: DSC_0570.JPG
|
|
Attachment 3: bonnie_psl_hi_mcl12.pdf
|
|
Attachment 4: bonnie_psl_hi_errf12.pdf
|
|
Attachment 5: bc_as_table.pdf
|
|
Attachment 6: powerspec.pdf
|
|
1727
|
Thu Jul 9 02:18:09 2009 |
rana | Update | PEM | Bonnie 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. |
1726
|
Wed Jul 8 19:42:37 2009 |
Clara | Update | PEM | Bonnie 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.

Bonnie's new home in the PSL. |
Attachment 2: bonnie2_pmcerr.pdf
|
|
Attachment 3: bonnie_PSL.pdf
|
|
1725
|
Wed Jul 8 19:13:19 2009 |
Alberto | Update | PSL | PSL 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. |
1724
|
Wed Jul 8 18:46:56 2009 |
Dmass | AoG | Electronics | Beam 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: |
Attachment 1: beamscanhead3.png
|
|
Attachment 2: beamscanhead6.png
|
|
1723
|
Wed Jul 8 12:36:15 2009 |
Clara | Update | PEM | Coherences 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.

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

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. |
Attachment 2: bonnie_butch.pdf
|
|
Attachment 3: Gseis_100.pdf
|
|
Attachment 4: mc1_xyz.pdf
|
|
Attachment 5: mc2_xyz.pdf
|
|
Attachment 6: most_coherent.pdf
|
|
1722
|
Wed Jul 8 11:13:36 2009 |
Alberto | Omnistructure | Computers | wireless 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. |
1721
|
Wed Jul 8 11:08:43 2009 |
Zach | Update | Cameras | GigE 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). |
Attachment 1: fig1.pdf
|
|
Attachment 2: fig2.pdf
|
|
1720
|
Wed Jul 8 11:05:40 2009 |
Chris Zimmerman | Update | General | Week 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.  |
1719
|
Wed Jul 8 10:56:04 2009 |
Stephanie | Update | General | Multiply 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. |
Attachment 1: DSC_0566.JPG
|
|
Attachment 2: InitialBuiltCkt.pdf
|
|
Attachment 3: BuiltCkt_ExpectedResponse.png
|
|
1718
|
Tue Jul 7 16:06:59 2009 |
Clara | Update | Computer Scripts / Programs | DTT 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. |
1717
|
Tue Jul 7 15:08:49 2009 |
Koji | Summary | Photos | 40 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... |
Attachment 1: IMG_1848.jpg
|
|
1716
|
Thu Jul 2 17:37:36 2009 |
steve | Update | VAC | V1 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.
|
1715
|
Thu Jul 2 16:45:06 2009 |
Clara | Update | PEM | Bonnie 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!

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.

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.

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.
|
1714
|
Thu Jul 2 06:31:35 2009 |
Clara | Update | PEM | First mic in place and connected |
I clamped Bonnie (microphone) to the top of a chamber near the vertex of the arms and placed Clyde (pre-amp) on the table right below (see picture). The cable was laid and Bonnie and Clyde are plugged into port #13 on the ADC. The second cable was plugged into port #14, but it is not connected to anything. I placed the looped up cable on top of the cabinet holding the ADC.
Note: the angle in the photograph is such that we are looking along the y-arm.
|
Attachment 1: bonnieandclyde.JPG
|
|
1713
|
Thu Jul 2 05:27:12 2009 |
Clara | Update | PEM | Voltage Divider Oops |
I tested the voltage dividers and was getting up to about 3V. I retested the mic w/o the voltage divider in place, and, lo and behold, I was able to generate about 70-75V (previously, I maxed out at 45V). I'm not 100% sure why this was, but it occurs to me that, before, the sounds I was generating were short in duration (loud claps, short yelps). This time, I tried yelling continuously into the microphone. So, probably, I simply wasn't seeing the real peak before on the scope because it was too short to pick up. I have corrected the voltage dividers (by replacing the 25.5 kOhm resistors, which were in parallel with the ADC, with 10 kOhm resistors, taking the voltage ratio to ~60:1) and tested them. I haven't been able to generate more than 1500 mV, so I think they are safe. (It's possible we would have been fine with the old setup, since I think it would be hard to get any noises as loud as I was making, but better safe than sorry, right?)
I'm attaching a diagram of the new-and-improved voltage dividers.

|
1712
|
Wed Jul 1 11:04:27 2009 |
Zach | Update | Cameras | GigE Phase Camera |
This past week, I have building a sine wave rectifier and trying to write a simple program that displays a ccd image to familiarize myself with the code. I also wrote a progress report in which I included the following images of the sine wave rectifier circuit as well as the optical chain including the phase-locked loop. The hirose connector arrived so I can begin soldering the electronics together and testing the trigger box with the ccd. I am waiting on the universal PDH box as well as another fiber coupler to begin setting up the optics. In order to avoid the frustrations associated with sending a laser beam down a long pipe to an optical bench across the room, I will be transmitting laser 1 to the ccd by means of a fiber optic cable and dealing with the alternative new and exciting frustrations.
|
Attachment 1: trigger.jpg
|
|
Attachment 2: fig1b.pdf
|
|
1711
|
Wed Jul 1 11:00:52 2009 |
Stephanie | Update | General | Multiply Resonant EOM Update |
Since last week, I have come up with a new circuit, which is shown in the attached figure. The magnitude (solid) and phase (dashed) of the voltage across the EOM (red), the ratio between the voltage across the EOM and the voltage across the primary nodes of the transformer (blue), and the impedance through the primary port of the transformer (red) are also shown in an attached figure. As can be seen on the plot, resonance occurs at 11 MHz, 29.5 MHz, and 55 MHz, as specified. Also, at these resonant frequencies, the impedance is about 50 Ohms (34 dB). The gain between the voltage across the EOM and the voltage across the primary nodes of the transformer (or output of the crystal oscillator) is about 12 dB; we'd like a higher gain than this, but this gain is primarily governed by the ratio between the secondary and primary inductances in the transformer, and we are using the largest available ratio (on the Coilcraft website) that has the necessary bandwidth. Because of this, we will likely have to add another component between the crystal oscillator and the EOM circuit, to get the voltage to the desired 8.5 Vp across the EOM (for an optical modulation depth of 0.1 rad).
The current and power through the primary port of the tranformer are 43-85 mA and 25-92 mW, respectively. Since the transformer ratings are 250 mA and 1/4 W for current and power; these values should be safe to use with the intended transformer. Also, the highest power dissipated by a resistor in the circuit (not including the 50 Ohm resistor that is part of the crystal oscillator setup) is around 74 mW. |
Attachment 1: EOMCKT.png
|
|
Attachment 2: PR1_VoltagePlot.pdf
|
|
1710
|
Wed Jul 1 10:56:42 2009 |
Chris Zimmerman | Update | General | Week 2/3 Update |
I spent the last week working a lot with the differences between a basic Michelson readout and the new one as a displacement sensor. The new one (w/ wave plates) ends with two differently polarized beams and should have better sensitivity; I've also been going through noise/sensitivity calculations for each, although that hit a road block when I had to start the 1st SURF progress report, which has taken up most of my time since Saturday. |
1709
|
Tue Jun 30 23:09:40 2009 |
Alberto | Update | Locking | chronicles of some locking attempts |
Tonight I tried to lock the interferometer. At the first attempts the arm power didn't go above about 4. The mode cleaner seemed to be not well aligned and it lost lock or got stuck on a wrong mode. I had to run the MC_UP and MC_DOWN scripts to lock it again.
After that the locking proceed more smoothly; at least till a power level in the arms of about 60. Then again the mode cleaner lost lock and I had to run the scripts again. Without the MCWFS servo off the MC reflected power is still rather high (about 1.7); also even when the WFS servo is engaged the reflected power is about 0.5, versus 0.3 that it should be.
Those are both signs of a not very good alignment. Tomorrow I'll have to work on the injection periscope on the PSL table to try to fix that. |
1708
|
Sat Jun 27 03:16:16 2009 |
Clara | Update | PEM | Exciting microphone things! |
So, I'm double-posting, but I figured the last post was long enough as it was, and this is about something different. After double and triple checking the XLR cables, I hooked up the microphone setup (mic---preamp---output) to the oscilloscope to figure out what kind of voltage would register with loud noises. So, I clapped and shouted and forgot to warn the other people in the lab what I was doing (sorry guys) and discovered that, even on the lowest gain setting, my loud noises were generation 2-3 times as much voltage as the ADC can handle (2V). And, since our XLR cables are so freaking long, we probably want to go for a higher gain, which puts us at something like 20 times too much voltage. I doubt this is really necessary, but it's late (early) and I got camera-happy, so I'm going to share anyway:

So, to deal with this issue, I made some nifty voltage dividers. Hopefully they are small enough to fit side-by-side in the ports without needing extra cableage. Anyway, they should prevent the voltage from getting larger than 2V at the output even if the mic setup is producing 50V. Seeing as my screaming as loud as I could about 2mm away from the mic at full gain could only produce 45V, I think this should be pretty safe. I put the ADC in parallel with a 25.5 kOhm resistor, which should have a noise like 10^-8 V/rHz. This is a lot smaller than 1 uV/rHz (the noise in the ADC, if I understood Rana's explanation correctly), so the voltage dividers should pose a noise issue. Now for pictures.

I opened one so you can see its innards.

In case the diagram on the box was too small to decipher...
And finally, I came up with a name scheme for the mics and pre-amps. We now have two Bluebird (bacteriophage) mics named Bonnie and Butch Cassidy. Their preamps are, naturally, Clyde and The Sundance Kid. Sadly, no photos. I know it's disappointing. Also, before anyone gives me crap for putting the labels on the mics upside-down, they are meant to be hung or mounted from high things, and the location (and stiffness) of the cable prevents us from simply standing them up. So they will more than likely be in some kind of upsidedownish position. |
1707
|
Sat Jun 27 02:48:09 2009 |
Clara | Update | PEM | I moved accelerometers and made some pretty pictures |
I have been working on finding the best spots to put the accelerometer sets in order to best subtract out noise (seismometers next!). Here is a plot of what I've done so far:

All of these were 80-minute samples. The dashed line is unfiltered, solid line filtered. So, Setup #1 looks the best so far, but I didn't leave it there very long, so perhaps it was just a really awesome 80 minutes. I've put the accelerometers back in the Setup #1 position to make sure that it is really better.
And, in case you can't intuitively figure out what configuration the accelerometers are in by such descriptive names, here are some helpful pictures. I didn't know about the digital cameras at first, so these are actually sketches from my notebook, which I helpfully labeled with the setup numbers, color-coded to match the graph above! Also, there are some real-life photographs of the current arrangement (Setup #1' if you forgot).



Doesn't this one look kind of Quentin Blake-esque? (He illustrated for Roald Dahl.)

This is the MC1 set.

Guess which one this is! |
1706
|
Fri Jun 26 19:14:04 2009 |
rana | Update | Environment | seisBLRMS for the past 3 weeks |
Restarted the seisBLRMS.m on mafalda (running a term on op540m). Don't know why it stopped - the
terminal had a 'disabled by EPICS' message even though the EPICS enable button was enabled.
I also changed the delay from 4 to 2 minutes. So now it is calculating a 64 s PSD starting from 2 minutes ago. We had
put it back to 4 minutes long ago since the framebuilder was acting slow, but maybe it will work now since its using
the NDS1 protocol instead of direct frame reading. If it starts not finding data, please kill the seisBLRMS and restart
it with a 3 minute delay. |