40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 130 of 341 Not logged in
ID Date Author Type Category Subject
16838   Mon May 9 18:49:05 2022 TegaUpdateBHDRelocate green TRX and TRY PDs/cams/optics from PSL table to BS table

[Paco, Tega]

Started work on the relocating the green transmission optics, cameras and PDs. Before removing the any of the optics, we checked and confirmed that the PDs and Cams are indeed connected to the GRN TRX/Y medm channels. Then added labels to the cables before moving them.

Plumbing:

• Moved all power and signal cables for the PDs and cameras from PSL table to BS table. See attachment #1

Relocated Optics & PDs & Cameras:

• TRX and TRY cameras
• TRX and TRY PDs
• 1 BS, 2 lens for PDs and a steering mirror, see Atachement #2

Attachment 1: IMG_20220509_184439943.jpg
Attachment 2: IMG_20220509_184154722.jpg
13952   Wed Jun 13 01:02:40 2018 gautamUpdateLSCReliable and repeatable 1f DRMI locking

[koji, gautam]

With Koji's help, I got repeatable and reliable DRMI locking going again tonight - this is with the AS path optics for the spectroscopy measurement in place, although the AUX laser remained shuttered tonight. Results + spectra tomorrow, but here's what I did:

• Initial alignment procedure was as usual - use arms+ASS to align ITMs, and then PRMI carrier+ASS to align PRM and BS.
• Found the appropriate gains and demod phases.
• Measured loop TFs - PRCL is a big mystery. Used these to finalize loop gains.
• Ran some sensing lines.
• Whitened DRMI PDs for a calibrated "low-noise" spectrum (although the coils were not de-whitened).

As I have found before, it is significantly easier to get the locking going post 11pm - the wall Seis BLRMS don't look that much quieter at midnight compared to 10pm, but this might be a scaling issue. I'll do a quantitative assessment next time... Also, Foton takes between 25-45 secs to save an updated filter (timed twice today).

13966   Thu Jun 14 18:09:24 2018 gautamUpdateLSCReliable and repeatable 1f DRMI locking

I finally analyzed the sensing measurement I ran on Tuesday evening. Sensing responses for the DRMI DOFs seems consistent with what I measured in October 2017, although the relative phasing of the DoFs in the sensing PDs has changed significantly. For what it's worth, my Finesse simulation is here

Attachment 1: DRMI1f_June14.pdf
10848   Tue Dec 30 17:26:23 2014 ranaUpdatePSLRelaxation Osc and the NPRO Noise eater

I wonder if the variable bump around 100 kHz can be something about the NPRO and if the bump we see is the closed loop response due to the Noise Eater.

This plot (from the Mephisto manual) shows the effect of the NE on the RIN, but not the frequency noise. I assume its similar since the laser frequency noise above 10 kHz probably just comes from the pump diode noise.

I went out to the PSL and turned off the NE at ~4:53 PM local time today to see what happened. Although the overall PCDRIVE signal looks more ratty, there is no difference in the spectra of ON/OFF when the PCDRIVE is low. When its noisy, I see a tiny peak around 1 MHz with NE OFF. Turned it back on after a few hours.

11141   Fri Mar 13 23:49:28 2015 ranaUpdatePSLRelaxation Osc and the NPRO Noise eater

Another thought about the mystery PCDRIVE noise: we've been thinking that it could be some slow death inside the NPRO, but it might also be a broken and intermittent thing in the MC servo or MC REFL PD.

Another possibility is that its frequency noise in the old oscillator used to drive the pre-PMC EOM (which is the Pockel Cell for the FSS). To check this, we should swap in a low noise oscillator for the PMC. I have one for testing which has 36 and 37 MHz outputs.

15326   Tue May 12 18:16:17 2020 gautamUpdateLSCRelative importance of losses in the arm and PRC

Attachment #1 is meant to show that having a T=500ppm PR2 optic will not be the dominant contributor to the achievable recycling gain. Nevertheless, I think we should change this optic to start with. Here, I assume:

• \eta_A denotes the (average) round trip loss per arm cavity (i.e. ITM + ETM). Currently, I guess this is ~100ppm.
• Fixed 0.5% loss from mode mismatch between the CARM mode and the PRC mode (the x-axis does NOT include this number).
• No substrates/AR coatings inside the cavity.
• For the nominal case, let's say the intracavity loss sums to 100 ppm.
• For the T=500ppm PR2, I assumed a total of 550 ppm loss in the PRC.

In relaity, I don't know how good the MM is between the PRC and the arms. All the scans of the arm cavity under ALS control and looking at the IR resonances suggest that the mode-matching into the arm is ~92%, which I think is pretty lousy. Kiwamu and co. claim 99.3% matching into the interferometer, but in all the locks, the REFL mode looks completely crazy, so idk

Attachment 1: armLossVSPRCloss.pdf
15327   Tue May 12 20:16:31 2020 KojiUpdateLSCRelative importance of losses in the arm and PRC

Is \eta_A the roundtrip loss for an arm?

Thinking about the PRG=10 you saw:
- What's the current PR2/3 AR? 100ppm? 300ppm? The beam double-passes them. So (AR loss)x4 is added.
- Average arm loss is ~150ppm?

Does this explain PRG=10?

15328   Tue May 12 22:47:49 2020 gautamUpdateLSCRelative importance of losses in the arm and PRC

Yes, \eta_A is the (average) round-trip loss for an arm cavity. I'd estimate this is ~100ppm currently. I edited the original elog to fill in this omission.

The RC mirror specs require some guesswork - the available specs for the Laseroptik mirrors (PR3) are for a 48 degree angle of incidence, and could be as high as 0.5 %. According to the poster, the spec is 2.6% loss inside the recycling cavity but I don't know where I got the number for the AR surface of the G&H PR2, and presumably that includes some guess I made for the MM between the PRC and the arm. Previously, assuming ~1-2% loss inside the RC gave good agreement between model and measurement. Certainly, if we assume similar numbers, a recycling gain of ~11 (200 * T_P=5.637%) is reasonable. But I think we need more data to make a stronger statement.

 Quote: Is \eta_A the roundtrip loss for an arm? Thinking about the PRG=10 you saw: - What's the current PR2/3 AR? 100ppm? 300ppm? The beam double-passes them. So (AR loss)x4 is added. - Average arm loss is ~150ppm? Does this explain PRG=10?
