40m SURFs Razib Obaid, Nancy Aggarwal, Unknown Bearded SMURF, Megan Daily, Gopal Nataraj, Katharine Larson and Sharmila Dhevi received 40m specific safety training on June 23, 2010.
Now that the MC is back up and running, I put the Guralp seismometers at the ends of the mode cleaner. Gur1 is near MC2, and Gur2 is near MC1 (yes, it seems backwards....that's how the cable lengths work). Also, the set of 3 MC2 accelerometers are in place under MC2. I can't find the black cube for the other set of accelerometers, so there aren't any around MC1/3.
The pumpdown started at 4 PM (2300 UTC). At 10 PM, we (Jenne, Jan, and I) opened up the RV1 valve to full open. That's the second inflection point in the plot.
Atm 2 is showing the butterfly valve that closes down down the orifice at higher pressure to slow down the pumping speed.
See elog entry #2573
I moved the Guralp box's input terminator from Gur1 to Gur2 a minute or so ago to check the other channels.
This week I have completed following tasks:
1. Worked out the analytical expressions for the amount of power of the DC and oscillatory part going into the camera.
2. Realigned the He-Ne PhaseCam setup as we had to replace the first steering mirror after the laser with a silvered mirror ( one without a dielectric coating for 1064 nm).
3. Gone through the code written by a previous surfer (Zach Cummings).
4. Read the paper 'Real-time phase-front detector for heterodyne interferometers'- F. Cervantes et. el. where they talk about constructing a phase detector for LISA pathfinder mission. One interesting fact I found was that, they used InGaAs chip for their CCD Cam which has a amazing QE of 80% @ 1064 nm. Unfortunately, the one we are using (Micro MT9V022 CMOS) has only ~5% QE for 1064 nm and 50% for 633 nm. One top of it MT9V022 has a built-in infra-red filter infront of it to make it more insenstive to 1064. In such limitations, we may have to find a work-around for this issue. Any idea?
5. Read about the EOM and AOM and their vibrating (!) way to add on and alter the incident light on them. (Source: Intro to Optical Electronics-Yariv)
One task that we couldn't accomplish even though I planned on doing is:
1. Move,if possible, to the Nd:YAG setup.
Task for this week:
1. Produce breathtaking calibration of the camera at He-Ne setup.
2. Read 'Fringe Analysis'-Y.Surrel and 'Phase Lock Technique'-Gardner.
3. Modify the phasecam code.
4. Produce an alternate triggerbox using diodes instead of Op-Amp as op-amp is suspected to fail at some point driving the camera due to impedance mismatch.
5. Answer Koji's question at Aidan's ELOG .
Weekly Project Update:
We are studying Haixing's circuit diagram for the quadrant maglev control circuit. We have analyzed several of the sub-circuits and plotted transfer functions for these in MatLab. To check the circuit, we will compare the calculated transfer functions with those obtained from the HP control systems analyzer.
To learn how to use the control systems analyzer, we are reading App Note 243 as well as an online manual (477 pages in the first volume). We are beginning with a simple test circuit, and are comparing its measured frequencyresponse with calculated transfer functions. We currently have obtained a response graph beginning at 100 Hz (which we have not yet figured out how to print), and we are planning to investigate behavior at lower frequencies.
We also have been continuing our reading on control systems after a failed attempt at magnetic levitation.
I spent this morning populating the SUS IO Chassis and getting it ready for installation into the 1Y4 rack. I discovered I'm lacking the internal cables to connect the ADC/DAC boards to the AdL adapter boards that also go in the chassis (D0902006 and D0902496). I'm not sure where Alex got the cables he used for the end IO chassis he had put in. I'll be going to Downs after the meeting today either to get cables or parts for cables, and get the SUS chassis wired up fully.
I'd also like to confirm with Alex that the OSS-MAX-EXP-ELB-C board that goes in the IO chassis matches the host interface board that goes in the computer (OSS-HIB2-PE1x4-1x4 Re-driver HIB, since we spent half a day the last time we installed an IO chassis determining that one of the pair was bad or didn't match.
The SUS chassis has been populated in the following way:
Slot 1 ADC PMC66-16AI6455A-64-50M
Slot 2 DAC PMC66-16AO16-16-F0-OF
Slot 3-6 BO Contec DIO-1616L-PE Isolated Digital IO board
Slot 7 ADC PMC66-16AI6455A-64-50M
Slot 8-9 DAC PMC66-16AO16-16-F0-OF
Slot 1 ADC adapter D0902006
Slot 2 DAC adapter D0902496-v1
Slot 7 ADC adapter D0902006
Slot 8-9 DAC adapter D0902496-v1
Wednesday Morning E-log :
Most of the time through this week, i was working towards making the simulink model work.
It involved learning simulink functions better, and also improving on the knowledge of control theory in general, and control theory of our system.
1. Thusrday : found tfs for the feedback loop. and tried many different filters and gains to stabilize the system (using the transient response of the system). - not through
2. Friday : decided to use error response and nullify the steady state error instead of looking at convergence of output. tried many other filter functions for that.
Rana then showed me his files for WFS.
3. Sunday - played with rana's files, learnt how to club simluink with matlab, and also about how to plot tfs using bode plots in matlab.
4. Monday : Read about state-space models, and also how to linearize in matlab. done with the latter, but the former still needs deeper understanding.
read ray-optics theory to calculate the geometric sensing matrix.
It first requires to calculate the eigen mode of the cavity with tilted mirrors. this eigen mode is needed to be found out using ray-optics transfer matrices for the optics involved . figured out matrices for the tilted plane mirrors, and am working on computing the same for MC2.
5. Tuesday : went to Universal Studios , Hollywood :P
6. Wednesday (today) : Writing the report to be submitted to SFP.
Summary of this Week's Activities:
6/23: LIGO Safety Tour; Simulink Controls Tutorial
6/24: Simulink Diagram for Feedback Loop; Constructed Pendulum Transfer Function; Discussion with Dr. Weinstein
6/25: Prepare for pump-down of vacuum chamber; crane broken due to locking failure; worked through COMSOL tutorials
6/28: Ran through Python Tutorials; Began learning about Terminal
6/29: Wrote Progress Report 1 First Draft
6/30: Began editing Progress Report 1
As per Steve's instructions, at 12:43 AM, I used the following steps to stop the pumpdown until the morning:
A little D-sub terminator was put on the Gur1 input to the Guralp box, to check again the noise level of the box.
The folding crane was fixed and tested this morning by the NNN rigging company. Pictures will be posted by Steve in the morning.
Afterwards, the ITM-east door was installed, jam-nuts checked. No high voltage was on for the in-vac PZTs.
The annulus spaces were roughed down to 350mTorr by Roughing Pump RP1. For this operation, we removed the low flow valve from the RP1 line.
After the spaces came down to ~400 mTorr, we closed their individual valves.
Warning: The VABSSC1 and VABSSC0 valves are incorrect and misleadingly drawn on the Vacuum overview screen.
Our idea is to have a much slower pumpdown this time than the last time when we had a hurricane kick up the dust. Looks like it worked, but next time we should do only 1/2 turn.
Not dead. It just had a HT fault. You can tell by reading the front panel. Cycling the power usually fixes this.
MOPA is back onliine. Rana found that the fuse in the AC power connector's fuse had blown. This was evident by smelling all of the inputs and outputs of the MOPA controller. The power cord we were using for this was only rated for 10A and therefore was a safety hazard. The fuse should be rated to blow before the power cord catches on fire. The power cord end was slightly melted. I don't know why it hadn't failed in the last 12 years, but I guess the MOPA was drawing a lot of extra current for the DTEC or something due to the high temperature of the head.
We got some new fuses from Todd @ Downs.
The ones we got however were fast-blow, and that's what we want The fuses are 10A, 250V. The fuses are ~.08 inches long, 0.2 inches in diameter.
I picked up the ribbon cable connectors from Jay. It looks like we'll have to make the new cables for connecting the ADCs/DACs myself (or maybe with some help). We should be able to make enough ribbon cables for use now. However, I'm adding "Make nice shielded cables" to my long term to do list.
I pointed out the 2 missing adapter boxes we need to Jay. He has the parts (I saw them) and will try to get someone to put it together in the next day or so. I also picked up 2 more D080281 (DB44 to SCSI), giving us enough of those.
I once again asked Jay for an update on IO chassis, and expressed concern that without them the CDS effort can't really go forward, and that we really need this to come together ASAP. He said they still need to make 3 new ones for us.
So we're still waiting on a computer, 3 IO chassis, router + ethernet.
The insects and the laser trouble... Strange coincidences with LHO surprised me, but now I have been relieved.
[Steve, Kiwamu, Jenne]
The 40m is now back in Laser Hazard mode. Safety glasses are required for entry into the LVEA / IFO room.
I talked with Rolf, and asked if we were using Megatron for IO. The gist boiled down to we (the 40m) needed to use it for something, so yes, use it for the IO computer. In regards to the other end station computer, he said he just needed a couple of days to make sure it doesn't have anything on it they need and to free it up.
I had a chat with Jay where he explained exactly what boards and cables we need. Adapter boards are 95% of the way there. I'll be stopping by this afternoon to collect the last few I need (my error this morning, not Jays). However it looks like we're woefully short on cables and we'll have to make them. I also acquired 2 D080281 (Dsub 44 x2 to SCSI).
For each 2 Pentek DACs plus a 110B, you need 1 DAC adapter board (D080303 with 2 connectors for IDC40 and a SCSI). You also need a D080281 to plug onto the back of the Sander box (going to the 110Bs) to convert the D-sub 44 pins to SCSI.
LSC will need none, SUS will need 3, IO will need 1, and the ends will need 1 each. We have a total of 6, we're set on D080303s. We have 3 110Bs, so we need one more D080281 (Dsub44 to SCSI). I'll get that this afternoon.
For each XVME220, we'll need one D080478 binary adapter. We have 8 XVME220s, and we have 8 boards, so we're set on D08478s.
For the ends, there's a special ADC to DB44/37 adapter, which we only have 1 one of. I need to get them to make 1 more of these boxes.
We have 1 ADC to DB37 adapter, of which we'll need 1 more of as well, one for IO and one for SUS.
However, for each Pentek ADC, we need a IDC40 to DB37 cable. For each Pentek DAC we need an IDC40 to IDC40 cable. We need a SCSI cable for each 110B. I believe the current XVME220 cables plug directly in the BIO adapter boxes, so those are set.
So we need to make or acquire 11 IDC40 to DB37 cables, 7 IDC40 to IDC40 cables, and 3 SCSI cables.
We're going to have to reinstate the policy of No food / organic trash *anywhere* in the 40m. Everyone has been pretty good, keeping the food trash to the one can right next to the sink, but that is no longer sufficient, since we've been invaded by an army of ants:
We are going back to the old policy of Take your trash out to the dumpsters outside. I'm sure there are some old wives tales about how exercise after eating helps your digestion, or something like that, so no more laziness allowed!
I found the laser dead this morning.
The crane people are here to unjam it.
Laser hazard mode is lifted and LASER SAFE MODE is in place. No safety glasses but CRANE HAZARD is still active.
Stay out of the 40m lab !
Those drawings are an OK start, but its obvious that things have changed at the 40m since 2002. We cannot rely on these drawings to determine all of the channel counts, etc.
I thought we had already been through all this...If not, we'll have to spend one afternoon going around and marking it all up.
Last week Alex merged in the changes I had made to the local 40m copy of the Real Time Code Generator. These were to add a new part, called FiltMuxMatrix, which is a matrix of filter banks, as well as fixing the filter medm generation code so the filter banks actually have working time stamps.
I checked out a new version of the CDS SVN with these changes merged in. Changes that will be added in the near future by Rolf and Alex include the addition of "tags". These are pieces in simulink which act as a bridge between two points, so you can reduce the amount of wire clutter on diagrams. Otherwise they have no real affect on the generated C code. Also the ADC/DAC channel selector and in fact the ADC/DAC parts will be changing. The MIT group has requested the channel selector be freed up for its original purpose in matlab, so Rolf is working on that.
For the time being, Alex has created a directory /rtcds on Linux1 under /home/cds. He then created softlinks to that directory on megatron, c1iscex, and allegra in the /opt directory. This was an easy way to have a shared path.
After checking out the CDS SVN, we discovered there some files missing that Alex had added to his version, but not the main branch. Alex came over to the 40m and proceeded to get all those files checked in. We then checked it out again. Changes were made to the awg, framebuilder, and nds codes and needed to be rebuilt.
Certain other file name conventions were also changed. Instead of tpchn_c1.par, tpchn_c2.par, etc, its now tpchn_c1lsc.par, tpchn_c2lsp.par, etc. The system name is included at the end of the filename, to help make it clearer what file goes with what.
This required an edit of the chnconf file, which has explicit calls to those file names. Once we edited that file, we had to reload the xinetd service which its apparently a subpart of (this can be accomplished by /etc/init.d/xinetd stop, then /etc/init.d/xinetd start).
/etc/rc.d/rc.local also had to be edited for the new model names (c1lsc, c1lsp, etc).
The daqdrc file (for the framebuilder) now parses which dcu_rate to use from the tpchn_c1lsc.par type files, so the dcu_rate 20 = 16384 lines have been removed. set gds_server has also been removed, and replaced with tpconfig "/opt/rtcds/caltech/c1/target/gds/param/testpoint.par"; from which it can get the hostname. This information is now derived from the c1SYS.mdl file.
After that Alex informed me the IOP processor needs to be running for the other models to work properly, as well as for the Framebuilder to work.
Initially there was a problem running on Megatron, because the IOP gets its timing signal from the IO chassis, and there was none connected to megatron. However, he has since modified the code so that if there's no IO chassis, the IOP processor just uses the system clock. It has been tested and runs on megatron now.
This applies to SUS:
Two ICS 110Bs. Each has 2 (4 total) 44 shielded conductors going to DAQ Interface Chassis (D990147-A). See pages 2 and 4.
Three Pentek 6102 Analog Outputs to LSC Anti-Image Board (D000186 Rev A). Each connected via 40 conductor ribbon cable (so 3 total). See page 5.
Eight XY220 to various whitening and dewhitening filters. 50 conductor ribbon cable for each (8 total). See page 10.
Three Pentek 6102 Analog Input to Op Lev interface board. 40 conductor ribbon cable for each (3 total). See page 13.
The following look to be part of the AUX crate, and thus don't need replacement:
Five VMIC113A to various Coil Drives, Optical Levers, and Whitening boards. 64 conductor ribbon cable for each (5 total). See page 11.
Three XY220 to various Coil boards. 50 conductor ribbon for each (3 total). See page 11.
This applies to WFS and LSC:
Two XY220 to whitening 1 and 2 boards. 50 conductor ribbon for each (2 total). See page 3.
Pentek 6102 to LSC Anti-image. 50 conductor ribbon. (1 total). See page 5.
The following are unclear if they belong to the FE or the Aux crate. Unable to check the physical setup at the moment.
One VMIC3113A to LSC I & Q, RFAM, QPD INT. 64 conductor ribbon cable. (Total 1). See page 4.
One XY220 to QPD Int. 50 conductor ribbon cable. (Total 1). See page 4.
The following look to be part of WFS, and aren't needed:
Two Pentek 6102 Analog Input to WFS boards. 40 conductor ribbon cables (2 Total). See page 1.
The following are part of the Aux crate, and don't need to be replaced:
Two VMIC3113A to Demods, PD, MC servo amp, PZT driver, Anti-imaging board. 64 conductor ribbon cable (2 Total). See page 3.
Two XY220 to Demods, MC Servo Amp, QPD Int boards. 50 conductor ribbon cable (2 Total). See page 3.
Three VMIC4116 to Demod and whitening boards. 50 conductor ribbon cable (3 Total). See page 3.
Using the three Marconis in 40m at 11.1 MHz, the Three Cornered Hat technique was used to find the individual noise of each Marconi with different offset ranges and the direct/indirect frequency source of the rubidium clock.
Rana explained the TCH technique earlier - by measuring the phase noise of each pair of Marconis, the individual phase noise can be calculated by:
S1 = sqrt( (S12^2 + S13^2 - S23^2) / 2)
S2 = sqrt( (S12^2 + S23^2 - S13^2) / 2)
S3 = sqrt( (S13^2 + S23^2 - S12^2) / 2)
I measured the phase noise for offset ranges of 1Hz, 10Hz, 1kHz, and 100kHz (the maximum allowed for a frequency of 11.1Mhz) and calculated the individual phase noise for each source (using 7 averages, which gives all the spikes in the individual noise curves). The noise from each source is very similar, although not quite identical, while the noise is greater at higher frequencies for higher offset ranges, so the lowest possible offset range should be used. It appears the noise below a range of 10Hz is fairly constant, with a smoother curve at 10Hz.
The phase noise for direct vs indirect frequency source was measured with an offset range of 10Hz. While very similar at high and low frequencies for all 3 Marconis, the indirect source was consistently noisier in the middle frequencies, indicating that any Marconis connected to the rubidium clock should use the rubidium clock as a direct frequency reference.
Since I can't adjust settings of the Marconis at the moment, I have yet to finish measurements of the phase noise at 160 MHz and 80 MHz (those used in the PSL lab), but using the data I have for only the first 2 Marconis (so I can't finish the TCH technique), the phase noise appears to be lowest using the 100kHz offset except at the higher frequencies. The 160 MHz signal so far is noisier than the 11.1 MHz signal with offset ranges of 1 kHz and 10 Hz, but less noisy with a 100 kHz offset.
I still haven't measured anything at 80 MHz and have to finish taking more data to be able to use the TCH technique at 160 MHz, then the individual phase noise data will be used to measure the noise of the function generators used in the PSL lab.
It seems to work, sort of.
ORPHAN ENTRY FOUND ON ROSALBA:::::::::::::::::::::::::::::::::::::::::::::::::::>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
We did svn update. Then Alex realized he missed adding some files, so added them to the svn, and then we checked out again.
We rebuilt awg, fb, nds.
We reloaded service xinet.d, after editing /etc/xinetd.d/chnconf. We changes all the tpchn_c1 to tpchn_c1SYS
There's a new naming scheme for the model files. They start with the site name. So, lsc becomes c1lsc.
On any machine you want code running, make a symbolic link to /cvs/cds/rtcds/ in /opt/
I am trying to get an actual complete install of the 40m svn on my machine. It keeps stopping at the same point:
I have always seen this when checking out the 40m medm SVN on a non-Linux box. I don't know what it is, but Yoichi and I investigated it at some point and couldn't reproduce it on CentOS. I think its some weirdness in the permissions of tmp files. It can probably be fixed by doing some clever checkin from the control room.
Even worse is that it looks like the whole 'SVN' mantra has been violated in the medm directory by the 'newCDS' team. It could be that Joe has decided to make the 40m a part of the official CDS SVN, which is OK, but will take some retraining on our part.
The power of the green beam generated on the PSL table should be about 650uW in terms of the shot noise.
One of the important parameters we should know is the power of the green beam on the PSL table because it determines the SNR.
The green beam finally goes to a photo detector together with another green beam coming from the arm cavity, and they make a beat signal and also shot noise.
So in order to obtain a good SNR toward the shot noise at the photo detector, we have to optimize the powers.
If we assume the green power from the arm is about 650uW, a reasonable SNR can be achieved when these powers are at the same level.
To get such power on the PSL table, a 90% partial reflector is needed for picking it off from the PSL as we expected.
power dependency of SNR
Suppose two lasers are going to a photo detector while they are beating (interfering).
The beat signal is roughly expressed by
[signal] ~ E1* E2 + E1 E2*,
~ 2 ( P1 P2)½ cos (phi),
where E1 and E2 represent the complex fileds, P1 and P2 represent their powers and phi is a phase difference.
This equation tells us that the strength of the signal is proportional to ( P1 P2)½ .
At the same time we will also have the shot noise whose noise level depends on the inverse square route of the total power;
[noise] ~ ( P1 + P2)½.
According to the equations above, SNR is expressed by
SNR = [signal] / [noise] ~ ( P1 P2)½ / ( P1 + P2)½.
If we assume P1 is fixed, the maximum SNR can be achieved when
P2 goes to the infinity. But this is practically impossible.
Now let's see how the SNR grows up as the power P2 increases. There are two kinds of the growing phase.
(1) When P2 <
P1 , SNR is efficiently improved with the speed of P2½.
(2) But when P2 >
P1 , the speed of growing up becomes very slow. In this regime increasing of P2 is highly inefficient for improvement of the SNR.
Thus practically P1 ~ P2 is a good condition for the SNR.
At this point the SNR already reaches about 0.7 times of the maximum, it's reasonably good.
According to the fact above, we just adjust the green powers to have the same power levels on the PSL table.
The table below shows some parameters I assume when calculating the powers.
Attached figure shows a simplified schematic of the optical layout with some numbers.
By using those parameters we can find that the green beam from the arm cavity is reduced to 650uW when it reaches the PSL table.
To create the green beam with the same power level on the table, the power of 1064 nm going to the doubling crystal should be about 150mW.
This amount of the power will be provided by putting a 90% partial reflector after the PMC.
The 40m corner station crane is out of order, and it's stuck in a way that prohibits entry to the 40m LVEA / IFO room for safety. The crane has been locked out / tagged out.
Until further notice, absolutely no one may enter the 40m LVEA. Work is permitted in the desk / control room areas.
Signs have been posted on all doors into the LVEA. Please consider those doors locked out / tagged out.
I've just stolen a GPIB controller, an yellow small box, from the spectrum analyzer HP8591E.
The controller is going to be used for driving the old spectrum analyzer HP3563A for a while.
Gopal and I will be developing and testing a GPIB program code for HP3563A via the controller.
Once after we get a new GPIB controller, it will be back to the original place, i.e. HP8591E.
--- GPIB controller ----
Yesterday afternoon I went to downs and acquired the following materials:
2 100 ft long blue fibers, for use with the timing system. These need to be run from the timing switch in 1Y5/1Y6 area to the ends.
3 ADCs (PMC66-16AI6455A-64-50M) and 2 DACs (PMC66-16AO16-16-F0-OF), bringing our total of each to 8.
7 ADC adapter boards which go in the backs of the IO chassis, bringing our total for those (1 for each ADC) to 8.
There were no DAC adapter boards of the new style available. Jay asked Todd to build those in the next day or two (this was on Thursday), so hopefully by Monday we will have those.
Jay pointed out there are different styles of the Blue and Gold adapter boxes (for ADCs to DB44/37) for example. I'm re-examining the drawings of the system (although some drawings were never revised to the new system, so I'm trying to interpolate from the current system in some cases), to determine what adapter style and numbers we need. In any case, those do not appear to have been finished yet (there basically stuffed boards in a bag in Jay's office which need to be put into the actual boxes with face plates).
When I asked Rolf if I could take my remaining IO chassis, there was some back and forth between him and Jay about numbers they have and need for their test stands, and having some more built. He needs some, Jay needs some, and the 40m still needs 3. Some more are being built. Apparently when those are finished, I'll either get those, or the ones that were built for the 40m and are currently in test stands.
Aparently Friday afternoon (when we were all at Journal Club), Todd dropped off the 7 DAC adapter boards, so we have a full set of those.
Things still needed:
1) 3 IO chassis (2 Dolphin style for the LSC and IO, and 1 more small style for the South end station (new X)). We already have the East end station (new Y) and SUS chassis.
2) 2 50+ meter Ethernet cables and a router for the DAQ system. The Ethernet cables are to go from the end stations to 1Y5-ish, where the DAQ router will be located.
3) I still need to finish understanding the old drawings drawings to figure out what blue and gold adapter boxes are needed. At most 6 ADC, 3 DAC are necessary but it may be less, and the styles need to be determined.
4) 1 more computer for the South end station. If we're using Megatron as the new IO chassis, then we're set on computers. If we're not using Megatron in the new CDS system, then we'll need a IO computer as well. The answer to this tends to depend on if you ask Jay or Rolf.
I do a
svn checkout --username svn40m https://nodus.ligo.caltech.edu:30889/svn /Users/dmass/svn
A blah blah blah many files
svn: In directory '/Users/dmass/svn/trunk/medm/c1/lsc'
svn: Can't copy '/Users/dmass/svn/trunk/medm/c1/lsc/.svn/tmp/text-base/C1LSC_MENU.adl.svn-base' to '/Users/dmass/svn/trunk/medm/c1/lsc/.svn/tmp/C1LSC_MENU.adl.tmp.tmp': No such file or directory
I believe I have always had this error come up when trying to do a full svn install. Any illumination is welcome.
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.
As the other channels showed the same effect we decided to reboot the crate and everything was fine afterwards.
[Jenne, Kiwamu, Steve, Sharmila, Katherine, Joe]
We finished bolting the door on the new ITMX (old ITMY) and putting the access connector section back into place. We finished with torquing all the bolts to 40 foot-pounds.
[Jenne, Megan, Frank]
We rebooted c1iovme, c1susvme1, and c1susvme2 during lunch. Frank is going to write a thrilling elog about why c1iovme needed some attention.
C1susvme 1&2 have had their overflow numbers on the DAQ_RFMnetwork screen red at 16384 for the past few days. While we were booting computers anyway, we booted the suses. Unfortunately, they're still red. I'm too hungry right now to deal with it....more to follow.
Is this a setpoint temperature that we can change by writing to the channel or is it a readout of the actual temperature of the oven?
This is a readout channel just to monitor the actual temperature.
We added a channel on c1psl in order to monitor the temperature of the PPKTP sitting on the PSL table.
To take continuous data of the temperature we added the channel by editing the file: target/c1psl/c1psl.db
We named the channel "C1:PSL-PPKTP_TEMP".
To reflect this change we physically rebooted c1psl by keying the crate.
Some unused optics in the BS chamber were removed.
After that the beam splitter has been drag wiped.
So now the BS chamber is waiting for the installation of the other core optics i.e. PRM, SRM and Tip-Tilts.
-- removing of unused optics
There were some unused optics, mainly 1.5 inch optics which had been used for the oplevs in the chamber.
Kathaine, Shamila (Team Magnet) and Kiwamu took those optics out from the chamber.
And then we carefully wrapped each of them by aluminum foils and put them in some clear boxes.
In fact, before wrapping them, we gently attached lens papers on their HR surfaces such that aluminum foils can not damage it.
Now there are only three 1.5 inch optics in the chamber, and they are supposed to be used for the oplevs.
We didn't remove any of the 2 inch optics and the PZT mirrors because they are still going to be used.
These are the pictures of the BS chamber after we cleaned up them.
-- wiping of the BS
Rana and Kiwamu drag wiped the HR surface of the BS by using lens paper with the solvents.
The below is the procedure we did. You can find some details about the wiping technique for suspended optics in this entry.
In this time we could wipe the beam splitter without removing the front earthquake stops because the beam splitter was brought close enough to us.
(1). put some blocks attaching the edge of the bottom plate of the tower in order to record the original position.
(2). locked the beam splitter to the frame by screwing the earthquake stops.
(3). made sure if it is really locked by seeing the output signal of the OSEMs in dataviewer. If it's locked successfully, the resonant frequency gets higher and the Q-value gets lower.
(3). moved the BS tower close to the door in order to reach the beam splitter easily.
(4). inspected the surface by using a fiber light. There were about 10 bright spots on the HR surface.
(5). wiped the surface three times by using the lens paper with Aceton.
(6). wiped it several times with Isopropyl.
(7). inspected the surface again, found there were no big bright spots near the center. Thumbed up
(8). put the tower back to the original place and released the beam splitter from the earthquake stops.
FSS SLOWDC slider is at around 0.
Please someone relock this at ~-4.0 to exploit some last juice of the fruit.
See this entry for the details of the operating point.
The laser chiller temp is fluctuating and the power output is decreasing. See 120 days plot.
Yesterday I removed ~300cc water from the overflowing chiller tank.
I visited downs and announced that I would be showing up again until all the 40m hardware is delivered.
I brought over 4 ADC boards and 5 DAC boards which slot into the IO chassis.
The DACs are General Standards Corporation, PMC66-16AO16-16-F0-OF, PCIe4-PMC-0 adapters.
The ADCs are General Standards Corporation, PMC66-16AI6455A-64-50M, PCIe4-PMC-0 adapters.
These new ones have been placed with the blue and gold adapter boards, under the table behind the 1Y4-1Y5 racks.
With the 1 ADC and 1 DAC we already have, we now have enough to populated the two ends and the SUS IO chassis. We have sufficient Binary Output boards for the entire 40m setup. I'm going back with a full itemized list of our current equipment, and bring back the remainder of the ADC/DAC boards we're due. Apparently the ones which were bought for us are currently sitting in a test stand, so the ones I took today were from a different project, but they'll move the test stand ones to that project eventually.
I'm attempting to push them to finish testing the IO chassis and the remainder of those delivered as well.
I'd like to try setting up the SUS IO chassis and the related computer this week since we now have sufficient parts for it. I'd also like to move megatron to 1Y3, to free up space to place the correct computer and IO chassis where its currently residing.
The following is not 100% accurate, but represents my understanding of the events currently. I'm trying to get a full description from Christian and will hopefully be able to update this information later today.
Last night around 7:30 pm, Caltech detected evidence of computer virus located behind a linksys router with mac address matching our NAT router, and at the IP 18.104.22.168. We did not initially recognize the mac address as the routers because the labeled mac address was off by a digit, so we were looking for another old router for awhile. In addition, pings to 22.214.171.124 were not working from inside or outside of the martian network, but the router was clearly working.
However, about 5 minutes after Christian and Mike left, I found I could ping the address. When I placed the address into a web browser, the address brought us to the control interface for our NAT router (but only from the martian side, from the outside world it wasn't possible to reach it).
They turned logging on the router (which had been off by default) and started monitoring the traffic for a short time. Some unusual IP addresses showed up, and Mike said something about someone trying to IP spoof warning coming up. Something about a file sharing port showing up was briefly mentioned as well.
The outside IP address was changed to 126.96.36.199 and dhcp which apparently was on, was turned off. The password was changed and is in the usual place we keep router passwords.
Update: Christian said Mike has written up a security report and that he'll talk to him tomorrow and forward the relevant information to me. He notes there is possibly an infected laptop/workstation still at large. This could also be a personal laptop that was accidently connected to the martian network. Since it was found to be set to dhcp, its possible a laptop was connected to the wrong side and the user might not have realized this.
I fitzed with the PRM and SRM briefly, and I now believe that they're both ready to go into the chambers.
For each optic, I used the microscope on a micrometer to check that the scribe lines on each side of the optic were at the same height. Basic procedure was to center the microscope on one scribe line, move the microscope to the other side, to see how far the line was from center, and try to (very gently!!) rotate the optic in the wire about the z-axis about half the distance that the one scribe line needed to be. Rinse and repeat several times until satisfied.
I then checked that our HeNe oplev was still at 5.5" beam height, and that the beam traveled straight across the table. I put the SRM in the oplev, unclamped the EQ stops, and waited for it to settle. The HEPA filters were turned off, to minimize the breeze. While the SRM settled, I worked on the height/rotation for the PRM on the other table.
After checking the SRM balance, I clamped it and moved it, and checked the PRM balance, then turned off the HeNe and rewrapped everything in foil, and turned on the HEPAs.
Both the SRM and the PRM seem a little off in Pitch. The beam returning to the QPD (placed just next to the laser) was always ~1cm above the center of the QPD. The beam travel distance was ~3m (vaguely) from laser to optic to QPD. This effect may be because the optics were originally balanced with OSEMs in place, and I didn't have any OSEMs today. Koji and I found several months ago that the OSEMs have some DC affect on the optics.
Anyhow, since our optics are so small, I think the OSEMs and coils can handle this small DC offset in pitch, so I think we're ready to rock-n-roll with putting them in the chambers.
Still on the to-do list......Tip Tilts!
The photo shows the oplev beam position on (kind of) the QPD, for the SRM. The PRM was basically the same.
Summary of This Week's Activities:
6/16: LIGO Orientation; First Weekly Meeting; 40m tour with Jenne; Removed WFS Box Upper Panel, Inserted Cable, Reinstalled panel
6/17: Read Chapter 1 of Control Systems Book; LIGO Safety Meeting; Koji's Talk about PDH Techniques, Fabry-Perot Cavities, and Sensing/Control; Meeting w/ Nancy and Koji
6/18: LIGO Talk Part II; Glossed over "LASERS" book; Read Control Systems Book Chapter 2; Literary Discussion Circle
6/21: Modecleaner Matrix Discussion with Nancy; Suggested Strategy: construct row-by-row with perturbations to each d.f. --> Leads to some questions on how to experimentally do this.
6/22: Learned Simulink; Learned some Terminal from Joe and Jenne; LIGO Meeting; Rana's Talk; Christian's Talk; Simulink Intro Tutorial
6/23 (morning): Simulink Controls Tutorial; Successfully got a preliminary feedback loop working (hooray for small accomplishments!)
Outlook for the Upcoming Week:
Tutorials (in order of priority): Finish Simulink Tutorials, Work through COMSOL Tutorials
Reading (in order of priority): Jenne's SURF Paper, Controls Book, COMSOL documentation, Lasers by Siegman.
Work: Primarily COMSOL-related and pre-discussed with Rana
This past week I have completed the following tasks:
1. Built a trigger and power box for the camera GC 750M (06058) and took some test images to see whether the trigger box really works. Result: It is doing fine!
2. Went over the setup that is already sitting on the table. Ref: Aidan's elog entry
3. Attended seminars and talks given by Alan, Jahms, Koji and Rana.
4. Attended the mandatory laser safety training by Peter.
Expected task for this week (could be more):
1. Work out analytical expressions of the power of the carrier and sidebands going to the camera in the setup. (As suggested by Rana and Joe)
2. Work on producing beat signal to the camera using the He-Ne laser setup.
3. Move,if possible, to the Nd:YAG setup.
4. Go over the codes and paper by the past SURFers on the phase camera experiment.
This week I attended a whole lot of orientations, lectures, and meetings related to SURF. Done with general and laser safety training.
read Nergis' thesis for, and other material on WFS.
got confused with how the sidebands and shifted carrier frequencies are chosen for the Interferometer, read initial chapters of Regehr's thesis for teh same.
Made a plan for proceeding with the WFS work through discussions with Koji.
Understood the MC cavity and drew a diagram for it and the sensors.
Did Calculations for Electric field amplitudes inside and outside the MC cavity.
Saw the hardware of the WFS and QPD inside, and their routes to computers. Figured out which computer shows up the conditioned data from teh sensors.
Tried calculating the cavity axis for MC using geometry and ray tracing. Too complicated to be done manually.
Read some material (mainly Seigman) for physics of calculating the eigen-axis of the MC cavity with mirrors mis-aligned. Will calculate that using simulations, using the ABCD matrices approach.
Made a simple feedback simulink model yesterday to learn simulink. Made it run/compile. Saw the behaviour thru time signals at different points.
in the night, Made a simulink model of the sensor-mirror thing, with transfer functions for everything as dummy TFs. Compiles, shows signals in time. Remaining part is to put in real/near-real TFs in the model.