I've been trying to lock the PLL for the AbsL Experiment but I can't see the beat (between the auxiliary NPRO and the PSL).

I believe the alignment of the PLL is not good. The Farady Isolator is definitely not perfectly aligned (you can see it from the beam spot after it) but still it should be enough to see something at the PLL PD.

it's probably just that the two beams don't overlap well enough on the photodiode. I'll work on that later on.

I'm leaving the lab now. I left the auxiliary NPRO on but I closed its shutter.

All the flipping mirrors are down.

This morning, after Steve pointed out that the readout RFAMPD_DC was zero, I thought of realigning the beam on the photodiode. Maybe I touched the lens or the beam splitter that send the beam on the diode when I installed an other beam splitter to make the measurement of the calibration between two ThorLabs PDA255 photodiodes.

After aligning the beam on the RFAMPD, the voltage of the DC readout was lower than it used to be (C1:IOO-RFAMPD_DC ~ 0.4 now vs. 4 as it was on November 4th).

I maximized the DC readout but the problem seems to be that the beam spot is not a round TEM00. In particular the spot looks like that of a TEM10 mode.

Since we're looking at the MC transmitted beam, is it possible that the MC is locked on the wrong mode?

Check out the attached picture.

I've opened the AP table and I'm working on it.

I re-aligned the Faraday on the AP table. I also aligned the beam to the periscope on the PSL and all the other optics along the beam path.  Now I have a nice NPRO beam at the PLL which overlaps with the PSL beam. The alignment has to be further improved because I see no beat yet.

I wonder if the all the tinkering on the PSL laser done recently to revive the power has 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. So maybe the misalignment is the casue.

Not feeling very well right now. I need to go home for a while.

AP table closed at the moment.

NPRO shutter closed

This morning I found a frequency generator connected to something on the PSL table sitting on the blue step next to the sliding doors.

Is anyone using it? Has it been forgotten there? If that's the case, can the interested person please take care of removing it?

I've opened the AP table and I'm working on it.

Also auxiliary NPRO turned on and mechanical shutter opened.

 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.

I added the StochMon calibrated channels to the data trend by including the following channel names in the C0EDCU.ini file:

[C1:IOO-RFAMPD_33MHZ_CAL]
[C1:IOO-RFAMPD_133MHZ_CAL]
[C1:IOO-RFAMPD_166MHZ_CAL]
[C1:IOO-RFAMPD_199MHZ_CAL]

Before saving the changes I committed C0EDCU.ini to the svn.

Then I restarted the frame builder so now the new channels can be monitored and trended.

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.

 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.

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.

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.

Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS 

 I found the red sea when I came in this morning.

I tried several things.

1. ssh into fb40m: connection refused
2. telnet fb40m 8087: didn't respond
3. shutdown fb40m by physically pushing the power button: it worked and the FB came back to life but still with a red light on the MEDM DAQ_DETAIL screen;
4. powercycled fb40m AND C0DAQCTRL: no improvement
5. shutdown fb40m, C0DAQCTRL, C1DCUEPICS and pushed the reset button on the RF network crate; then I restarted the computers in this order: fb40m, C1DCUEPICS, C0DAQCTRL: it worked: they came back to life and the lights eventually turned green on the MEDM montior screen

I'm now going to restart the single front -ends and burtgooey them if necessary.

Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS 

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:

@11MHz Loss=0.22dBm/meter

@55MHz Loss=0.41dBm/meter

(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:

 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.

I did the measurement on a 4.33 meter long cable with SMA connectors at the ends.

 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.