11214   Fri Apr 10 17:05:45 2015 ericqUpdateLSCRelative ETM calibration (Rough MC2 calibration)

I did a quick measurement get an idea of the ETM actuator calibration, relative to the ITMs. This will still hold if/when we revisit the ITM calibration via the Michelson.

For the test masses, I locked the arms individually using MC2 as the actuator, and took transfer functions from the SUS-[OPTIC]_LSC_EXC point to the PO[X/Y]_I_ERR error signals. There were two points with coherence less than 99% that I threw away. I then took the fraction at each point, and am using the standard deviation of those fractions as the reported random error, since the coherence was super high for all points, making the error of each point negligible relative to their spread.

This gives:

• ETMX/ITMX: 2.765 +- 0.046
• ETMY/ITMY: 2.857 +- 0.029

With the data from ELOG 8242, this implies:

• ETMX: 13.00 +- 0.22 x 10 -9 / f2 m/counts
• ETMY: 13.31 +- 0.15x 10 -9 / f2 m/counts

MC2 data was taken with the arms locked with the ETMs. The results are not so clean, the fractions don't line up; there is some trend with excitation frequency... The ratio is around the same as the ETMs, but I'm not going to quote any sort of precision, since I don't fully understand what's happening. Kind of a bummer, because it struck me that we could get an idea of the arm length mismatch by the difference in IMC frequency / arm FSR. I'll think about this some more...

Attachment 1: quickCal.png
11215   Fri Apr 10 18:39:39 2015 ericqUpdateLSCRelative ETM calibration (Rough MC2 calibration)

I didn't verify that the loop gain was low enough at the excitation frequencies.

I put a 1kHz ELP in both arm servos, and got cleaner data for both. The ETM numbers are pretty much consistent with the previously posted ones, and the MC2 data now is consistent across frequencies. However, the MC2 numbers derived from each arm are not consistent.

Now:

• ETMX / ITMX: 2.831 +- 0.043
• MC2 / ITMX: 3.260 +- 0.062
• ETMY / ITMY: 2.916 +- 0.041
• MC2 / ITMY: 3.014 +- 0.036

With the data from ELOG 8242, this implies:

• ETMX: 13.31 +- 0.21 x 10-9 / f2 m/counts
• ETMY: 13.59 +- 0.20 x 10-9 / f2 m/counts
• MC2 in Xarm meters : 15.32 +- 0.30 x 10-9 / f2 m/counts
• MC2 in Yarm meters : 14.04 +- 0.18 x 10-9 / f2 m/counts
This is, of course, pretty fishy. Each arm sees the same frequency fluctuation of the light coming out of the IMC, especially given that the MC2 to arm data was taken simultaneously for both arms. Now, one possible source of this kind of mismatch would be a mismatch of the arm lengths, but there is no way they differ by 10%, as they would have to in order to explain the above numbers. To me, it seems more likely that the ITM calibrations are off.
Attachment 1: betterCal.png
5090   Tue Aug 2 10:53:03 2011 JenneOmnistructureSAFETYRegular door out of service. Use Control Room Door only!!

The hazardous waste people are moving chemicals around outside our door, and have roped off our regular front door.

Please go around, and use the control room door to enter and exit.  It is currently unlocked, although I'll lock up when I leave for LIGOX.

300   Wed Feb 6 16:50:47 2008 josephbConfigurationCamerasRegions of Interest and max frame rate
The Snap code has once again been modified such that setting the -l option to 0 will take images as fast as possible. Also, the -H and -W options set the height and width, while in principle the -Y and -X options set the position in pixels of the top edge and left edge of the image. It also seems possible to set these values such that the saved image wraps around. I'll be adding some command checking so that the user can't do this in the near future.

Doing some timed runs, using a -H 350 and -W 350 (as opposed to the full 752x480), 100 images can be saved in roughly 8 seconds, and 1000 images took about 73 seconds. This corresponds to a frame rate of about 12-13 frames per second (or a 12-13 Hz display). The size of this area was sufficient to cover the current PMC transmission beam.

The command line I used was

time ./Snap -l 0 -m 1000 -f 'test' -W 350 -H 350 -Y 50 -X 350 -E 2000

Interestingly enough, there would be bursts of failed frame saves if I executed commands in another terminal (such as using ls on the directory where the files were being stored).

As always, this code is available in /cvs/cds/caltech/target/Prosilica/40mCode/.
301   Wed Feb 6 19:39:11 2008 ranaConfigurationCamerasRegions of Interest and max frame rate
We really need to look into making the 40m CDS network have an all GigE backbone so that we can have cooler cameras as well as collect multiple datastreams...
1520   Sat Apr 25 00:45:31 2009 YoichiConfigurationVACReflector for the cryopump temperature monitor changed
The temperature of the cryopump head is monitored by a photo switch looking at an aluminum foil reflector attached to the needle of the temperature gauge.
If the needle moves out of the 14K position, the photo switch will be triggered to close the cryopump gate valve.
However, this photo switch system has been touchy.
Tonight, the switch falsely tripped several times and closed the gate valve, which caused lock losses as the motion of the valve generates a lot of vibrations.
Seems to me, it was caused by the poor/irregular reflection from the wrinkled aluminum foil on the needle.
So I replaced the aluminum foil with a brand-new shiny one.
1521   Sat Apr 25 02:54:25 2009 YoichiConfigurationVACReflector for the cryopump temperature monitor changed

 Quote: The temperature of the cryopump head is monitored by a photo switch looking at an aluminum foil reflector attached to the needle of the temperature gauge. If the needle moves out of the 14K position, the photo switch will be triggered to close the cryopump gate valve. However, this photo switch system has been touchy. Tonight, the switch falsely tripped several times and closed the gate valve, which caused lock losses as the motion of the valve generates a lot of vibrations. Seems to me, it was caused by the poor/irregular reflection from the wrinkled aluminum foil on the needle. So I replaced the aluminum foil with a brand-new shiny one.

The photo switch still trips randomly. We need a better interlock.
2362   Mon Dec 7 19:02:22 2009 MottUpdateGeneralReflectivity Measurements

I have made some measurements of the R value for some coatings we are interested in.  The plots have statistical error bars from repeated measurements, but I would suspect that these do not dominate the noise, and would guess these should be trusted to plus or minus 5% or so.  They still should give some indication of how useful these coatings will be for the green light.  I plan to measure for the ITM as soon as possible, but with the venting and finals this may not be until late this week.

