[Yuta, Jenne]

Vaguely chronological order:

Found a beat peak, thought it was puny, went to realign Ygreen at end table.

Noticed that beam out of faraday was clipping on the last lens before the steering optics.  We adjusted the mirror directly before the faraday, making sure the power transmitted (measured by the Ophir) didn't go down. Now we're roughly centered on both the lens directly after the faraday, and the lens before the steering optics.

This, of course, meant that we had to completely realign the Ygreen beam to find the TEM00 resonance.  We did that.  Actually, this took us a really long time. We ended up putting a temporary CCD camera on the PSL table to look at the transmitted green light.  This helped a lot, but the resonant modes were just totally wacky.  We finally were able (after 30+ minutes, using the camera) to get to TEM01.  Then Yuta adjusted ITMY a teeny bit, and green was happy to resonate.  We then removed the CCD camera so that we could move on to beat stuff.

Yuta decided it's faster to sweep the PSL temp, rather than the end laser temp, since we don't have to watch that the arm maintains lock.  So we set the end laser temp (T+) to 34.049C, which gave a measured temperature at the back of 34.68C (with an offset of 29425)

We then swept the SLOW adjust on the FSS screen to change the PSL temp.  We went all the way, starting at 0, to +10, back to 0, then on to -10, in steps of 0.01 .

We found a puny peak at -0.96, and pretty good peak at -9.48.  Height of the pretty good peak, after optimizing PSL table beat alignment was -50dBm. At this time, the PSL temp is 33.81C, while the Yend is still measured at 34.68C.

I checked the cabling, and it looks like the beat setup is still as it should be, using the old-school, non-beatbox stuff.  We plugged the beat PD into the beat detection setup, removing it from the spectrum analyzer.  As mentioned in my self-reminder elog, I changed the gains on the top 2 SR560's down by a factor of 2 so they weren't overloading. 

We aren't really sure that we're getting any real signals into the ALS model though.  C1:ALS-BEATY_COARSE_I_MON seems to be the same whether or not the arm is locked on green, therefore it seems to be the same ~500 or 600 counts whether or not there is a beat.  Hmmmm. We used the offset option of the OFFSETTER2 to send an offset to the beat signal that gets sent to the ETMY.  We confirmed that signals are going out to ETMY from the ALS model, but we're not sure if they are correct / non-insane signals.  One symptom that we're seeing is even though we have the Yarm locked on green, and the ALS system engaged, the arm is still flashing in IR, which means the green is mostly just following the arm.  We're not actually holding the arm in place.

Also, TRY and TRX are not recorded channels, so I went into the .ini file to have them acquire (uncommented them, set acquire=1, set the data rate to 2048), saved the ini file, and restarted the fb's daqd process.  The new TRY_OUT_DQ channel is digital zeros, and is red in dataviewer.  Also, the lsc model is no longer happily connected to the framebuilder.  I then decided to try Joe's old .daqconfig script (in the scripts directory) which provides a gui for acquiring channels.  Restarted the daqd process, same story.  I then went back to comment out the TRY_OUT_DQ lines, set acquire=0, set data rate back to 16384.  Joe's program put a bunch of spaces into the .ini file, but I don't think they do anything bad.  Except that now when I restart daqd, lsc still won't connect to the framebuilder.  Yuta setup pynds to save the data, if we were able to get anything useful.

We couldn't make awg, tdssine, or DTT write anything to the OFFSETTER2_EXC.  This is annoying, because this is how (once we figure everything else out) we need to sweep (with a ramp or triangle) the beat signal.

Moral of the night: we learned some stuff, but ultimately failed.