Unfortunately, this has happened (and seems like it will happen) enough times that I set up a script for rebooting the machine in a controlled way, hopefully it will negate the need to repeatedly go into the VEA and hard-reboot the machines. Script lives at /opt/rtcds/caltech/c1/scripts/cds/rebootC1LSC.sh. SVN committed. It worked well for me today. All applicable CDS indicator lights are now green again. Be aware that c1oaf will probably need to be restarted manually in order to make the DC light green. Also, this script won't help you if you try to unload a model on c1lsc and the FE crashes. It relies on c1lsc being ssh-able. The basic logic is:

1. Ask for confirmation.
2. Shutdown all vertex optic watchdogs, PSL shutter.
3. ssh into c1sus and c1ioo, shutdown all models on these machines, soft reboot them.
4. ssh into c1lsc, soft reboot the machine. No attempt is made to unload the models.
5. Wait 2 minutes for all machines to come back online.
6. Restart models on all 3 vertex FEs (IOPs first, then rest).
7. Prompt user for confirmation to re-enable watchdog status and open PSL shutter.

After the CDSs crashed we run the rebootC1LSC.sh script.

The script is a bit annoying in that it requires entering the CDSs' passwords multiple times over the time it runs which is long.

The resulting CDS screen is a bit different than what was reported before (attached). Also, not all watchdogs were restored.

We restore the remaining watchdogs and do XARM locking. Everything seems to be fine.

It was way more annoying without a script and took longer than the 4 minutes it does now.

You can fix the requirement to enter password by changing the sshd settings on the FEs like I did for pianosa.

After running the script, you should verify that there are no red flags in the output to console. Yesterday, some of the settings the script was supposed to reset weren't correctly reset, possibly due to python/EPICS problems on donatella, and this cost me an hour of searching last night because the locking wasn't working. Anyway, best practise is to not crash the FEs.

Steve noticed the RGA was not working today.  It was powered on but no other lights were lit.

Turns out the c0rga machine had not been rebooted when the file system on linux1 was moved to the raid array, and thus no longer had a valid mount to /cvs/cds/.  Thus, the scripts that were run as a cron could not be called.

We rebooted c0rga, and then ran ./RGAset.py to reset all the RGA settings, which had been reset when the RGA had lost power (and thus was the reason for only the power light being lit).

Everything seems to be working now.  I'll be adding c0rga to the list of computers to reboot in the wiki.

[Jenne, Steve]

Steve noticed that the RGA was not logging data and that not all the correct connection lights were on, and he wasn't able to run the "RGAset.py" script (in ...../scripts/RGA/) that sets up the proper parameters. 