EDIT (12/9/09): I fixed the label on the y axis of the plots, and changed them to png format.

Attachment 1: Y1-45P_R.png
Attachment 2: Y1-45S_R.png
Attachment 3: Y1-50CC_R.png
476   Wed May 14 13:14:19 2008 AndreySummaryComputersReflective Memory Network is restored

Reflective Memory Network is restored, all watchdogs and oplevs are returned to the "enabled" state.

In order to revive the computers, several things were done.

1) Following Mr. Adhikari's elog entry #353, I walked around the interferometer room, and switched off the power keys in all crates with computers whose names are contained in the MEDM Reflective Memory screen, including the rack with the framebuilder. By the way, it was nontrivial to find the switch in the 1Y4 crate that would shut off/on processors "c1susvme1" and "c1susvme2": the switch turned out to be located at the rear side of the crate, and it is not a key but it is a button.

2) I was trying to follow wiki-40 computer restart procedures, but every time that I was trying to run "startup.cmd" screen from the corresponding target subdirectory, I got the error message "Device or resource busy".
By the way, one more thing was learned: if you firstly open in terminal burtgooey, select the snap file, then reboot the processor, and then will try to burt-restore it, you will get the message "Status Not OK". In order to really burt-restore the processor which was recently rebooted, you need to close the terminal with burtgooey and open burtgooey in a new terminal window which should be opened after rebooting the processor.

Feeling that my activities according to wiki-40 procedures do not revive computers, I invited Alex Ivanov.

3) Alex tried to touch the memory card in "c1iovme" in rack 1Y2, because once before this card failed causing network problems, but this did not help.

4) We shutted off and restarted again (pressing the power-switching button) the black Linux machine "c1dcuepics" (located in the very bottom below the framebuilder). Alex says that this machine is responsible for all EPICS. It was not restarted for 182 days, and probably some process there went wrong.

After restarting this machine "c1dcuepics" we were able to follow wiki-40 procedures for restarting all other computers (whose names are on the MEDM RFM network). We ran correcponding "startup.cmd" files and burt-restored them without error messages.

Now all the computers work and communicate in a proper way.

Mr. Joseph Betzwiezer was helping me with all these activities (we decided that it is more important that cameras for now), thanks to him. But our joint skills turned out to be insufficient, so Alex Ivanov's contribution was the most important.
2915   Wed May 12 02:35:13 2010 Koji, Rana, KiwamuUpdateGreen LockingReflection from ETM and ITM !

We succeeded in getting the reflected green beam from both ITMY and ETMY.

After we did several things on the end table, we eventually could observe these reflections.

Now the spot size of the reflection from ITMY is still big ( more than 1 cm ), so tomorrow modematching to the 40m cavity is going to be improved by putting mode matching telescopes on right positions.

An important thing we found is that, the beam height of optics which directly guides the beam to the cavity should be 4.5 inch on the end table.

(what we did)

* Aidan, Kevin and Kiwamu set the beam to be linearly polarized by rotating a QWP in front of the Innolight. This was done by monitoring the power of the transmitted light from the polarizer attached on the input of the Faraday of 1064 nm. Note that the angle for QWP is 326.4 deg.

* We put some beam damps against the rejected beam from the Faraday

* To get a good isolation with the Faraday we at first rotated the polarization of the incident beam so to have a minimum transmission. And then we rotated the output polarizer until the transmission reaches a minimum. Eventually we got the transmission of less than 1mW, so now the Faraday should be working regardless of the polarization angle of the incident beam. As we predicted, the output polaerizer seems to be rotated 45 deg from that of the input.

* Rana, Koji and Kiwamu aligned the PPKTP crystal to maximize the power of 532 nm.  Now the incident power of 1064 nm is adjusted to 250mW and the output power for 532 nm is 0.77mW. Actually we can increase the laser power by rotating a HWP in front of the Faraday.

* We injected the green beam to the chamber and aligned the beam axis to the ETMY without the modematching lenses, while exciting the horizontal motion of the ETM with f=1Hz from awg. This excitation was very helpful because we could figure out which spot was the reflection from the ETM.

* Once we made the reflected beam going close to the path of the incident beam, we then put the modematching lenses and aligned the steering mirrors and lenses. At this time we could see the reflected beam was successfully kicked away by the Faraday of 532 nm.

* Koji went to ITMY chamber with a walkie-talkie and looked at the spot position. Then he told Rana and Kiwamu to go a right direction with the steering mirrors. At last we could see a green beam from ITM illuminating the ETM cage.

* We excited the ITMY with f=2Hz vertically and aligned the ITM from medm. Also we recovered a video monitor which was abandoned around ETMY chamber so that we could see the spot on the ETM via the monitor. Seeing that monitor we aligned the ITM and we obtained the reclection from the ITM at the end table.

* We also tried to match the mode by moving a lens with f=400mm, but we couldn't obtain a good spot size.

2917   Wed May 12 03:52:54 2010 KojiUpdateGreen LockingReflection from ETM and ITM !

I could not understand this operation. Can you explain this a bit more?

1) Get Max transmittion by rotating PBS_in and PBS_out.

2) Flip the Faraday 180 deg i.e. put the beam from the output port.

3) Rotate PBS_in to have the best isolation.

 Quote: * To get a good isolation with the Faraday we at first rotated the polarization of the incident beam so to have a minimum transmission. And then we rotated the output polarizer until the transmission reaches a minimum. Eventually we got the transmission of less than 1mW, so now the Faraday should be working regardless of the polarization angle of the incident beam. As we predicted, the output polaerizer seems to be rotated 45 deg from that of the input.

2919   Wed May 12 09:16:29 2010 steveUpdateGreen LockingReflection from ETM and ITM !

Now I know why Rana was wearing his bright green pants yesterday. It is nice to see the green beam in the 40m IFO again. It calls for celebration!

I stopped AWG 1Hz drive of ITMYs (south-arm) I still see unblocked beams at the ETMYs table. We have plenty of cleaned razor beam traps to be used. Please block Faraday rejects etc

2930   Fri May 14 08:18:46 2010 steveUpdateGreen LockingReflection from ETM and ITM !

I stopped AWG  1 Hz drive to ITMYs. ITMXe was also driven or oscillating. ITMXe damping was off, so I turned it on. It did not effect it's oscillation

