On Rana's suggestion I checked the MC transmission QPD (C1:IOO-MC_TRANS_SUM). I found that the readout is almost zero when the MC is unlocked.
I unlocked the Mode Cleaner turning off the LSC control and disabling the autolocker. The QPD reads 0.014. It seems that there is no offset.
I also checked with the IR card around the photodetector and I didn't see any stray beam.
Yes it did.
For long time, the crystal temperature C1:PSL-126MOPA_LTMP was 43~46deg. Now it is 34deg. Try ~10deg lower temperature.
I wonder if the all the tinkering on the PSL laser done recently to revive the power have changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat.
Beat found at 30MHz with auxiliary NPRO temperature of 37.19 degrees, vs. ~48 deg as it used to be.
The beat is small (-70dBm). PLL alignment has to be improved.
PLL alignment improved. Beat amplitude = -10dBm. Good enough.
DC readouts at the PLL photodiode:
V_NPRO = -4.44V
V_PSL = -3.76V
The NPRO beam is attenuated by a N.D.=1 attenuator just before going to the photodiode.
Something strange happened at the last. Right before -10dBm, the amplitude of the beat was about -33dBm. Then I was checking the two interfering beams with the IR card and saw that they overlapped quite well. I then turned my head back to the spectrum analyzer and suddenly the beat was at -10dBm. Not only, but a bunch of new peaks had appeared on the spectrum. Either I inadvertently hit the PD moving it to a better position or something else happened.
Like if someone was making some other modulation on the beam or the modulation depth of the PSL's sidebands had gone up.
I locked the PLL and made some first measuremtns of the spectrum of the error signal. I'll post them later.
I closed the shutter of the NPRO.
This afternoon, I tried to lock the interferometer again after a few days.
After a couple of failed attempts, and relocks of the MZ, the interferometer stayed locked continuously for about 50 minutes, with arm power of about 92.
I just wanted to check the status of the interferometer so I didn't do any particular measurement in the meantime.
We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.
Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:
./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1
which replaces the old one without the part with the -v argument.
The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.
I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.
So be aware that:
We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.
I tried applying the changes but they didn't work. It seems that nodus doesn't like the command syntax.
I have to go through the problem...
The elog is up again.
The 40m produces a large amount of paper and cardboard waste. It would be worth it if we disposed those kind of garbages for recycling.
I set up two new garbage bins in the lab: one in the control rooms that adds up to the can/bottle recycling bin, and one other one in the office area, next to the printer for general paper disposal.
People in the lab are strongly invited to make use of the two new garbage bins and recycle their paper and cardboard waste.
Boxes can be larger than the garbage bin, so I'd recommend people to crash them before throwing them into the bin.
I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table.
Closing the AP table and the NPRO shutter now.
Last night something happened on the beat between the PSL beam and the auxiliary NPRO beam, that spoiled the quality of the beating I had before. As a result the PLL has become unable to lock the two lasers.
The amplitude of the beat at the spectrum analyzer has gone down to -40 dBm from -10 that it was earlier. The frequency has also become more unstable so that now it can be seen writhing within tens of KHz.
Meanwhile the power of the single beams at the PLL photodiode hasn't changed, suggesting that the alignment of the two beam didn't change much.
Changes in the efficiency of the beating between the two beams are not unusual. Although that typically affects only the amplitude of the beat and wouldn't explain why also its frequency has become unstable. Tuning the alignment of the PLL optics usually brings the amplitude back, but it was uneffective today.
It looks like something changed in either one of the two beams. In particular the frequency of one of the two lasers has become less stable.
Another strange thing that I've been observing is that the amplitude of the beat goes down (several dBm) as the beat frequency is pushed below 50 MHz. Under 10 MHz it even gets to about -60 dBm.
I noticed the change yesterday evening at about 6pm, while I was taking measurements of the PLL open loop tranfer function and everything was fine. I don't know whether it is just a coincidence or it is somehow related to this, but Jenne and Sanjit had then just rebooted the frame builder.
I confirm what I said earlier. The amplitude of the beat is -10 dBm at 300MHz. It goes down at lower frequencies. In particular it gets to-60 dBm below 20 MHz. For some strange reason that I couldn't explain the beating efficiency has become poorer at low frequencies.
NPRO shutter closed
Problem found. Inspecting with Koji we found that there was a broken SMA-to-BNC connector in the BNC cable from the photodiode.
I measured the open loop gain of the PLL in the AbsL experiment.
I repeated the measurement twice: one with gain knob on the universal PDH box g=3.0; the second measurement with g=6.0
The UGF were 60 KHz and 100 KHz, respectively.
That means that one turn of the knob equals to about +10 dB.
I closed the shutter of the NPRO for the night.
Came in, found all front-ends down.
Keyed a bunch of crates, no luck:
Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS
Powered off/restarted c1dcuepics. Still no luck.
Powered off megatron. Success! Ok, maybe it wasn't megatron. I also did c1susvme1 and c1susvme2 at this time.
BURT restored to Nov 26, 8:00am
But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC. I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m. I'm leaving it this way--we can deal with it tomorrow.
I found the red sea when I came in this morning.
I tried several things.
I'm now going to restart the single front -ends and burtgooey them if necessary.
Everything is back on.
Restarted all the front ends. As usual c1susvme2 was stubborn but eventually it came up.
I burt-restored all the front-ends to Nov 26 at 8am.
The mode cleaner is locked.
Today I measured the max output power at the EOM output of one of the RF AM Stabilizers that we use to control the modulation depth. I needed to know that number for the designing of the new RF system.
When the EPICS slider of the 166 MHz modulation depth is at 0 the modulation depth is max (the slider's values are reversed : 0 is max, 5 is min; it is also 0 for any value above 5, sepite it range from 0 to 10).
I measured 9.5V from the EOM output, that is 32 dBm on a 50 Ohm impedance.
Alberto, Kiwamu, Koji,
this morning we found the RFM network and all the front-ends down.
To fix the problem, we first tried a soft strategy, that is, we tried to restart CODAQCTRL and C1DCUEPICS alone, but it didn't work.
We then went for a big bootfest. We first powered off fb40m, C1DCUEPICS, CODAQCTRL, reset the RFM Network switch. Then we rebooted them in the same order in which we turned them off.
Then we power cycled and restarted all the front-ends.
Finally we restored all the burt snapshots to Monday Dec 7th at 20:00.
I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.
I'll go for a big boot fest.
I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.
I'm doing a couple of measurement and I'll put it back in as soon as I'm done.
I replaced the SMA end connector for the 166 MHZ Local Oscillator signal that goes to the back of the flange in the 1Y2 rack. The connector had got damaged after it twisted when I was tigheting the N connector of the Heliax cable on the front panel.
These are the losses I measured on a RG-174 cable for the two frequencies that we're planning to use in the Upgrade:
(The cable was 2.07m long. The input signal was +10dBm and the output voltages at the oscilloscope where: Vpk-pk(11MHz)=1.90V, Vpk-pk(11MHz)=1.82V )
I apologize for the lack of correctness on the units in yesterday's elog entry, but I wasn't very sharp last night.
I repeated the measurement today, this time also making sure that I had a 50ohm input impedance set in the scope. These the results for the losses.
I also measured the losses in the Heliax cable going from the 166 MHz LO to the LSC rack:
Oplev positions before and after drag wiped arm TMs as of yesterday. Slow-mode pumpdown has started with 3/4 turn opened RV1 valve at 8am today.
I'm leaving the lab now for less than 2 hours. I should be back in time for when the pumping is finished so that I can measure the finesse again.
Seems like very strange cable loss numbers. The Heliax is lossier than the RG-174? I wonder how these compare with the specs in the cable catalog?
I did the measurement on a 4.33 meter long cable with SMA connectors at the ends.
[Jenne, Kiwamu, Koji]
We got the IFO back up and running! After all of our aligning, we even managed to get both arms locked simultaneously.
I'm going to do it right now.
Last week we vented and we cleaned the main optics of the arm cavities.
I measured the frequency of the cavity poles for both the arm cavities to see how they changed (see previous elog entry 2226). These the results:
fp_X = 1616 +/- 14 Hz
fp_Y = 1590 +/- 4 Hz
The Y arm cavity pole moved down by 130 Hz, whereas the X arm moved by only 34 Hz. I wonder if that is because Kiwamu spent much more time on cleaning ITMY than on any other optic.
The way the filter's transfer function has been measured is by a swept sine between the "SERVO INPUT" and the "PIEZO DRIVE OUTPUT" connection on the box front panel. The spectrum analyzer used for the measurement is the SR785 and the source amplitude is set at 0.1V.
The two transfer functions are clearly different. In particular the old one looks like a simple integrator, whereas the new one already includes some sort of boost.
That probably explains why the new one is unable to lock the PLL. Indeed what the PLL needs, at least to acquire lock, is an 1/f filter.
I thought the two boxes were almost identical, at least in the filter shapes. Also the two schematics available in the DCC coincide.
Yesterday I measured the Open Loop Gain of the PLL in the absolute length experiment. The servo I used was that of the old Universal PDH box.
The OLG looks like this:
The UGF is at 10 KHz.
The elog has been quite slow for the last two days. The cause is nodus, that has been slowing down the access to it.
I looked at the list of the running processes on nodus by typing the command prstat, which is the equivalent for Solaris of the Linux "top". I didn't see any particular process that might be absorbing too many resources.
I remember Rana fixing the same problem in the past but couldn't find his elog entry about that. Maybe we should just restart nodus, unless someone has some other suggestion.
Problem solved. Nodus and the elog are running fine. It's just that the elog takes some time to make a preview of complex pdf attachments, like those in Kiwamu's entry 2405.
Since it wasn't sure whether all the front-ends had been restored after the bootfest, I burtrestored everything to Dec 26 at 20:00.
Always keep in mind that to burtrestore c1dcuepics, the snapshot file has to be modified by hand by moving the last quote up to the line before the last.
I opened the auxiliary laser's shutter.
I'm currently working on the AP table.
I finished working on the table.
I closed the AUX NPRO's shutter.
This morning I found all the watchdogs had tripped during the night.
I restored them all.
I can't damp ITMX. I noticed that its driving matrix is all 1s and -1s as the the right values had been lost in some previous burtrestoring.
FYI: I stored the Universal PDH boxes in the RF cabiner in the Y arm.
In the lab there are lots of old posters with outdated autocad drawings, or printouts with schematics of old electronics hanging on the walls.
Can we get rid of those and start giving the lab a fresh and modern look?
This morning I found that there was no light on the SPOB PD. I went looking at the photodetector and I found that the shutter in front of it was closed.
I switched the shutter driver from n.c. to n.o. which had the effect of opening it.
I guess we inadvertently closed the shutter with Rana when last week we were tinkering with the ITMY camera.
This morning I've been having problems in trying to lock the X arm.
That doesn't seem to have solved the problem. The X arm can get locked but TRX slowly moves between 0.2 and 1.
The X arm is now locked with TRX stable at ~1.
I think earlier on today I was having problems with running the alignment scripts from op540. Now I'm controlling the IFO from Rosalba and I can easily and stably lock all degrees of freedom.
I needed the X arm to be locked to align the auxiliary beam of the AbsL experiment to the IFO. To further stabilize TRX I increased the loop gain from 1 to 1.5.
Now the auxiliary beam is well aligned to the IFO and the beat is going through the PRC. I'm finally ready to scan the recycling cavity.
I also changed the gain of the PRC loop from -0.1 to -0.5.
Rana noticed that recently the temperature inside the lab has been a little bit too high. That might be causing some 'unease' to the computers with the result of making them crash more often.
For the next hours I'll be paying attention to the temperature inside the lab to make sure that it doesn't go out of control and that the environment gets too cold.
I'm working on the AbsL experiment. A measurement which involved the PRC locked is running at the moment.
Please make sure of not interfering with the interferometer until it is done. Thank you.
Today the lab is perceptibly cooler.
The temperature around the corner is 73 F.