• We installed the spare summing node (the prototype which has no serial number) and are using it now, with IN1 enabled on both channels with 0dB gain and polarity ON. 
• We reduced the whitening gain on ASAIR 45 to 6 dB (from 12dB) because the ADC was sometimes saturating causing lock losses when we transitioned DARM to this sensor. 
• We increase the MICH trigger threshold to 40, this has made DRMI lock acquisition with the arms locked on ALS considerably faster. 
• We spent some time on the ALS find resonance, more details latter. 
• We made measurements of the DRMI loop gains at a CARM offset of 30 pm.  We found we had to reduce the PRCL gain by 30% to get the UGF to 70 Hz at this offset, and the SRCL gain by a factor of 2 to get a ugf of 40 Hz.  This is now in the guardian. This change means that we are able to go to a arm build up 100 times higher than the single arm (roughly 20pm CARM stably).  
• We found that when we tried to go to a lower CARM offset, the DHARD loop became unstable and caused us to loose lock.  We are now reducing the gain by a factor of 2, and then manually turning it off.  (For the record, we are running ASC loops to the BS, PRM, and DHARD durring the CARM offset reduction right now.)
• We now see that the recycling gain is lower than it should be, which could be because our alignment is not good.  It might be helpfull to commision some ASC for CHARD and SRM.  We have seen that at around 130 times the single arm transmission, REFL DC is reduced by about 50%, and refl 9 I is coming into the linear range. 
• We have also made various changes to our guardians that should make the locking sequence more robust, like reloading the LSC matrix when it fails, checking if the PSL rotation stage gives us the wrong input power, and actually checking the IR in the CHECK_IR state instead of relying on a person to check it.

ALS IR search

This morning Matt and I did some debugging of the new ALS COMM FIND_FSR, this now works OK as long as the hard coded magic numbers are close to the resonance locations.  Latter this evening, this became untrue, so we added the FINE_TUNE_IR state in again, which was removed last week.  This is a slow search, and doesn't always work.  We could fine tune the parameters to make this better, but we should also find a way of saving the location of the frequency were the last resonance was found, instead of relying on the hard coded offsets.  COMM could also be improved by not discarding the information about any resonances it passes through in searchstate 0. 

The DIFF FIND_IR_BETTER wasn't working, it was actually checking only one of the hard coded offsets (twice).  We fixed this, so now it checks the whole list of hard coded numbers. These numbers also became inaccurate latter in the evening, and when FIND_IR_BETTER tries to search, it always drops the lock.  We reverted to our old FIND_IR instead of trying to debug this. 

These two pieces of code always seem to work for a while after someone has updated the hard coded offsets, but we haven't yet come up with something that is robust to drifts in the frequency. 

We were locked at -11 to -13 sqrt(TRX+TRY) for about 20 minutes (with DHARD off) before we turned DHARD on and lost it at 10:36 UTC December 2nd.