Attachment 1: itmx1hzos.jpg
1191   Tue Dec 16 19:06:01 2008 YoichiUpdatePSLReference cavity ring down repeated many times
Today, I repeated the reference cavity ring down measurement many times to see how much the results vary.

I repeated the ring down for 20 times and the first attachment shows the comparison of the measured and estimated cavity transmission power.
The blue curve is the measured one, and the red curve is the estimated one. There are only 10 plots because I made a mistake when transferring data
from the oscilloscope to the PC, and one measurement data was lost.

The second attachment shows the histogram of the histogram of the estimated cavity pole frequencies.
I admit that there are not enough samples to treat it statistically.
Anyway, the mean and the standard deviation of the estimated frequencies are 47.6kHz and 2.4kHz.
Assuming a Gaussian distribution and zero systematic error, both of which are bold assumptions though, the result is 47.6(+/-0.6)kHz.

Now I removed the Pockels Cell from the RC input beam path.
I maximized the transmission by tweaking the steering mirrors and rotating the HWP.
Since the transmission PD was saturated without an ND filter on it, I reduced the VCO RF power slider to 2.85.
Accordingly, I changed the nominal common gain of the FSS servo to 10.5dB.
Attachment 1: RC_Ringdown_Estimates.png
Attachment 2: Cavity_Pole_Histogram.png
1190   Fri Dec 12 22:51:23 2008 YoichiUpdatePSLReference cavity ring down measurement again
Bob made new HV-cables with HV compatible coaxes. The coax cable is rated for 2kV, which was as high as Bob
could found. I used it with 3kV hoping it was ok.
I also put a series resistor to the pockels cell to tame down the ripples I saw in elog:1136.

Despite those efforts, I still observed large ringings.
I tried several resistor values (2.5k, 1k, 330ohm), and found that 330ohm gives a slightly better result.
(When the resistance is larger, the edge of the PBS Refl. becomes dull).
Since the shape of the ringing does not change at all even when the pulse voltage is lowered to less than 1kV,
I'm now suspicious of the DEI pulser.

Anyway, I estimated the cavity pole using the MATLAB's system identification toolbox again.
This time, I locked the reference cavity using only the PZT feedback, which makes the UGF about a few kHz.
So, within the time scale shown in the plot below, the servo does not have enough time to respond, thus the laser
frequency stays tuned with the cavity. This was necessary to avoid non-linear behavior of the transmitted power
caused by the servo disturbing the laser frequency. With this treatment, I was able to approximate the response of
the cavity with a simple linear model (one pole low-pass filter).

MATLAB estimated the cavity pole to be 47.5kHz.
The blue curve in the plot is the measured RC transmitted power.
The incident power to the cavity can be inferred from the inverse of the red curve (the PBS reflection power).
The brown curve is the response of the first order low-pass filter with fc=47.5kHz to the input power variation.
The blue and brown curves match well for the first 10usec. Even after that the phases match well.
So the estimated 47.5kHz is probably a reasonable number. I don't know yet how to estimate the error of this measurement.

According to http://www.ligo.caltech.edu/~ajw/PSLFRC.png the designed transmission of the reference cavity mirrors is 300ppm (i.e.
the round trip loss (RTL) is 600ppm).
This number yields fc=35kHz. In the same picture, it was stated that fc=38.74kHz (I guess this is a measured number at some point).
The current fc=47.5kHz means, the RTL has increased by 200ppm from the design and 150ppm from the time fc=38.74kHz was measured.
Attachment 1: RC-Ringdown.png
1136   Fri Nov 14 19:20:42 2008 YoichiUpdatePSLReference cavity ring down
Thanks to Bob making the high-voltage BNC cables for the HV pulse generator, I was able to operate the EOM in front of
the reference cavity.

The conceptual setup is the following:
[HV pulse] ----+           +-->-- [PD2]
V           |
->--[HWP]->-- [EOM] -->-- [PBS] --<->-- [QWP] --<->-- [Reference Cavity] -->-- [PD1]
|
[PD3] --<--+


The high voltage pulse rotates the polarization of the light after the EOM. When the HV is applied, the PBS reflects most of the light
into PD2 (Thorlabs PDA255), shutting down the incident light into the cavity.
The transmitted light power of the reference cavity is monitored by PD1 (PDA255). The reflected light from the reference cavity
is monitored by the DC output of the RF PD (PD3). PD3 is low-passed so the response is not fast.
Thorlabs says PDA255 has 50MHz bandwidth.

The attached plot shows the time series of the above PD signals when the HV was applied.
Input Pulse (blue curve) is the input to the HV pulse generator. When it is high, the HV is applied.
"PBS reflection" (red) is PD2. "Reflection" (green) is PD3. "Transmission" (light blue) is PD1.

The red curve shows huge ringing. At first I thought this was caused by the bad response of the PD.
However, the same ringing can be seen in the PD3 and the peaks match very well.
When red curve goes down the green curve goes up, which is consistent with the energy conservation.
So it looks like the light power is actually exhibiting this ringing.
May be the HV pulse is distorted and the voltage across the EOM is showing this ringing.
I will check the input voltage shape to the EOM using a high impedance probe, if possible.

The green curve shows a slow decay because it has a long time constant. It is not an actual
trend of the reflected light power.

The RC transmission power shows some peaks, probably due to the ringing in the input power.
So just fitting with an exponential would not give a good estimate of the cavity pole.
Even though, we should be able to de-convolute the frequency response of the reference cavity
from the input (red curve) and output (light blue curve) signals.
Attachment 1: RingDown.png
1137   Fri Nov 14 20:35:47 2008 ranaUpdatePSLReference cavity ring down
To make the DEI pulser make a fast pulse on the EO shutter EOMs, we had to make sure:

1) the cable had a high voltage rated dielectric. cheap dielectrics show the 'corona'
effect, especially when there is a bend in the cable.

2) the EO has to have a resistor on it to prevent ringing due to the impedance mismatch.

3) We needed ~3.5 kV to get the EO shutter crystal to flip the light by 90 deg.
1138   Fri Nov 14 22:40:51 2008 YoichiUpdatePSLReference cavity ring down

 Quote: To make the DEI pulser make a fast pulse on the EO shutter EOMs, we had to make sure: 1) the cable had a high voltage rated dielectric. cheap dielectrics show the 'corona' effect, especially when there is a bend in the cable.

