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.
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.
(Report on Aug 12, 2022)
We went around the lab for the final check. Here are the additional notes.
I declare that now we are ready for the power outage.
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 ---
--- Suspending the mirror ---
[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:
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.
" We found that IPANG was not on its photodiode, but determined that it was centered on all of the in-vac mirrors, and that it was just a little bit of steering on the ETMY end out-of-vac table that needed to be done."
Manasa took photos of all test mass chambers and the BS chamber, so we can keep up-to-date CAD drawings.
Oplevs and IPPOS/IPANG are being centered as I type. Manasa and Ayaka are moving the lens in front of IPANG such that we have a slightly larger beam on the QPD.
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.
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...
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.
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:
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.
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.
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.
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):
We when last hand measured distances, after moving PR2, we found:
However, when I looked at the sideband splitting interferometrically, I found:
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?
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
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:
This means that:
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)
Measured arm reflectivity R_cav: 0.875 +/- 0.005
Estimated round trip loss L_RT: 157ppm +/- 8ppm
Estimated finesse F: 1213+/-2
Measured arm reflectivity R_cav: 0.869 +/- 0.006
Estimated round trip loss L_RT: 166ppm +/- 8ppm
Estimated finesse F: 1211+/-2
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.
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.
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.
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.
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.
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.
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!
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.
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.
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..
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.
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?