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.
Not dead. It just had a HT fault. You can tell by reading the front panel. Cycling the power usually fixes this.
As per Steve's instructions, at 12:43 AM, I used the following steps to stop the pumpdown until the morning:
Kiwamu, Nancy, and I restored the power into the MC today:
We found many dis-assembled Allen Key sets. Do not do this! Return tools to their proper places or else you are just wasting everyone's time!
Just as I expected, since these hunuman didn't actually check MC_L after doing this stuff, MC_L was only recording ZERO. Joe and I reset and restarted c1susmve2 and then
verified (for real this time) that the channel was visible in both the Dataviewer real time display as well as in the trend.
The lesson here is that you NEVER trust that the problem has been fixed until you check for yourself. Also, we must always
specify a very precise test that must be used when we ask for help debugging some complicated software problem.
I re-aligned the beam into the PMC. I got basically no improvement. So I instead changed the .LOW setting so that PMCTRANS would no longer go yellow and make the donkey sound.
I did the same for the MOPA's AMPMON because its decayed state is now nominal.
Steve and I removed the thermal insulation from around the reference cavity vacuum chamber. It wasn't really any good anyways.
Here are the denuded photos:
Steve and I are now planning to replace the foam with some good foam, but before that we will wrap the RC chamber with copper sheets like you would wrap a filet mignon with applewood bacon.
This should reduce the thermal gradients across the can. We will then mount the sensors directly to the copper sheet using thermal epoxy. We will also use copper to cover most of this hugely
oversized window flange - we only need a ~1" hole to get the 0.3 mm beam out of there.
My hope is that all of this will improve the temperature stability of this cavity. Right now the daily frequency fluctuations of the NPRO (locked to the RC) are ~100 MHz. This implies
that the cavity dT = (100 MHz) / (299792458 / 1064e-9) / (5e-7) = 1 deg. That's sad....
I also changed the RC_REFL cam to manual gain from AGC. I cranked it to max gain so that we can see the REFL image better.
After whatever Joe/Alberto did this afternoon, the MC was not locking. Koji and I removed several of the cables in the side of the rack where they
were apparently working (I say apparently because there's no elog).
MC is now locking but the autolocker did not work at first - op340m was unable to access any channels from c1iool0. After several minutes, it mysteriously
started working - the startup.cmd yields errors seen on the terminal. I attach the screen dump/.
Sometimes I like to plot the spectrum of MC_F. Its a good diagnosis of whether something is wrong.
The red trace is noisier than the blue reference. What is the cause of this?
As you can see, there was not much (if any) worsening of the laser frequency fluctuation from removing the RefCav insulation. The plots below are zooomed in:
I have used the same peak-to-peak scale so that its easy to compare the fluctuations before (LEFT) and after (RIGHT).
As you can clearly see, the laser frequency moves just as much now (the SLOW_DC) as it did before when it had the insulation. Only now the apparent (i.e. fake) RC temperature fluctuations are much larger. So this sensor is fairly useless as configured.
To make the beam on the MC trans camera bigger, I removed the lens + ND filter that was in that path.
The camera was getting the transmission through a BS1-33 (33% reflector). The reflection went to the TRANS QPD. I changed
the R=33% into an HR mirror (Y1-45P) so now the camera has a nice beam. The QPD was now saturating so I put a ND06 into that path
so now the TRANS_SUM is ~4.5-5 V when the MC is aligned.
The MC was also misaligned and failing to lock all weekend (why??) so I aligned the MC mirrors to get it to acquire again. Since we want to
collect MC seismic data, please make sure the MC is locked and running after finishing with your various MC or PSL work (this means YOU).
Since we now have a good measurement of the phase noise of the Rb clock Marconi locked to the Rb clock, I wanted to use that to check out the old DAQ system:
I used Megan's phase noise setup - Marconi #2 is putting out 11000013 Hz at 13 dBm into the ZP-3MH mixer. Marconi #1 is putting out 3 dBm at 11000000 Hz into the RF input.
The output goes through a 50 Ohm load and then a Mini-Circuits BNC LP filter (either 2 or 5 MHz). Then an SR560 set for low noise, G = 5, AC coupling, 1-pole LP @ 1 kHz.
This SR560 output goes into the channel C1:IOO-MC_DRUM1 (which is sampled at 16384 Hz with ICS-110B after the usual Sander Liu AA chassis containing the INA134s).
So...who was working around the PSL rack this morning and afternoon? Looks like there was some VCO phase noise work at the bottom of
the rack as well as some disconnecting of the Guralp cables from that rack. Who did which when and who needs to be punished?
I just realized that an unfortunate casualty of this LSC work was the deletion of the slow controls for the LSC which we still use (some sort of AUX processor). For example, the modulation
depth slider for the MC is now in an unknown state.
I reconnected the RF signal to the FSS and to the FSS' EOM so that we could lock the refcav again.
I then started a 3 sec. period trianglewave on the AOM drive amplitude to see if there is a direct coupling from RIN to Frequency. Ideally we will be able to measure this by looking at the RCTRANS and the FSS-FAST.
This is the 0.3 mHz BW spectrum of this test - as you can see the apparent linewidth (assuming the width is all caused by the DAQ jitter) is comparable to the BW and therefore not resolved.
Basically, the Hanning window function is not sharp enough to do this test and so I will do it offline in Matlab.
1) Gravity has to be included because the inverted pendulum effect changes the resonant frequencies. The deflection from gravity is tiny but the change in the dynamics is not. The results are not accurate without it. The z-direction probably is unaffected by gravity, but the tilt modes really feel it.
2) You should try a better meshing. Right now COMSOL is calculating a lot of strain/stress in the steel plates. For our purposes, we can imagine that the steel is infinitely stiff. There are options in COMSOL to change the meshing density in the different materials - as we can see from your previous plots, all the action is in the rubber.
3) I don't think the mesh density directly limits the upper measurement frequency. When you redo the swept-sine using the matlab scripting, use a logarithmic frequency grid like we usually do for the Bode plots. The measurement axis should go from 0.1 - 30 Hz and have ~100 points.
In any case, the whole thing looks promising: we've got real solid models and we're on the merge of being able to duplicate numerically the Dugolini-Vass-Weinstein measurements.
Someone had left a typo in the MC autolocker script recently while trying to set the lock threshold to 0.09. As a result, the autlocker wouldn't run.
I repaired it, made a few readability improvements, and checked in the new version to the SVN. If you make script changes, check them in. If you think its too minor of a change for a SVN checkin, don't do it at all.
I bet you thought that the NPRO slow actuator response could be well represented by a pole at ~0.1 Hz? Well, that's just what they want you to believe.
I attach the response measured in FSS-FAST (with no feedback to the SLOW actuator) when the SLOW is given a step. As you may remember from
kindergarten, the response of a single pole low pass should just be an exponential. Clearly, there's more here than 1 pole.
I also inserted a factor of 0.01 in the FSSSlowServo code so I could make the gain sliders have reasonable values (they used to all be ~1e-3). The SVN and the MEDM snapshot are updated.
Alastair found that the foam hut that he and Jan put on top of the Rb clocks to temperature stabilize them was too good of an insulator. The Rb boxes had gotten very hot and became internally unlocked as seen on the front panel.
After we let them cool down with the box off, I turned them back on. After several minutes the 'Locked' light came back on. Some minutes after that the '1PPS Sync' light also came on, indicating that the two had become somewhat synchronized. It really means that the frequencies are kind of close: I think its roughly that f1-f2 < 2 mHz.
I put the yellow box back on and have left it with a small gap on the bottom so that the hot air can get out. Hopefully, this will protect the clocks from the wind, but not cause them to overheat.
The signal going to the DAQ right now is DC-coupled, with a gain of 1. The peak-peak beat signal in this situation is 6300 counts.
My guess is that the clocks will by synchronized by tomorrow afternoon so that we can get the measurement done. Please don't disturb the clocks or the yellow box around them. Try to minimize any activity around that area.
I tried to get the clocks to be closer to 90 deg for the relative phase by adding some cable length to one of the lines, but they are still wandering too much. We need to use the serial interface and up the gain in their 1PPS locking loops.
The green xterm on op540m which is running the seisBLRMS DMF got stuck somehow ~3 days ago and lost its NDS connection. I closed the matlab session and restarted it. Seismic trends are now back online.
P-pol = purple
S-pol = red
The .graffle file for this is in the 40m SVN's omnigraffle dir/
I used the free software called 'ABCD' for Mac to construct this mode matching solution for going from the PMC to the IMC.
After getting it close by eye, I plugged the initial guess into Matlab and let it optimize the distances. I then plugged this into 'ABCD'
to get the exact solution. ABCD doesn't actually optimize anything; it just makes a nice table and graphically plots the solution.
The part numbers for these lenses are:
In a manner similar to the now classic 'Mode Matching from PMC to IMC' entry, I have calculated the lenses and positions needed to match the 2W NPRO beam into the PMC.
The added complication is that we also want to have a reasonable beam size to get into the Faraday and the AOM. It seems that this should be possible using one lens.
After the beam comes out of the AOM, there's another lens to match to the PMC. Its possible to do this with more lenses, but this is just an effort to minimize the number
of surfaces in the beam.
For the future SLOW controls our current plan is to keep using the VME based stuff and associated processors (Baja, Motorola, etc.). This is not
a sustainable plan since these are obsolete and eventually will die. One option is to use these boxes from Diamond Systems:
In fact, many of the mounts need to be adapted to 4": the beefy steering mirrors going into the PMC, the PMC RFPD, the ISS AOM, the Faraday between the NPRO and the AOM, the NPRO itself, the ISS PDs.
Also for the FSS: the 21.5 MHz EOM, the PBS, the AOM, the refcav periscope, and the RFPD.
Its obvious, in retrospect, that we would have to do this, but it somehow didn't occur to me until actually trying to put things on the table...
The NPRO itself is already tapped with 3 (metric) M3 holes. It also has 4 (un-tapped) holes at its 4 corners which look like they are for feet. Anyone have a mount design for the Innolight NPRO already?
We also started labeling the table with the new coordinate system. In this system, the NE corner is the origin. The screw hole which is most NE is 1,1. The numbering increases in the south (+X) direction and goes negative in the west (-Y) direction.
We changed the name of the new control room computer from kallo to rossa (since its red).
I also tried to install the nVidia graphics driver, but failed. I downloaded the one for the GeForce 310
for x86_64 from the nVidia website, but it failed to work. I installed it, but then X windows wouldn't start.
I've left it running a basic VESA driver.
Kiwamu updated the host tables to reflect the name change. We found that both rossa and allegra were
set up to look at the old 131.* DNS computers and so they were not resolving correctly. We set them up for new way.
The lifting and resetting of the BLUE PSL enclosure has made it unstable somehow. When I push on it a little it rocks back and forth a lot.
Steve, please look into what's happening and stiffen it if you can. Its too unstable right now.
To test out this website - emachineshop.com, Jenne and I are designing some of the mounts for the new beam height.
It took me a few hours to figure out how to do it, but the software is easy enough for simple stuff. This is a brass mount with M4 clearance holes which are countersunk and a lip so that it can be dogged down to the table.
And I raised it back to 73F. The thermometers on the wall show 74-75F as the actual room temp. The dial on the temperature controller is not calibrated.
The differences between this setup and the one used previously is the lack of the 50 Ohm terminator in the mixer output and
that the SR560 readout with the G=100 should come before the first SR560 via T, so as not to be spoiled by the high noise of the G=1 SR560.
With the setup now working, we should now test the power filtering for the crystal and amplifier.
Why are we running CentOS 4.8 instead of 5.5 ? What runs at LLO? What runs in Downs?
Koji and I inspected and photographed the laser after opening up its case. I then drilled the clearance holes in the 4 corners and tapped holes for 1/4-20. I was careful to tap with the laser sideways, to avoid shavings getting into the laser and suctioned out as much of the pieces as I could. The laser is now mounted on some bad 1/4-20 based NewFocus style pedestals. The riser block can now be made with 1/4-20 through holes and the laser will sit on its for corner feet. We'll make the base aluminum to avoid differential CTE based stress in the laser base.
We checked the level of the laser. With the new mounting the beam is level to within ~1 mrad and has a 4" beam height.
I've mounted the Faraday Rotator from the old MOPA. It has 8-32 mounting holes (who's shafts are curiously not parallel). We need an aluminum block of the proper height (2 3/4" ??) to make a permanent solution.
I've also mounted the thin-film polarizer. This works well, but it also needs a block machined to get the mounting to be less Mickey Mouse.
Pockel Cell for phase correction and 35.5 MHz PMC modulation
The EOM is mounted as before on the angle bracket to align it for P-pol light. The beam now goes cleanly through there. No further mounting hardware required.
The 2 lenses in the 'mode matching telescope' between the laser and the PMC are in place, but not placed with any accuracy.
By sheer luck, I saw the PMC flashing in the TEM27 mode without any alignment from me. Next step is to get the lens positions tuned and then do the beam scan on the beam going towards the PMC to verify the approximate mode matching. This is all crude, but I just want to get the beam going into the vacuum as fast as possible.
apps/linux64/comsol (old v. 3.5)
* running up2date on rossa
* rossa needs to be able move windows between monitors: Xinerama?
* there are permissions problems: controls on rossa can't
make and delete directories made by 'controls' elsewhere.
Some sort of user# or group issue?
To bypass the polarizer issue, I just used cubes. One I took from the FSS-Refcav path and the other from the power control part of the old MOPA, just downstream of the MOPA's periscope.
We'll swab these out with the thin-film polarizers after we get the mounts made.
With the cubes in, I also installed the Faraday + its 1/2-wave plate. The transmission looks good and we're getting into the PMC and its flashing a TEM00 mode sometimes. I set up a signal generator to drive the SLOW actuator by 1 FSR at 0.1 Hz.
I have set up a PMC transmission camera and transPD so that its easy to align. The flashing mode already allows us to align most of the rest of the table (except FSS).
Our next step should be to run the cables for locking the PMC:
On Tuesday, we need to make sure that all of our mounts' drawings are in the cue for the shop. I'll put the list of mounts onto the PSL upgrade wiki page.
We also have to come up with a plan for wiring some of the 2W NPRO's channels into the cross-connect so that we can have some laser channels recorded by EPICS.
We must remember that we are using the Rev.B SOS Coil Drivers and not the Rev. A.
The main change from A->B was the addition of the extra path for the bias inputs. These inputs were previously handled by the slow EPICS system and not a part of the front end. So we used to have a separate bias screen for these than the bias which is in the front end. The slow bias is what was used for the alignment to avoid overloading the range of the main coil driver path.
Also, Kiwamu has modified the layout drawing to add the green PLL stuff. This has collapsed the reference cavity's wave function placing it close to its original position.
WE (maybe Valera and Steve) can now put the reference cavity back on the table.
I turned off the laser last night to protect against the electricians. but failed to elog it. I accept the burnt toast completely.
I wiped out the old CentOS install on rossa and installed CentOS 5.5 on there. The DVDs are on a spindle in the control room; there were 2 iso's, but I only needed the first to install most things.
It still needs to get all of the usual stuff (java, flash, nvidia) installed as well as setting up the .cshrc and the NFS mount of /cvs/cds. The userID and groupID are set to 1001 as before. Whoever
sees Sanjit first should steer him towards this elog entry.
I found Sanjit's instructions for doing the Nvidia settings too complicated and so I followed these instructions from Facebook:
After installations, the monitors were autodetected and the Xinerama effect is working.
I measured the RF power output of the VCO Driver box as a function of slider value. I measured using the Gigatronics Handheld power meter and connected to the AOM side of the cable after the white Pasternak DC block.
* at low power levels, I believe the waveform is too crappy to get an accurate reading - that's probably why it looks non-monotonic.
* the meter has a sticker label on it saying 'max +20 dBm'. I went above +20 dBm, but I wonder if maybe the thing isn't linear up there...
I restarted the seisBLRMS DMF monitor by ssh'ing into mafalda and starting up a matlab session. I also have started a StripTool session on rossa by forwarding the process from op440m.
We need to get the modern EPICS installation onto these linux machines by copying what K. Thorne has done at LLO.
The IR sensitive Olympus 570 camera gives us a really nice view of these IR beams. Its actually a lot better than what you can get with the analog IR viewers:
I changed the setpoint for the HVAC control (next to Steve) from 73F to 72F. This is to handle the temperature increase in the control room with the AC unit there turned off.
We know that the control setpoint is not linear, but I hope that it settles down after several hours. Lets wait until Tuesday evening before making another change.
I installed the blue IP camera from ZoneNet onto the PSL table. It gets its power from the overhead socket and connects via Cat5 to the Netgear switch in the PSL/IO rack.
You can connect to it on the Martian network by connecting to http://192.168.113.201:3037. Your computer must have Java working in the browser to make that work.
So far, this works on rossa, but not the other machines. It will take someone with Joe/Kiwamu level linux savvy to fix the java on there. I also don't know how to fix the host tables, so someone please add this camera to the list and give it a name.
As you can see from the image, it is illuminating the PSL with IR LEDs. I've sent an email to the tech support to find out if we can disable the LEDs.
Our new 2W Mephisto has a pretty zippy "SLOW" temperature input. Tuning the perl PID servo, I found that the best response came from setting
the "P" and "D" terms to zero. This is because the internal temperature stabilization servo has a fairly high UGF. In the attached
image you can see how the open loop step response looks (loop is open then the "KI" parameter is set to zero). The internal servo
really has too little damping. There is a 30% overshoot when it gets a temperature step. For this kind of servo Innolight would have done better
to back off on the gain until they got back some phase margin.
New SLOW parameters:
timestep = 1.9 s
KP = 0
KI = 0.035
KD = 0