I'll check it with Bob.

 Quote: 2) the EO has to have a resistor on it to prevent ringing due to the impedance mismatch.

Did you use a shunt or series resistor ?
If shunt, I guess it has to have a huge heat sink.
Actually, DEI says the pulser does not require any external shunt/series resistors or impedance-matching network.
Looks like it is not true ...

 Quote: 3) We needed ~3.5 kV to get the EO shutter crystal to flip the light by 90 deg.

Yes, I adjusted the voltage to maximize the power change and it was about 3.5kV.
1140   Mon Nov 17 15:07:06 2008 YoichiUpdatePSLReference cavity ring down
I used MATLAB's system identification tool box to estimate the response of the reference cavity, i.e. cavity pole.
What I did was basically to estimate a model of the RC using the time series of the measured input and output power.

First, I prepared the input and output time series for model estimation.
The input is the input power to the RC, which I produced by inverting the PBS reflected light power and adding an offset
so that the signal is zero at t=0. Offset removal was necessary to make sure that the input time series does not give an
unintentional step at t=0.
The output time series is the transmission power of the RC. I also added an offset to make it zero at t=0.
Then I commanded MATLAB to compute the response of a first order low-pass filter to the input and try to fit
the computed response to the measured output by iteratively changing the gain and the cut-off frequency.
("pem" is the name of the command to use if you are interested in).

The result is shown in the attachment.
Blue curve is the input signal (I added a vertical offset to show it separately from the output).
The green curve is the measured output (RC transmission). The red curve is the response of the estimated model.
The estimated cut-off frequency was about 45kHz.

You can see that the red curve deviates a lot from the green curve after t=15usec.
By looking at this, I realized that the bandwidth of the RC cavity servo was too high.
The time scale we are looking at is about 50kHz whereas the FSS bandwidth is about 400kHz.
So when the input light was cut off, the error signal of the FSS becomes meaning less and the
input laser frequency was quickly moved away from the resonance. This is why the green curve does not
respond to the large peaks in the blue curve (input). The cavity was already off-resonance when the input power
showed bumps.

Since the red curve matches nicely with the green curve at the very beginning of the ring down, the estimated 45kHz
cavity pole is probably not that a bad estimate.

To make a better measurement, I will try to reduce the bandwidth of the RC servo by using only the PZT actuator.
If there were no ringing in the input light power, we wouldn't have to worry about the bandwidth of the servo because our
feedback is all made to the laser, not the cavity length.
In order to reduce the ringing in the input power, I asked Bob to make new HV cables using HV grade coax cables.
Attachment 1: Fit.png
1915   Mon Aug 17 02:05:49 2009 Yoichi,ranaUpdatePSLReference cavity reflection looks bad
Rana, Yoichi

It has been a well known fact that the reference cavity reflection beam looks ugly.

We measured the visibility of the RC by locking and unlocking it.
Comparing the reflected beam powers, we got the visibility of 0.46,

The beam going into the RC looks fine (circular on a sensor card).
However, the beam reflected back from the RC is distorted into a
horizontal ellipse, even when the RC is not locked.

We took a picture of the reflected beam hitting a white paper with the
infrared camera (see the attachment). It looks like two overlapping
circles horizontally separated. Could it be a badly coated optics
producing a secondary reflection ?

We looked into the RC's front mirror with an inspection mirror, but we
could not identify any obstructing object.

Rana is now touching the RC alignment.

We plan to remove the periscope before the RC to have a better look
into the cavity for inspection.

Late breaking update:
- We also moved the Refcav reflection camera to look at the leakage through a reflection steering mirror so that there's less chance of distortion. There was previously a W1 window in there as a pickofff. Also changed the camera to autogain so that we can see something.

- Re-aligned onto the refl pd.

- Tweaked alignment into RC. Mainly in yaw. Transmission went from 5V to 7V. In your face, Aso!
Attachment 1: P8170113.JPG
Attachment 2: Untitled.png
1917   Mon Aug 17 04:16:13 2009 YoichiUpdatePSLReference cavity reflection looks bad

 Quote: Rana, Yoichi - We also moved the Refcav reflection camera to look at the leakage through a reflection steering mirror so that there's less chance of distortion. There was previously a W1 window in there as a pickofff. Also changed the camera to autogain so that we can see something. - Re-aligned onto the refl pd. - Tweaked alignment into RC. Mainly in yaw. Transmission went from 5V to 7V. In your face, Aso!

After our removal of the pick off window and Rana's re-alignment of the beam into the RC, the RC optical gain increased.
FSS was complaining about it by driving the PC feedback crazy.
I reduced the nominal common gain from 12.5dB to 11dB.
1018   Wed Oct 1 23:21:03 2008 YoichiConfigurationPSLReference cavity reflection camera
I re-centered the reference cavity reflection camera, which has been mis-aligned for a while.
I also tweaked an input steering mirror to make the alignment better. This resulted in the increase of the transmission PD voltage
from 8V to 9V.
1956   Thu Aug 27 13:42:08 2009 ranaSummaryPSLReference Cavity Temperature Control: psl.db changes