I looked, and the computer was not mounting the file system.  I did a remote shutdown, then Steve went in and pushed the power button to turn the machine back on.  After it booted up, it was able to talk to the file system, so I started ..../scripts/RGA/RGAset.py .  The first 2 times I ran the script, it reported errors, but the 3rd time, it reported no communication errors.  So, now that the computer can again talk to the file system, it should be able to run the cronjob, which is set to take data at 4am every day.  Steve will check in the morning to confirm that the data is there.  (The last data that's logged is 22Dec2013, 4am, which is right around when Koji reported and then fixed the file system).

When I came in this morning no light was reaching the MC. One fast machine was dead, c1lsc, and a number of the slow machines: c1susaux, c1iool0, c1auxex, c1auxey, c1iscaux. Gautam walked me through reseting the slow machines manually and the fast machines via the reboot script. The computers are all back online and the MC is again able to lock.

I restored C1:PSL-126MOPA_126MON to its original settings (EGUF = -410, EGUL = 410) and added a new calc channel called C1:LSC-EX_GRNBEAT_FREQ that is derived from C1:PSL-126MOPA_126MON. The calibration in the new channel converts the input to MHz.

grecord(calc, "C1:LSC-EX_GRNBEAT_FREQ")
{
        field(DESC,"EX-PSL Green Beat Note Frequency")
        field(SCAN, ".1 second")
        field(INPA,"C1:PSL-126MOPA_126MON")
        field(PREC,"4")
        field(CALC,"0.4878*A")
        }

I rebooted c1psl and burtrestored.

I rebooted cymac0 a couple of times. When I first got here it was just frozen. I rebooted it and then ran a model (x1ios). The machine froze the second time I ran ./killx1ios. I've rebooted it again.

For context, there's a is stand-alone cymac test system running at the 40m.  It's not hooked up to anything, except for just being on the martian network (it's not currently mounting any 40m CDS filesystems, for instance).  The machine is temporarily between the 1Y4 and 1Y5 racks.

I had to restart the elog again.

At this point, I'm going to try to get one of the GC guys to install gdb on nodus, and run the elog in the debugger, that way when it crashes the next time, I have some error output I can send back to the developer and ask why its crashing there.

Problem:

The front ends seem to have different gps timestamps on the data than the frame builder has when receiving them.

One theory is we have fairly been doing SVN checkouts of the code for the front ends once a week or every two weeks, but the frame builder has not been rebuilt for about a month. 

Current Action:

Alex is currently rebuilding the frame builder with the latest code changes.

It also suggests I should try rebuilding the frame builder on a semi-regular basis as updates come in.

[Yuta Koji]

(Report on Aug 12, 2022)

We went around the lab for the final check. Here are the additional notes.

• 1X9: The x-end frontend machine still had the AC power. The power strip to which the machine is connected was disconnected from the AC at the side of the rack. (Attachment 1)
• 1X8: The vacuum rack still supplied the AC to c1vac. This was turned off at the UPS. (Attachment 2)
• 1X6: VMI RFM hub still had the power. This was turned off at the rear switch. (Attachment 3)
• PSL: The PSL door was open (reported above). Closed. (Attachment 4)
• 1Y2: The LSC rack still had the DC power. The supplies were turned off at the KEPCO rack (the short rack). (Attachment 5)
  Note that the top-right supply for the +15V is not used. (The one in the empty slot got busted). We may need some attention to the left-most one in the second row. It indicated a negative current. Is this just the current meter problem or is the supply broken?
• Control room: The CAD WS was turned off.

I declare that now we are ready for the power outage.

Jenne, Koji

Recent status of SOSs:

We completed one of the suspension (ITMY).

ITMX: 6 Magnets, standoffs, and guide rod glued / balance to be confirmed / needs to be baked
ITMY: 6 Magnets, standoffs, and guide rod glued / balance confirmed / needs to be baked
SRM: 6 Magnets, one standoff, and guide rod glued,  / waiting for the release from the gluing fixture.
PRM: one standoff, and guide rod glued / waiting for the magnet gluing. 

We think we solved all the problems for hanging the suspensions.

--- Magnet gluing fixture ---

• There is the two kinds of fixtures. Neither does work propery in the original form!
• The height of the side magnets should be finely adjusted by changing the teflon sheets beneath the optics in the fixture.
• Be aware of the polarity of the fixture in terms of the side magnets
• Wrongly glued magnets (and others) can be removed by a razor blade with some amount of acetone.
• The pickle picker frequently knocks the magnets down during the release. Don't s be down in the dumps too much.

--- Suspending the mirror ---

• The wire winches must be carefully attached to the suspension tower such that the wires are not streached during fastening the clamps.
• There are a couple variations of the drawings for SOS. The one we have has #4-40 for the earthquake stops at the bottom.
  Zach and Mott made the EQ stops with the right size.

[yehonathan, anchal, paco]

Yesterday around 9:30 pm, we centered the BS, ITMY, ETMY, ITMX and ETMX oplevs (in that order) in their respective QPDs by turning the last mirror before the QPDs. We did this after running the ASS dither for the XARM/YARM configurations to use as the alignment reference. We did this in preparation for PRFPMI lock acquisition which we had to stop due to an earthquake around midnight

Late elog. Original time 08/02/2021 21:00.

I locked both arms and ran ASS to reach to optimum alignment. ETMY PIT > 10urad, ITMX P > 10urad and ETMX P < -10urad. Everything else was ok absolute value less than 10urad. I recentered these three.

Than I locked PRMI, ran ASS on PRCL and MICH and checked BS and PRM alignment. They were also less than absolute value 10urad.

I recently realized that the PLL is only using about 20% of the available actuation range of the AUX PZT. The +/-10 V control signal from the LB1005 is being directly inputted into the fast AUX PZT channel, which has an input range of +/-50 V.

I recommend to install a PZT driver (amplifier) between the controller and laser to use the full available actuator range. For cavity scans, this will increase the available sweep range from +/-50 MHz to +/-250MHz. This has a unique advantage even if slow temperature feedback is also implemented. To sample faster than the timescale of most of the angular noise,  scans generally need to be made with a total sweep time <1 sec. This is faster than the PLL offset can be offloaded via the slow temperature control, so the only way to scan more than 100 MHz in one measurement is with a larger dynamic range.

I reconfigured the MC reflection path for low power. This meant the following changes:

• Replaced the 10% reflection BS by 98% reflection beam splitter
• Realigned the BS angle to get maximum on C1:IOO-MC_RFPD_DCMON when cavity is unlocked.
• Then realigned the steering mirrors for WFS1 and WFS2.
• I tried to align the light for MC reflection CCD but then I realized that the pickoff for the camera is too low for it to be able to see anything.

Note, even the pick-off for WFS1 and WFS2 is too low I think. The IOO WFS alignment does not work properly for such low levels of light. I tried running the WFS loop for IMC and it just took the cavity out of the lock. So for low power scenario, we would keep the WFS loops OFF.

The lens in front of IPANG on the out-of-vac table was moved to get a larger beam giving reasonable signals at the QPD.

IPPOS did not need much adjustment and was happy at the center of the QPD.

All oplevs but the ETMY were close to the center. I had to move the first steering mirror about half an inch on the out-of-vac table to catch the returning oplev beam from ETMY and direct it to the oplev PD.

* We have taken reasonable amount of in-vac pictures of ETM, ITM and BS chambers to update the CAD drawing.

Rather than make a new elog post every time I move something, I'm going to just keep updating this Google spreadsheet, which ought to republish every time I change it. It's already got everything I've done for the past week-ish. The spreadsheet can be accessed here, as a website, or here, as a pdf. I will still post something nightly so that you don't have to search for this post, but I wanted to be able to provide more-or-less real-time information on where things are without carpet-bombing the elog.

Thus far, the software needed for the Magewell video encoder has been successfully installed on Donatella. OBS studio has also been installed and works correctly. OBS will be the video recording software that can be interfaced via command line once the SDI video encoder starts working. (https://github.com/muesli/obs-cli)

So far, the camera can not be connected to the Magewell encoder. The encoder continues to have a pulsing error light that indicates "no signal" or "signal not locked". I have begun testing on a secondary camera, directly connected to the Magewell encoder with similar errors. This may be able to be resolved once more information about the camera and its specifications/resolution is uncovered. At this time I have not found any details on the LCL-902K by Watec that was given to me by Koji. I will begin looking into the model used in the 40 meter next.

Connect any video signal supported by the adapter. Use Windows / Mac or any other OS. If it keeps complaining, contact Magwell support.

[Kiwamu, Jenne]

We went this evening in search of a beat note signal between the Xarm transmitted green light and the PSL doubled green light. 

First, we removed our new ETMX camera (we left the mount so it should be easy to put back) from the other day.   We left the test masses exactly where they had been while flashing for IR, so even though we can no longer confirm, we expect that the IR beam axis hasn't changed.  We used the steering mirror on the end table to align the green beam to the cavity.  We turned on the loop to lock the end laser to the cavity, and achieved green lock of the arm.

Then we went to the PSL table to overlap the arm transmitted light with the PSL doubled light.  We made a few changes to the optics that take the arm transmitted light over to the PD.  We found that the arm transmitted light was very high, so we changed from having one steering mirror to having 3 (for table space / geometry reasons we needed 3, not just 2) in order to lower the beam axis.  We also found that the spot size of the arm transmitted beam was ~2x too small, so we changed the mode matching telescope from a 4x reducer to a 2x reducer by changing the 2nd lens from f=50mm to f=100mm (the first lens is f=200mm).  We made the arm transmitted beam and the PSL green beam overlap, but we saw no peak on the spectrum analyzer. 

We checked the temperature of the PSL and end lasers, and determined that we needed to adjust the set temp of the end laser.  However, we still didn't find any beat note.

We then tweaked the temperature of the doubling oven at the end station, to maximize the power transmitted, since Kiwamu said that that had worked in the past.  Alas, no success tonight.

We're stopping for the evening, with the success of reacquiring green lock of the Xarm.

Now that we have all Satellite boxes working again, I've been working on trying to recover the DRMI 1f locking over the last couple of days, in preparation for getting back to DRFPMI locking. Given that the AS light levels have changed, I had to change the whitening gains on the AS55 and AS110 channels to take this into account. I found that I also had to tune a number of demod phases to get the lock going. I had some success with the locks tonight, but noticed that the lock would be lost when the MICH/SRCL boosts were triggered ON - when I turned off the triggering for these, the lock would hold for ~1min, but I couldn't get a loop shape measurement in tonight.

As an aside, we have noticed in the last couple of months glitchy behaviour in the ITMY UL shadow sensor PD output - qualitatively, these were similar to what was seen in the PRM sat. box, and since I was able to get that working again, I did a similar analysis on the ITMY sat. box today with the help of Ben's tester box. However, I found nothing obviously wrong, as I did for the PRM sat. box. Looking back at the trend, the glitchy behaviour seems to have stopped some days ago, the UL channel has been well behaved over the last week. Not sure what has changed, but we should keep an eye on this...

[Paco, Yuta]

We recovered the LO beam on the BHD port. To do this, we first tried reverting to a previously "good" alignment but couldn't see LO beam hit the sensor. Then we checked the ITMY table and couldn't see LO beam either, even though the AS beam was coming out fine. The misalignment is likely due to recent changes in both injection alignment on TT1, TT2, PR2, PR3, as well as ITMX, ITMY. We remembered that LO path is quite constrained in the YAW direction, so we started a random search by steering LO1 YAW around by ~ 1000 counts in the negative direction at which point we saw the beam come out of the ITMY chamber

We proceeded to walk the LO1-LO2 in PIT mostly to try and offload the huge alignment offset from LO2 to LO1 but this resulted in the LO beam disappearing or become dimmer (from some clipping somewhere). This is WiP and we shall continue this alignment offload task at least tomorrow, but if we can't offload significantly we will have to move forward with this alignment. Attachment #1 shows the end result of today's alignment.

The following that went unnoticed from yesterday were recovered today:

1. ETMX and ETMY 'misalign' scripts weren't running. Troubleshooting showed slow machines c1auxex and c1auxey weren't responding. The machines were reset.

2. PRM oplev gains were zero. Gain values were set looking back at the burt files.

3. X end PZT power supplies were turned ON and set to 100V.

4. X end doubler temperature was reset to the last optimal value on elog (36.35 deg).

Some hitches that should be looked into:

1. Check: ASS for X arm seems not quite doing its job. ETMX has to be moved using sliders to obtain maximum TRX and the arm alignment was seen to be drifting.

2. Check: Status of other slow machines and burt restore whichever needs one.

ETMX ASC output was turned off for whatever reason. Switched it on, ASS is fine.

[ericq, Jenne]

We both happened to come by today to fix things up.

When I arrived, the PMC was locked to a 01 mode, which I fixed. The PMC transmission is still worryingly low. MC locked happily. 

ETMX was getting odd kicks, the kind where a DC shift would occur suddenly, and then go away a few moments later. I turned off all dynamic coil outputs, and looked at the MON output of the SOS driver with a scope to try and see if the DAC or dewhitening was glitching, but didn't see anything... Meanwhile, Jenne fiddled with the TTs until we got beams on POP and REFL. (EDIT, JCD:  Useful strategies were to put an excitation onto TT2, and move TT1 until the scattered beam in the chamber was moving at the excitation frequency,  Find the edges of TT2 by finding where the scattered light stops seeing the excitation, and center the beam on TT2.  By then, I think I saw the beam on the PRM face camera.  Then, put a temporary camera looking at the face of PR2.  Using TT2 to center here got us the beam on the POP camera.)

We then walked PRM and the TTs around to keep those two camera beams and get the PRM oplev beam back on its QPD. At this point, ITMX was misaligned (by us), and ITMY aligned to get some recycled flashes into the Y-arm. Y-arm was locked to green, and we poked TTs to get better IR flashes. Misaligning PRM, we had Y-Arm flashes of ~0.7. From there, the michelson and then X-arm were roughly aligned. Both arms were seeing flashes of about 0.7, and the MICH fringes on the AS port look nice.

Frustratingly, the SUS->LSC communication for TRY and TRX isn't working, and could not be fixed by any combination of model or front-end restarting... Thus we haven't been able to actually lock the arms and run ASS. THIS IS VERY FRUSTRATING. 

Additionally, at the point where we were getting light back into the Yarm, the ITMX that were seen on Friday were happening again, tripping the watchdog. Also, something in the Yarm cavity is getting intermittently pushed around, as can be seen by the green lock suddenly wandering off. All of these suspension shenanigans seem to be independent of oplev damping. 

It troubles me that this whole situation is fairly similar to the last time we lost the input pointing (ELOG 10088)

In any case, we feel that we have gotten the IFO alignment to a lockable state.

It's great that you guys found the beam.
Yes, ITMX kick and lost communication for TRY were the motivation of my CDS rebooting.

[Anchal, JC, Radhika, Paco]

JC reported that power outage happened twice in 40m today at around 4:17 pm.

We followed instructions from this page mostly to recover today. Following are some highlights:

Main laser controller fan broke

Paco reported that the adhoc fan in the back of main laser controller slid down and broke. Their might be contamination on the table from broken fan parts. Paco replaced this fan with another fan which is larger. I think it is time to fix this fan on the controller for good.

Main volume valve V1 shutdown

The main volume valve shut down because c1vac turned off. We restored the vacuum state by simply opening this valve again. Everything else was same as until the final step in vacuum resetting steps.

Mode cleaner locking issues

The burt restore for mode cleaner board settings do not bring back the state of channels C1:IOO-MC_FASTSW and C1:IOO-MC_POL. This has been an issue which has puzzled us in the past too as we try to get the mode cleaner to lock after power outage recovery. I have now added these channels and their required state in autolocker settings so that autolocker scan in the correct state always. It seems like I added with Yuta's name in the commit author.

[Steve Koji Kiwamu]

- The storage on linux1 and linux1 itself (with this order) were turned on at 10:30am

- Kiwamu restored the vacuum system

   => opened V4, started TP1 (maglev) and opened V1.

      The pressure went downfrom 2.5 mTorr to the normal level in about 20 minutes.

- A regular fsck of linux1 was completed at 5pm

- Nodus was turned on. Mounting /cvs/cds succeeded

- The control room computers were turned on

- The rack power for FB turned on, FB and megatron started.

- HVs on 1X1 were turned on. The are not vacuum HV, but used only in the air

- Turned on the RF generation box and the RF distribution box

- burtrestore slow machines (c1psl, c1susaux, c1iool0, c1iscaux, c1iscaux2, c1auxex, c1auxey)

Found the Marconi for the 11 MHz source had been reset to its default.

 => reset the parameters. f = 11.065910 MHz (see #5530) amp = 13 dBm.

Interferometer became lockable. I checked the X/Y arm lock, and MICH lock, they all are fine.

I failed to start Rana's favorit anciant desktop computer at the vac rack. He has to baby this old beast just a little bit more.

Vacuum status: Vac Normal was reached through Farfalla: Rga was switched back to IFO and and Annuloses are beeing pumped now.

V1 was closed for about a day and the pressure reached  ~2.8 mTorr in the IFO.  This leakrate plus outgassing is normal

The ref cavity 5000V was turned on.

The only thing that has to be done is to restart the RGA. I forgat to turn it off on Friday.

 As it turns out Steve is not crazy in this particular instance: the vacuum computer, linux3 , has some issues. I can login just fine, but trying to open a terminal makes the CPU rail and the RAM max out and eventually the machine freezes.

Under KDE, I can open a terminal OK as root, but if I then try a 'su controls', the same issue happens. Let's wait for Jamie to fix this.

Restarted Apache on nodus using Yoichi's wiki instructions. SVN is back up.

The following is a message from the LIGO 40m Chief Recycling Officer:

Please get up off your (Alignment Stabilization Servo)es and recycle your bottles and cans!  There is a recycling bin in the control room.  Recent weeks have seen an increase in number of bottles/cans thrown away in the regular garbage.  This is not cool. 

Thank you,

---L4mCRO

 Going off some discussion we had at lunch today, here is my current knowledge of the state of cavity lengths. 

Acknowledging that Koji changed the sideband modulation frequency recently, the ideal cavity lengths are (to the nearest mm):

• Lprc = c / ( 4 * fmod) = 6.773 m
• Lsrc = c / ( 5 * fmod) = 5.418 m

We when last hand measured distances, after moving PR2, we found:

• Lprc  = 6.752 m = 2.1 cm short
• Lsrc  = 5.474 m = 5.6 cm long. 

However, when I looked at the sideband splitting interferometrically, I found:

• Lprc = 6.759m = 1.4 cm short

This is only 5mm from the hand measured value, so we can believe that the SRC length is between 5 and 6 cm too long. I'm building a MIST model to try and see what this may entail. 

Com'on. This is just a 60ppm change of the mod frequency from the nominal. How can it change the recycling cav length by more than a cm?

https://wiki-40m.ligo.caltech.edu/IFO_Modeling/RC_lengths

This describes how the desirable recycling cavity lengths are affected by the phase of the sidebands at non-resonant reflection of the arms.

If we believe these numbers, L_PRC = 6.7538 [m] and L_SRC = 5.39915 [m].

Compare them with the measured numbers

• Lprc = 6.752 m
• Lsrc  = 5.474 m

You should definitely run MIST to see what is the optimal length of the RCs, and what is the effect of the given length deviations.

Koji correctly points out that I naïvely overlooked various factors. With a similar analysis to the wiki page, I get:

• Ideal arm length of 37.795 m
• Ideal PRC length of 6.753 m
• Ideal SRC length of 5.399 m

This means that:

• The PRC, measured at 6.759m, is 6mm long. 
• The SRC, measured at 5.474m, is 7.5 cm long

Next step is to see how this may affect our ability to sense, and thereby control, the SRC when the arms are going. 

MIST simulations and plots are in the attached zip. 

I looked at the data of the day before yesterday (Oct 06) to know how much is the recycling gain.

X arm: (TRX_PRecycled) / (TRX_PRMmisaligned) * T_PRM = 83.1/0.943*0.07 = 6.17
Y arm: (TRX_PRecycled) / (TRX_PRMmisaligned) * T_PRM = 99.2/1.017*0.07 = 6.83

==> G_PR = 6.5 +/- 0.5     (oh...this estimation is so bad...)

From the recycling gain and the arm cavity reflectance, one can get the loss in the recycling cavity.

G_PR = T_PRM  / (1-Sqrt(R_PRM * (1-L_PRC)*R_cav))^2

==> loss in the recycling cavity L_PRC: 0.009+/-0.009
       (About 1% loss is likely in the recycling cavity)

I put all three seismometers and all six accelerometers together in the foam box with peanuts. Three of the accelerometers are facing in the x-direction and three are in the y-direction. Both Guralps are aligned on the NS axis and the Ranger is pointing vertically.

**EDIT: The accelerometers are in the x and z directions, not x and y. Sorry, I was sleepy when I wrote this.**

One of the accelerometers was refusing to show anything, and after a few hours of checking connections and swapping cables, I discovered that someone had unplugged the cable from the ADC. A quick glance in the dataviewer shows that the channel has been unplugged since about 3 in the afternoon on August 8th (Saturday). So... obviously all the accelerometer measurements made with that channel since then did not actually get recorded. Yay.

Anyway, as of 2:45, everything is working and taking data. Clearly we're not getting a full night's worth... hopefully that's okay.

I noticed that our current suspension damping loops for the new SOS were railing the DAC outputs. The reason being that cts2um module has not been updated for most optics and thus teh OSEM signal (with the new Sat Amps) is about 30 times stronger. That means our usual intuition of damping gains is too high without applying correct conversion cts2um filter module. I reduced all these gains today and nothing is overflowing the c1su2 chassis now. I also added two options in the "!" (command running drop down menu) in the sus_single medm screens for opening ndscope for monitoring coil outputs or OSEM inputs of the optic whose sus screen is used.

I am using a PDA255 photodiode to measure the power outputted by the NPRO beam on the PSL table. (I'm going to then use a network analyzer to measure the amplitude response of the PZT to being driven at a range of frequencies. I'll detect the variation in in response to changing the driving frequency using this PDA255.)

The PDA255 has an active area of 0.8mm^2 and a maximum intensity for which the response is linear of 10mW/cm^2. This means that a beam I focus on the PD must have a power less than 0.08 mW (and even less if the spot size is smaller than the window size).

I used a power meter to measure the beam power and found it was 0.381 mW.

The second polarizing beam splitter in the setup transmits most of the beam power, but reflects 0.04 mW (according to the power meter). I'm going to place the photodiode there in the path of the reflected beam.

[Alberto, Jenne]

We aligned both the reference cavity and the PMC, each by looking at their Trans PD on Davaviewer, and adjusting the two steering mirrors to maximize the transmission power.  We got a pretty good amount of improvement for the ref cav, but since the PMC hasn't decayed a whole lot, we got a much smaller amount of improvement.

After Alberto and I worked on aligning the reference cavity, Rob asked the important and useful question: what is the visibility of the reference cavity.  This helps tell us if we're optimally aligned or not even close.

I did a scan of the ref cav temperature, using /scripts/PSL/FSS/SLOWscan, but there seems to be no real signal is C1:PSL-FSS_RFPDDC.  As shown in Alberto's 200-day plot, it does change sometimes, but if you zoom in on the flat parts, it seems like it's not really reading anything meaningful.  I did a cursory check-out of it, but I'm not 100% sure where to go from here:  There are (as with all of these gold-box PDs) 3 outputs:  a ribbon cable (for ADC purposes I think), an SMA for the RF signal, and a BNC for the DC signal.  The photodiode is clearly working, since if you stick the Lollypop in front of the PD, the cavity unlocks.  I plugged a 'scope into the DC BNC, and it also behaves as expected: block the beam and the signal goes down; unblock the beam and the signal goes up.  Something of note is that this readout gives a positive voltage, which decreases when the beam is blocked.  However, looking at the dataviewer channel, nothing at all seems to happen when the beam is blocked/unblocked.  So the problem lies somewhere in the get-signal-to-DAQ path.  I unplugged and replugged in the ribbon cable, and the value at which the channel has been stuck changed.  Many days ago, the value was -0.5, for the last few days it's been -1.5, and after my unplug/replug, it's now back to ~ -0.5 . The other day Alberto mentioned, and made the point again today that it's a little weird that the PD reads out a negative voltage.  Hmm.

Do we have a tester-cable, so that instead of the ribbon cable, I can plug that connector (or pins thereof) into a 'scope?

we have a tester cable, but you don't want it. Instead the problem is probably at the cross-connect. The D-cable goes to a cross-connect and you can probe there with a voltmeter. If the signal is good there, trace it to the ADC. Also trend for several years to see when this happened - Yoichi may know the history better.

Also, we still need to complete the FSS RFPD task list from last year.

 [Jenne, Ben]

I called in the reinforcements today.  Ben came over and we looked all around at all of the cross-connects and cables relating to the FSS.  Everything looks pretty much okey-dokey, except that we still weren't getting signal in the DataViewer channels.  Finally we looked at the psl.db file, which indicates that the C1:PSL-FSS_RFPDDC channel looks at channel 21 of the ADC cross connect thing.  We followed the cable which was plugged into this, and it led to a cable which was disconnected, but laying right next to the Ref Cav refl PD.  We plugged this into the DC out SMA connection of the photodiode (which had not been connected to anything), and suddenly everything was mostly golden again in dataviewer land.  RFPDDC_F now has a signal, but RFPDDC is still flat. 

Even though this seems to be working now, it's still not perfect.  Rob suggested that instead of having this SMA cable going from the photodiode's DC out, we should take the signal from the ribbon cable.  So I'm going to figure out which pin of the D-connector is the DC out, and take that from the cross connect to the ADC cross connect.  This will help avoid some persnickity ground loops.