I made the changes to the psl.db to handle the new Temperature box hardware. The calibrations (EGUF/EGUL) are just copied directly from the LHO .db file (I have rsync'd their entire target area to here).

allegra:c1psl>diff psl.db~ psl.db 341,353d340 < grecord(ai,"C1:PSL-FSS_TIDALOUT") < { <       field(DESC,"TIDALOUT- drive to the reference cavity heater") <       field(DISV,"1") <         field(SCAN,".5 second") <       field(DTYP,"VMIVME-3113") <       field(INP,"#C0 S28 @") <       field(EGUF,"10") <       field(EGUL,"-10") <       field(EGU,"volts") <       field(LOPR,"-10") <       field(AOFF,"0") < } 493,494c480,481 <         field(EGUF,"285.675") <         field(EGUL,"-214.325") --- >         field(EGUF,"67.02") >         field(EGUL,"7.96") 508,509c495,496 <         field(EGUF,"726.85") <         field(EGUL,"-1273.15") --- >         field(EGUF,"75.57") >         field(EGUL,"12.31") 531,532c518,519 <         field(EGUF,"726.85") <         field(EGUL,"-1273.15") --- >         field(EGUF,"75.57") >         field(EGUL,"12.31") 605,617d591 < grecord(ai,"C1:PSL-FSS_TIDALINPUT") < { <       field(DESC,"TIDALINPUT- tidal actuator input") <       field(DISV,"1") <         field(SCAN,".5 second") <       field(DTYP,"VMIVME-3123") <       field(INP,"#C0 S3 @") <       field(EGUF,"10") <       field(EGUL,"-10") <       field(EGU,"volts") <       field(LOPR,"-10") <       field(AOFF,"0") < } 1130a1105,1130 > grecord(ai,"C1:PSL-FSS_TIDALINPUT") > { >       field(DESC,"TIDALINPUT- tidal actuator input") >       field(DISV,"1") >         field(SCAN,".5 second") >       field(DTYP,"VMIVME-3123") >       field(INP,"#C0 S3 @") >       field(EGUF,"10") >       field(EGUL,"-10") >       field(EGU,"volts") >       field(LOPR,"-10") >       field(AOFF,"0") > } > grecord(ai,"C1:PSL-FSS_TIDALOUT") > { >       field(DESC,"TIDALOUT- drive to the reference cavity heater") >       field(DISV,"1") >         field(SCAN,".5 second") >       field(DTYP,"VMIVME-3113") >       field(INP,"#C0 S28 @") >       field(EGUF,"10") >       field(EGUL,"-10") >       field(EGU,"volts") >       field(LOPR,"-10") >       field(AOFF,"0") > } 1143,1144c1143,1144 <         field(HOPR,"0.010") <         field(LOPR,"-0.010") --- >         field(HOPR,"2") >         field(LOPR,"0")

1954   Wed Aug 26 19:58:14 2009 Rana, AlbertoUpdatePSLReference Cavity Temperature Control: MINCO PID removed

Summary: This afternoon we managed to get the temperature control of the reference cavity working again.

We bypassed the MINCO PID by connecting the temperature box error signal directly into EPICS.

We couldn't configure the PID so that it worked with the modified temperature box so we decided to just avoid using it.

Now the temperature control is done by a software servo by using the channel C1:PSL-FSS_MINCOMEAS as error signal and driving C1:PSL-FSS_TIDALSET (which we have clip-doodle wired directly to the heater input).

We 'successfully' used ezcaservo to stabilize the temperature:

ezcaservo -r C1:PSL-FSS_MINCOMEAS -s 26.6 -g -0.00003 C1:PSL-FSS_TIDALSET

We also recalibrated the channels:

C1:PSL-FSS_RMTEMP

C1:PSL-FSS_RCTEMP

C1:PSL-FSS_MINCOMEAS

with Peter King on the phone by using ezcawrite (EGUF and EGUL) but we didn't change the database yet. So please do not reboot the PSL computer until we update the database.

More details will follow.

Attachment 1: rc.png
2742   Wed Mar 31 15:31:53 2010 steveUpdatePSLReference Cavity RF PD base upgraded

 Quote: Some more words about the RFAM: I noticed that there was an excess RFAM by unlocking the RC and just looking at the RF out with the 50 Ohm input of the scope. It was ~100 mVp-p! In the end our method to minimize the AM was not so sensible - we aligned the waveplate before the EOM so as to minimize the p-pol light transmitted by the PBS cube just ahead of the AOM. At first, this did not minimize the RFAM. But after I got angry at the bad plastic mounting of the EOM and re-aligned it, the AM seemed to be small with the polarization aligned to the cube. It was too small to measure on the scope and on the spectrum analyzer, the peak was hopping around by ~10-20 dB on a few second timescale. Further reduction would require some kind of active temperature stabilization of the EOM housing (maybe a good SURF project!). For the EOM mount we (meaning Steve) should replace the lame 2-post system that's in there with one of the mounts of the type that is used in the Mach-Zucker EOMs. I think we have spare in the cabinet next to one of the arms. After the RFAM monkeying, I aligned the beam to the RC using the standard, 2-mirror, beam-walking approach. You can see from the attached plot that the transmission went up by ~20% ! And the reflection went down by ~30%. I doubt that I have developed any new alignment technique beyond what Yoichi and I already did last time. Most likely there was some beam shape corruption in the EOM, or the RFAM was causing us to lock far off the fringe. Now the reflected beam from the reference cavity is a nice donut shape and we could even make it better by doing some mode matching! This finally solves the eternal mystery of the bad REFL beam (or at least sweeps it under the rug). At the end, I also fixed the alignment of the RFPD. It should be set so the incident angle of the beam is ~20-40 deg, but it was instead set to be near normal incidence ?! Its also on flimsy plastic legs. Steve, can you please replace this with the new brass ones?

Teflon feet removed and heavy brass-delrin pd base installed. Ref-cavity reflected light remains to be beautiful doughnut shape on camera.

Attachment 1: brspdbs.JPG
2732   Mon Mar 29 21:43:27 2010 AlbertoConfigurationPSLReference Cavity PD Noise Spectrum

[Rana, Alberto]

This evening we measured the noise spectrum of the reference cavity PD used in the FSS loop. From that we estimated the transimpedance and found that the PD is shot-noise limited. We also found a big AM oscillation in correspondence of the FSS modulation sideband which we later attenuated at least in part.

This plot shows the spectrum noise from the RF output of the photodetector.

(here you should be able to see an attached figure, if not it's probably becasue imagemagic has having problems with displaying png files)

The tall peak at 21.5 MHz is the AM modulation introduced by the EOM. It seems to be caused by a misalignment of the EOM which might be somehow modulating the polarization.
The mount in which the EOM sits is not very solid. We should change it with something similar to that of the other two EOMs in the Mach Zehnder.
By tightening down the plastic screws of the mount Rana reduced the amplitude of the AM modulation by 20dB.

The bump in both the dark and shot noise are in corrispondence of the resonance of the PD's electronics. As it appears, the electronics is not well tuned: the bump should coincide with the AM peak.

In the case of the dark noise spectrum, the bump is due to the thermal noise of the electronics. It's a good sign: it means that the electronics is good enough to be sensitive to it.

Transimpedance Estimate
As a "sanity check" we made an approximate estimate of the transimpedance to make sure that the PD is dominated by shot noise rather than other noises, ie electronic's noise.

1. Supposing that the laser beam hitting the PD was shot noise limited, we measured 1.1V at the DC output. That let us estimate the photocurrent at DC of 20mA, for a 50Ohm output impedance.
2. The shot noise for 20mA is 80 pA/rtHz
3. From the nosie spectrum, we measured 3e-7 v/rtHz at 21.5MHz
4. The impedance at RF is then Z_rf = 3e-7 V/rtHz / 80e-12 pA ~ 4000 Ohm
5. Since the RF path inside the PD has a gain of 10, the transimpedance is ~400Ohm, which is about as we (ie Rana) remembered it to be.
6. The PD seems to be working fine.
Attachment 2: 2010-03-29_FSS_PD_shotnoise_and_darknoise.png
2733   Tue Mar 30 06:37:32 2010 ranaConfigurationPSLReference Cavity PD Noise Spectrum

Some more words about the RFAM: I noticed that there was an excess RFAM by unlocking the RC and just looking at the RF out with the 50 Ohm input of the scope. It was ~100 mVp-p! In the end our method to minimize the AM was not so sensible - we aligned the waveplate before the EOM so as to minimize the p-pol light transmitted by the PBS cube just ahead of the AOM. At first, this did not minimize the RFAM. But after I got angry at the bad plastic mounting of the EOM and re-aligned it, the AM seemed to be small with the polarization aligned to the cube. It was too small to measure on the scope and on the spectrum analyzer, the peak was hopping around by ~10-20 dB on a few second timescale. Further reduction would require some kind of active temperature stabilization of the EOM housing (maybe a good SURF project!).

For the EOM mount we (meaning Steve) should replace the lame 2-post system that's in there with one of the mounts of the type that is used in the Mach-Zucker EOMs. I think we have spare in the cabinet next to one of the arms.

After the RFAM monkeying, I aligned the beam to the RC using the standard, 2-mirror, beam-walking approach. You can see from the attached plot that the transmission went up by ~20% ! And the reflection went down by ~30%. I doubt that I have developed any new alignment technique beyond what Yoichi and I already did last time. Most likely there was some beam shape corruption in the EOM, or the RFAM was causing us to lock far off the fringe. Now the reflected beam from the reference cavity is a nice donut shape and we could even make it better by doing some mode matching! This finally solves the eternal mystery of the bad REFL beam (or at least sweeps it under the rug).

At the end, I also fixed the alignment of the RFPD. It should be set so the incident angle of the beam is ~20-40 deg, but it was instead set to be near normal incidence ?! Its also on flimsy plastic legs. Steve, can you please replace this with the new brass ones?

Attachment 1: rc.png
2759   Sat Apr 3 11:35:47 2010 ranaConfigurationPSLReference Cavity PD Noise Spectrum

### The units on this plot are completely bogus - we know that the thermal noise from the resonant part of the circuit is just V = sqrt(4*k*T*Z) ~ 3nV/rHz. Then the gain of the MAX4107 stage is 10. The output resistor is 50 Ohms, which forms a divide by 2 with the input impedance of the spectrum analyzer and so the bump in the dark noise should only be 15 nV/rHz and not microVolts.

 Quote: [Rana, Alberto] This evening we measured the noise spectrum of the reference cavity PD used in the FSS loop. From that we estimated the transimpedance and found that the PD is shot-noise limited. We also found a big AM oscillation in correspondence of the FSS modulation sideband which we later attenuated at least in part. This plot shows the spectrum noise from the RF output of the photodetector.

2760   Sat Apr 3 16:07:40 2010 AlbertoConfigurationPSLReference Cavity PD Noise Spectrum

I was aware of a problem on those units since I acquired the data. Then it wasn't totally clear to me which were the units of the data as downloaded from the Agilent 4395A, and, in part, still isn't.

It's clear that the data was in units of spectrum, an not spectral density: in between the two there is a division by the bandwidth (100KHz, in this case). Correcting for that, one gets the following plot for the FSS PD:

Although the reason why I was hesitating to elog this other plot is that it looks like there's still a discrepancy of about 0.5dBm between what one reads on the display of the spectrum analyzer and the data values downloaded from it.

However I well know that, I should have just posted it, including my reserves about that possible offset (as I'm doing now).

Quote:

### The units on this plot are completely bogus - we know that the thermal noise from the resonant part of the circuit is just V = sqrt(4*k*T*Z) ~ 3nV/rHz. Then the gain of the MAX4107 stage is 10. The output resistor is 50 Ohms, which forms a divide by 2 with the input impedance of the spectrum analyzer and so the bump in the dark noise should only be 15 nV/rHz and not microVolts.

 Quote: [Rana, Alberto] This evening we measured the noise spectrum of the reference cavity PD used in the FSS loop. From that we estimated the transimpedance and found that the PD is shot-noise limited. We also found a big AM oscillation in correspondence of the FSS modulation sideband which we later attenuated at least in part. This plot shows the spectrum noise from the RF output of the photodetector.

3240   Fri Jul 16 20:25:52 2010 MeganUpdatePSLReference Cavity Insulation

Rana and I

1) took the temperature sensors off the reference cavity;

2) wrapped copper foil around the cavity (during which I learned it is REALLY easy to cut hands with the foil);

3) wrapped electrical tape around the power terminals of the temperature sensors (color-coded, too! Red for the out of loop sensor, Blue for the first one, Brown for the second, Gray for the third, and Violet for the fourth. Yes, we went with an alphabetical coding system, excluding the out of loop sensor);

4) re-wrapped the thermal blanket heater;

5) covered the ends of the cavities with copper, ensuring that the beam can enter and exit;

6) took pretty pictures for your enjoyment!

We will see if this helps the temperature stabilization of the reference cavity.

The end of the reference cavity, with a lovely square around the beam.

The entire, well-wrapped reference cavity!

3241   Fri Jul 16 23:53:27 2010 RanaUpdatePSLReference Cavity Insulation

From the trend, it seems that the Reference Cavity's temperature servo is working fine with the new copper foil. I was unable to find the insulating foam anywhere, but that's OK. We'll just get Frank to make us a new insulation with his special yellow stuff.

The copper foil that Steve got is just the right thickness for making it easy to form around the vacuum can, but we just have to have the patience to wrap ~5-10 more layers on there. We also have to get a new heater jacket; this one barely fits around the outside of the copper wrap. The one we have now seems to have a good heating wire pattern, but I don't know where we can buy these.

I also turned the HEPA's Variac back down to the nominal value of 20. Please remember to turn it back up to 100 before working on the PSL.

3280   Fri Jul 23 16:02:16 2010 RanaUpdatePSLReference Cavity Insulation

This is the trend so far with the copper foil wrapping. According to Megan's calculation, we need ~1 mm of foil and the thickness of each layer is 0.002" (1/20th of a mm), so we need ~20 layers. We have ~5 layers so far.

As you can see the out-of-loop temperature sensor (RCTEMP) is much better than before. We need another week to tell how well the frequency is doing -

the recent spate of power cycles / reboots of the PSL have interrupted the trend smoothness so far.

Attachment 1: Untitled.png
3282   Fri Jul 23 21:14:29 2010 RanaUpdatePSLReference Cavity Insulation

I wrapped another ~3 layers onto there. It occurs to me now that we could just get some 2mm thick copper plates made to fit over the stainless steel can.

They don't have to completely cover it, just mostly. I also took the copper circles that Steve had made and marked them with the correct beam height

and put them on Steve's desk. We need a 1" dia. hole cut into these on Monday.

To compensate for the cooling during my work, I've set the heater for max heating for 1 hour and then to engage the temperature servo.

I also noticed the HEPA VARIAC on the PSL was set to 100. Please set it back to 20 after completing your PSL work so that it doesn't disturb the RC temperature..

1923   Tue Aug 18 14:24:43 2009 YoichiSummaryPSLReference Cavity Inspection
Rana, Koji, Yoichi

To see why the reflected beam from the RC is distorted, we took out
the periscope and the iris in front of the RC. The periscope mirrors
had some gunk and dusts on them. We blew nitrogen air onto them to
remove the dust. Since the gunk did not come off with the air, we
wrapped a Q-tip with lens cleaning paper soaked in Methanol, and wiped
the surface of the mirrors. We did this because it was hard to remove
the mirrors from the periscope (they were in a spring loaded mirror
holders. The springs were too strong to safely remove them without
damaging the mirrors).

Looking into the RC from the front mirror revealed nothing obstructing
in the path.

After the cleaning, we put the periscope back and observed the direct
reflection from the cavity (not locked). It was still distorted
exactly like before.

So we did some tests.
First we injected He-Ne to the RC. It turned out that multiple
reflections from the optical window (not AR coated for He-Ne) made it
almost impossible to investigate anything with He-Ne. But this
observation made us to suspect maybe one side of the window is not AR
coated.

We placed the periscope about 50cm away from the RC and injected the
beam from an angle, so that we can observe the direct reflection.

First, we checked the shape of the beam leaving the periscope. It was good.
We then observed the reflected beam from the RC. It was also good, no distortion.
We made sure that it was really the reflection from the mirror, not from the window
as follows.
We measured the separation between the in coming beam to the cavity and the reflected beam
at two locations. From this, we can guess where the two beams intersect (the reflection point).
The estimated reflection point was far inside the RC enclosure, indicating that it was really
reflection from the front mirror of the RC.
Since we did not see any other reflection beam, we concluded that the AR coating of the window
is good.

We checked the direct reflection beam shape with several different incident angles, but the
beam shape was always good.

We put back the periscope to the original position. This time, we put a high reflectivity mirror
after the output mirror of the periscope. The beam coming out of the circulator (PBS) had a good
circular shape. But still if we let the beam reflected by the cavity, the beam shape is distorted.
Something must be happening in the RC. Unfortunately, we could not figure out what it is.

We put everything back to the original configuration, except for the iris, and the RC alignment
was already good (surprise). After Koji's final tweak, the FSS is now doing fine, but still
the reflected beam is ugly.
1001   Fri Sep 26 19:08:43 2008 ranaConfigurationPSLRefcav Trans: PD + Camera + Dumps
I went out to improve the Refcav trans path.

I removed all ND filters to get rid of the fringing.

I removed the anodized Al dump that was there. Black anodized Aluminum dumps are forbidden for use as
dumps in any low phase noise setup (such as our frequency stabilization cavity). The scatter was going
directly back into the cavity and making noise. For now its undumped, but Steve will find the
reflections and dump them on unblemished razor blade dumps mounted stiffly.

I will post a photo of the new setup later - the new setup is sketched on the control room markerboard.

The transPD level is now 8 V, up from its previous 3-4 V. We will probably have to also put a lens
in front of it to get the beam size down.
12573   Wed Oct 19 18:32:25 2016 rana, yinziUpdatePSLRefCav thermal control: heater is dead

#### We wanted to re-activate the Heater for the reference cavity today to use it as a testbed for PID autotuning and the new heater driver circuit that Andrew is working on for the coating thermal noise experiment.

Unfortunately, it seems that the large power supply which is used for the heater is dead. Or maybe I don't remember how to use it?

The AC power cord was plugged in to a power strip which seems to work for IO chassis. We also tried swapping power strip ports.

We checked the front panel fuses. The power one was 3 Ohms and the 'bias' one was 55 Ohms. We also checked that the EPICS slider did, in fact, make voltage changes at the bias control input.

Non of the front panel lights come on, but I also don't remember if that is normal.

Have those lights been dead a long time? We also reconnected the heater cable at the reference cavity side.

5072   Sat Jul 30 20:41:50 2011 ranaUpdatePSLRefCav Stabilization back on

I turned the RefCav heater and servo back on a couple days ago. At first it was stabilizing again at a low setpoint, but in reality the right temperature (~40 C). After fixing the in-loop signal offsets, the setpoint now correctly reflects the actual temperature.

Jenny is going to calibrate the sensors using some kind of dunking cannister next week.

1850   Thu Aug 6 23:29:47 2009 JenneUpdatePSLRef cav reflection PD is funky

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?

1851   Fri Aug 7 00:10:14 2009 ranaUpdatePSLRef cav reflection PD is funky

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.

1860   Fri Aug 7 17:05:34 2009 JenneUpdatePSLRef cav reflection PD is funky

 Quote: 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.

1847   Thu Aug 6 18:26:26 2009 JenneUpdatePSLRef Cav and PMC aligned

[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.

741   Fri Jul 25 19:57:18 2008 JenneUpdatePSLRef Cav & PMC
"PMC is in, but is still being worked on. Leave it alone." ---Rana

Ref. Cavity is locked again. Still a work in progress. I think we're ready to mode match on Monday. ---Jenne
ELOG V3.1.3-