Dead again. No outputs for the past month. We really need a cron job to check this out rather than wait for someone to look at the web page.

MC unlocked, Autolocker waiting for c1iool0 EPICS channels to respond. c1iool0 was responding to ping, but not to telnet. Keyed the crate and its coming back now.

There's many mentions of c1iool0 in the recent past, so it seems like its demise must be imminent. Good thing we have an Acromag team on top of things!

Also, the beam on WFS2 is too high and the autolocker is tickling the Input switch on the servo board too much: this is redundant / conflicting with the MC2 tickler.

The WFS gains are supposedly maximized already. If we remotely try to increase the gain, the two MAX4106 chips in the RF path will oscillate with each other.

We should insert a bi-directional coupler (if we can find some LEMO to SMA converters) and find out how much actual RF is getting into the demod board.

Koji responding to Rana

> For the rough calibration below 10 Hz, we can use the SUS OSEM cal: the SUSPIT and SUSYAW error signals are in units of micro-radians.

I can believe the calibration for the individual OSEMs. But the input matrix looked pretty random, and I was not sure how it was normalized.
If we accept errors by a factor of 2~3, I can just naively believe the calibration factors.

> If the RF signals at the demod input are low enough, we can consider either increasing the light power on the WFS or increasing the IMC mod. depth.

The demod chip has the conversion factor of about the unity. We increased the gains of the AF stages in the demod and whitening boards. However, we only have the RMS of 1~20 counts. This means that we have really small RF signals. We should check what's happening at the RF outputs of the WFS units. Do we have any attenuators in the RF chain? Can we skip them without making the WFS units unstable?

• For the rough calibration below 10 Hz, we can use the SUS OSEM cal: the SUSPIT and SUSYAW error signals are in units of micro-radians.
• It seems from the noise plots that the demod board is now dominating over the whitening board noise.
• If the RF signals at the demod input are low enough, we can consider either increasing the light power on the WFS or increasing the IMC mod. depth.
• We should look at the out-of-lock light power on the WFS and re-examine what the 'safe' level is. We used to do this based on the dissipated electrical power (bias voltage x photocurrent).

At Hanford, there is this issue with laser jitter turning into an IMC error point noise injection. I wonder if we can try out taking the acoustic band WFS signal and adding it to the MC error point as a digital FF. We could then look at the single arm error signal to see if this makes any improvement. There might be too much digital delay in the WFS signals if the clock rate in the model is too low.

Sus damping restored.

It didn't go crazy at least for the past 24hours.

Now, the output matrices in the previous entry were implemented.
The WFS servo loops have been engaged for several hours.
So far the REFL and TRANS look straight. Let's see how it goes.

Signal transfer function measurements

C1:SUS-MC*_ASCPIT_EXC channels were excited for swept sine measurements.

The TFs to WFS1-I1~4, Q1~4, WFS1/2_PIT/YAW, MC2TRANS_PIT/YAW signals were recorded.

The MC1 and MC3 actuation seems to have ~30Hz elliptic LPF somewhere in the electronics chain.
This effect was compensated by subtracting the approximated time delay of 0.022sec.

The TFs were devided by freq^2 to make the response flat and averaged between 7Hz to 15Hz.
The results have been summarized in Attachment 3&4.

Attachment 4 has the signal sensing matrix. Note that this matrix was measured with the input gain of 0.1.

Input matrix for diagonalizing the actuation/sensor response

Pitch

e.g. To produce pure WFS1P reaction, => -1.59 MC1P + 0.962 MC2P + 0.425 MC3P

Yaw

WFS1 / WFS2 demod phases and WFS signal matrix

Noise analysis of the WFS error signals.

Attachment 1: All error signals compared with the noise contribution measured with the RF inputs or the whitening inputs terminated.

Attachment 2: Same plot for all the 16 channels. The first plot (WFS1 I1) shows the comparison of the current noise contributions and the original noise level measured with the RF terminated with the gain adjusted along with the circuit modification for the fair comparison. This plot is telling us that the electronics noise was really close to the error signal.

I wonder if we have the calibration of the IMC suspensions somewhere so that I can convert these plots in to rad/sqrtHz...?

Valve configuration: vacuum normal

RGA head temp: 43.5 C

Vac envelope temp: 23 C

- Updated the circuit diagrams:

IMC WFS Demodulator Board, Rev. 40m https://dcc.ligo.org/LIGO-D1600503

IMC WFS Whitening Board, Rev. 40m https://dcc.ligo.org/LIGO-D1600504

- Measured the noise levels of the whitening board, demodboard, and nominal free running WFS signals.

- IMC WFS demod phases for 8ch adjusted

Injected an IMC PDH error point offset (@1kHz, 10mV, 10dB gain) and adjusted the phase to have no signal in the Q phase signals.

- The WFS2 PITCH/YAW matrix was fixed

It was found that the WFS heads were rotated by 45 deg (->OK) in CW and CCW for WFS1 and 2, respectively (oh!), while the input matrices were identical! This made the pitch and yaw swapped for WFS2. (See attachment)

- Measured the TFs MC1/2/3 P/Y actuation to the error signals

PMC and IMC were aligned on Friday (16th) and Today (19th).

The PD and lens for the ringdown experiment were removed as they were blocking the WFS.

https://dcc.ligo.org/LIGO-D1400414

As it turns out, its not so old as I thought. Jenne and I reworked these in 2014-2015. The QPD whitening is the same as the IMC WFS whitening so we can just repeat those fixes here for the IMC.

I looked into converting the QPD whitening switches for the X end to Acromag.

• To test this out and be able to freely toggle filters without messing anything up, I added a temporary dummy cdsFiltCtrl module (ACROMAG_BIO_TEST) to the c1scx model.
• The filters can be toggled from the automatically generated medm screen medm/c1scx/C1SCX_ACROMAG_BIO_TEST.adl
• The control output of the dummy filter bank is sent to a channel named C1:SCX-ACROMAG_SWCTRL.
• I was able to read in the appropriate bits from there and send them to the appropriate acromag channel using a calcout channel.
  • I couldn't get individual bo channels to work. This Acromag module is configured to write to 4 channels at a time, so I set that up with an analog output channel. The calcout channel shifts each relevant bit from C1:SCX-ACROMAG_SWCTRL to the right place for writing to the Acromag. 
• I connected the Acromag XT1111 Binary I/O unit to a temporary power supply and verified that toggling the filters on and off changed the output appropriately. This is a sinking output model so the output pin is connected to the return if the switch is on. 

The plan from here:

• Determine how to configure these outputs to be compatible with the QPD whitening board.
• Modify the SUS PD whitening board to always use the analog filter and remove digital option in models.
• Test DACs 
• Verify that the QPD whitening gain switches aren't doing anything
• Assemble new Acromag box for X end and connect to QPD whitening, SUS PD whitening and SOS driver boards

Rana pointed out that this modification (removal of 900Ohm) leave the input impedance as low as 100Ohm.
As OP284 can drive up to 10mA, the input can span only +/-1V with some nonlinearity.

Rather than reinstalling the 900Ohms, Rana will investigate the old-days fix for the whitening filter that may involve the removal of AD602s.
Until the solution is supplied, the IMC WFS project is suspended.

Mach Zucker on howto do Ringdowns:  https://dcc.ligo.org/LIGO-T900007

No damage. ITMY is glitching, so it has not been damped.

The transients are likely due to doppler interference due to the input laser frequency sloshing due to errant control signals after the IMC unlock. I performed a few "partial" ringdowns by reducing the power by about 80% while keeping the IMC servo locked. (Function generator at 0.5Vpp square wave, 0.25V offet. Turned IMC boosts off to increase the stable range of the servo).

I need to work out how to extract the loss from this, I think having a partial ringdown may change the calculations somewhat; the time constants in the trans and refl signals are not identical.

Thanks to Gautams nice setup, it was very easy to take these measurements. Thanks! Code and data attached.

I have implemented the same modification (shorting the input resistor of AD602) to the two whitening boards.

The input resistor 909Ohm of AD602 was shorted. I've confirmed that the gain (= attenuation by voltage division) was increased by a factor of 10.
This modification was done for WFS2-I1 and WFS2-Q1. Also the thick film resistors for the WFS2-I1 channel was all replaced with thin film resistors.

Attachment 1 shows the comparison of the noise levels. The curves were all calibrated referred to the response of the original whitening filter configuration.
(i.e. measurement done after the gain change was compensated by the factor of 10.)

Now the AF chain is not limited by the noise in the whitening filter board. (Brown)
In fact, this noise level was completely identical between I1 and Q1. Therefore, I don't think we need this resistor replacement for the whitening filter board.

We can observe the improvement of the overall noise level below 10Hz. (Comparison between green and red/blue)
As the signal level goes up, the noise above 100Hz was also improved.

Now we need to take care of the n x 0.7Hz feature which is in the demod board...
 

The whitening board saids it is Rev B, but the actual component values are more like Rev. C.

The input stage (AD602) has an input resistor of 909 Ohm.
This is causing a big attenuation of the signal (x1/10) because the input impedance of AD602 is not high. And this screws up the logarithm of the gain.
I don't think this is a right approach.

I have implemented the modification to the demod boards (Attachment 1).
Now, I am looking at the noise in the whitening board. Attachment 2 shows the comparison of the error signal with the input of the whitening filter shorted and with the 50ohm terminator on the demodulator board. The message is that the whitening filter dominates the noise below 3Hz.

I am looking at the schematic of the whitening board D990196-B. It has an VGA AD602 at the input. I could not find the gain setting for this chip.
If the gain input is fixed at 0V, AD602 has the gain of 10dB. The later stages are the filters. I presume they have the thick film resistors.
Then they may also cause the noise. Not sure which is the case yet.

Also it seems that 0.7Hz noise is still present. We can say that this is coming from the demod board but not on the work bench but in the eurocard crate.

In an effor to see if I could narrow down the cause of the 100kHz ringing seen in the reflected PD signal, I tried a few things.

1. Changed the PD - there was a PDA 255 sitting on the PSL table by the RefCav. Since it wasn't being used, I swapped the PD I was using with this. Unfortunately, this did not solve the problem.
2. Used a different channel on the oscilloscope - ringing persisted
3. Changed BNC cable running from PD to oscilloscope - ringing persisted
4. Checked the spectrum of the PD under dark and steady illumination conditions for any features at 100kHz, saw nothing (as expected) 

I was working under the hypothesis that the ringing was due to some impedance mismatch between the PD output and the oscilloscope, and 4 above supports this. However, most documents I can find online, for example this one, recommend connecting the PD output via 50ohm BNC to a scope with input impedance 50ohms to avoid ringing, which is what I have done. But perhaps I am missing something.

Moreover, the ringdown in reflection actually supplies two of the five variables needed to apply the MIT method of loss estimation. I suppose we could fit the parameter "m4" from the ringdown in transmission, and then use this fitted value on the ringdown in reflection to see where the reflected power settles (i.e. the parameter "m3" as per the MIT paper). I will try analyzing the data on this basis.

I also measured the power levels at each of the PDs, these should allow us to calibrate the PD voltage outputs to power in Watts. All readings were taken with the Ophir power meter, with the filter removed, and the IMC locked.

The MC1 suspension troubles vanished as they came - but the IMC was remaining locked stably so I decided to do another round of ringdowns, and investigate this feature in the reflected light a bit more closely. Over 9 ringdowns, as seen in the below figure, the feature doesn't quite remain the same, but qualitatively the behaviour is similar.

Steve helped me find another PDA255 and so I will try switching out this detector and do another set of ringdowns later tonight. It just occurred to me that I should check the spectrum of the PD output out to high frequencies, but I doubt I will see anything interesting as the waveform looks clean (without oscillations) just before the trigger...

As promised, here is the more detailed elog.

Part 1: AOM alignment and diffraction efficiency optimization

I started out by plugging in the input to the AOM driver back to the DS345 on the PSL table, after which I re-inserted the 24V fuse that was removed. I first wanted to optimize the AOM alignment and see how well we could cut the input power by driving the AOM. In order to investigate this, I closed the PMC, unlocked the PSL shutter, and dialed the PSL power down to ~100mW using the waveplate in front of the laser. Power before touching anything just before the AOM was 1.36W as measured with the Coherent power meter. 

The photodiode (PDA255) for this experiment was placed downstream of the 1%(?) transmissive optic that steers the beam into the PMC (this PD would also be used in Part 2, but has since been removed)...

Then I tuned the AOM alignment till I maximized the DC power on this newly installed PD. It would have been nicer to have the AOM installed on the mount such that the alignment screws were more easily accessible, but I opted against doing any major re-organization for the time being. Even after optimizing the AOM alignment, the diffraction efficiency was only ~15%, for 1V to the AOM driver input. So I decided to play with the AOM driver a bit.

Note that the AOM driver is powered by 24V DC, even though the spec sheet says it wants 28V. Also, the "ALC" input is left unconnected, which should be fine for our purposes. I opted to not mess with this for the time being - rather, I decided to tweak the RF adjust potentiometer on the front of the unit, which the spec sheet says can adjust the RF power between 1W and 2W. By iteratively tuning this pot and the AOM alignment, I was able to achieve a diffraction efficiency of ~87% (spec sheet tells us to expect 80%), in a switching time of ~130ns (spec sheet tells us to expect 200ns, but this is presumably a function of the beam size in the AOM). These numbers seemed reasonable to me, so I decided to push on. Note that I did not do a thorough check of the linearity of the AOM driver after touching the RF adjust potentiometer as Koji did - this would be relevant if we want to use the AOM as an ISS servo actuator, but for the ringdown, all that matters is the diffraction efficiency and switching time, which seemed satisfactory. 

At this point, I turned the PSL power back up (measured 1.36W just before the AOM). Before this, I estimated the PD would have ~10mW power incident on it, and I wanted it to be more like 1mW, so I I put an ND 1.0 filter on to avoid saturation.

Part 2: PMC "ringdown"

As mentioned in my earlier elog, we want the PMC to cut the light to the IMC in less than 1us. While I was at it, I decided to see if I could do a ringdown measurement for the PMC. For this, I placed two more PDs in addition to the one mentioned in Part 1. One monitored the transmitted intensity (PDA10CF, installed in the old 3f cancellation trial beam path, ~1mW incident on it when PMC is locked and well aligned). I also split off half the light to the PMC REFL CCD (2mW, so after splitting, PMC CCD gets 1mW through some ND filters, and my newly installed PD (PDA255) receives ~1mW). Unfortunately, the PMC ringdown attempts were not successful - the PMC remains locked even if we cut the incident light by 85%. I guess this isn't entirely surprising, given that we aren't completely extinguishing the input light - this document deals with this issue.... But the PMC transmitted intensity does fall in <200ns (see plot in earlier elog), which is what is critical for the IMC ringdown anyways. So I moved on.

Part 3: IMC ringdown

The PDA10CF installed in part 2 was left where it was. The reflected and transmitted light monitors were PDA255. The former was installed in front of the WFS2 QPD on the AS table (needed an ND1.0 filter to avoid damage if the IMC unlocks not as part of the ringdown, in which case ~6mW of power would be incident on this PD), while the latter was installed on the MC2 transmission table. We may have to remove the former, but I don't see any reason to remove the latter PD. I also ran a long cable from the MC2 trans table to the vertex area, which is where I am monitoring the various signals.

The triggering arrangement is shown below.

To actually do the ringdown, here is the set of steps I followed.

1. Make sure settings on scope (X & Y scales, triggering) are optimized for data capture. All channels are set to 50ohm input impedance. The trigger comes from the "TTL" output of the DS345, whose "signal" output drives the AOM driver. Set the trigger to external, the mode should be "normal" and not "auto" (this keeps the data on the screen until the next trigger, allowing us to download the data via ethernet.
2. The DS345 is set to output a low frequency (0.005Hz) square wave, with 1Vpp amplitude, 0.5V offset (so the AOM driver input is driven between 0V and 1V DC, which is what we want). This gives us ~100 seconds to re-lock the IMC, and download the data, all while chilling in the control room
3. The autolocker was excellent yesterday, re-acquiring the IMC lock in ~30secs almost every time. But in the few instances it didn't work, turn the autolocker off (but make sure the MC2 tickle is on, it helps) and manually lock the IMC by twiddling the gain slider (basically manually do what the autolock script does). As mentioned above, you have ~100 secs to do this, if not just wait for 200secs and the next trigger...
4. In the meantime, download the data (script details to follow). I've made a little wrapper script (/users/gautam/2016_12_IMCloss/grabChans.sh) which uses Tobin's original python script, which unfortunately only grabs data one channel at a time. The shell script just calls the function thrice, and needs two command line arguments, namely the base name for the files to which the data will be written, and an IP address for the scope...

It is possible to do ~15 ringdowns in an hour, provided the seismic activity is low and the IMC is in a good mood. Unfortunately, I messed up my data acquisiton yesterday, so I only have data from 2 ringdowns, which I will work on fitting and extracting a loss number from. The ringing in the REFL signal is also a mystery to me. I will try using another PDA255 and see if this persists. But anyways, I think we can exclude the later part of the REFL signal, and fit the early exponential decay, in the worst case. The ringdown signal plots have been uploaded to my previous elog. Also, the triggering arrangement can be optimized further, for example by using the binary output from one of our FEs to trigger the actual waveform instead of leaving it in this low frequency oscillation, but given our recent experience with the Binary Output cards, I thought this is unnecessary for the time being...

Data analysis to follow.

I have left all the PDs I put in for this measurement. If anyone needs to remove the one in front of WFS2, go ahead, but I think we can leave the one on the MC2 trans table there...

For no apparent reason, the MC1 glitches are back. Nothing has been touched near the PD whitening chassis today, and the trend suggests the glitching started about 3 hours ago.. I had disabled the MC1 watchdog for a while to avoid the damping loop kicking the suspension around when these glitches occur, but have re-enabled it now. IMC is holding lock for some minutes... I was hoping to do another round of ringdowns tonight, but if this persists, its going to be difficult...

Over the weekend, I worked a bit on getting these ringdowns going. I will post a more detailed elog tomorrow but here is a quick summary of the changes I made hardware-wise in case anyone sees something unfamiliar in the lab...

• PDA10CF PD installed on PSL table in the beam path that was previously used for the 3f cancellation trials
• PDA255 installed on MC2 trans table, long BNC cable running from there to vertex via overhead cable tray
• PDA255 installed on AS table in front of one of the (currently unused) WFS

I spent a while in preparation for these trials (details tomorrow) like optimizing AOM alignment/diffracted power ratio, checking AOM and PMC switching times etc, but once the hardware is laid out, it is easy to do a bunch of ringdowns in quick succession with an ethernet scope. Tonight I did about 12 ringdowns - but stupidly, for the first 10, I was only saving 1 channel from the oscilloscope instead of the 3 we want to apply the MIT method.

Here is a representative plot of the ringdown - at the moment, I don't have an explanation for the funky oscillations in the reflected PD signal, need to think on this.. More details + analysis to follow...

Dec 5 2016, 130pm:

Actually the plot I meant to put up is this one, which has the time window acquired slightly longer. The feature I am referring to is the 100kHz oscillation in the REFL signal. Any ideas as to what could be causing this?

ELOG of the work on Thursday

Gautam suggested looking at the preamplifier noise by shorting the input to the first stage. I thought it was a great idea.

To my surprise, the noise of the 2nd stage was really high compared to the model. I proceeded to investigate what was wrong.

It turned out that the resistors used in this sallen-key LPF were thick film resistors. I swapped them with thin film resistors and this gave the huge improvement of the preamplifier noise in the low frequency band.

Attachment 1 shows the summary of the results. Previously the input referred noise of the preamp was the curve in red. We the resistors replaced, it became the curve in magenta, which is pretty close to the expected noise level by LISO model above 3Hz (dashed curves). Unfortunately, the output of the unit with the demodulator connected showed no improvement (blue vs green), because the output is still limited by the demodulator noise. There were harmonic noise peaks at n x 10Hz before the resistor replacement. I wonder if this modification also removed the harmonic noise seen in the CDS signals. I will check this next week.

Attachment 2 shows the current schematic diagram of the demodulator board. The Q of the sallen key filter was adjusted by the gain to have 0.7 (butter worth). We can adjust the Q by the ratio of the capacitance. We can short 3.83K and remove 6.65K next to it. And use 22nF and 47nF for the capacitors at the positive input and the feedback, respectively. This reduces the number of the resistors.

ELOG of the Wednesday work.

It turned out that the IMC WFS demod boards have the PCB board that has a different pattern for each of 8ch.
In addition, AD831 has a quite narrow leg pitch with legs that are not easily accessible.
Because of these, we (Koji and Rana) decided to leave the demodulator chip untouched.

I have plugged in the board with the WFS2-Q1 channel modified in order to check the significance of the modification.

WFS performance before the modification

Attachment 1 shows the PSD of WFS2-I1_OUT calibrated to be referred to the demodulator output. (i.e. Measured PSDs (cnt/rtHz) were divided by 8.9*2^16/20)
There are three curves: One is the output with the MC locked (WFS servos not engaged). The second is the PSD with the PSL beam blocked (i.e. dark noise). The third is the electronics noise with the RF input terminated and the nominal LO supplied.

This tells us that the measured PSD was dominated by the demodulator noise in the dark condition. And the WFS signal was also dominated by the demod noise below 0.1Hz and above 20Hz. There are annoying features at 0.7, 1.4, 2.1, ... Hz. They basically impose these noise peaks on the stabilized mirror motion.

WFS performance after the modification

Attachment 2 shows the PSD of WFS2-Q1_OUT calibrated to be referred to the demodulator output. (i.e. Measured PSDs (cnt/rtHz) were divided by 21.4*2^16/20)
There are three same curves as the other plot. In addition to these, the PSD of WFS2-I1_OUT with the MC locked is also shown as a red curve for comparison.

This figure tells us that the measured PSD below 20Hz was dominated by the demodulator noise in the dark condition. And the WFS signal is no longer dominated by the electronics noise. However, there still are the peaks at the harmonics of 0.7, 1.4, 2.1, ... Hz. I need further inspection of the FWS demod and whtening boards to track down the cause of these peaks.

I've pulled out the 24V fuse block which supplies power to the AOM RF driver. The way things are set up on the PSL table, this same voltage source powers the RF amplifiers which amplify the green beatnote signals before sending them to the LSC rack. So I turned off the green beat PDs before pulling out the fuse. I then disconnected the input to the RF driver (it was plugged into a DS345 function generator on the PSL table) and terminated it with a 50 ohm terminator. I want to figure out a smart way of triggering the AOM drive and recording a ringdown on the scope, after which I will re-connect the RF driver to the DS345. The RF driver, as well as the green beat amplifiers and green beat PDs, remain unpowered for now...

The most recent power outage took out our projector and mixer. The projector was sent for repair while we ordered a new mixer. Both arrived today. Steve is working on re-installing the projector right now, and I installed the mixer which was verified to be working with our DAFI system (although the 60Hz issue still remains to be sorted out). The current channel configuration is:

Ch1: 3.5mm stereo output from pianosa

Ch2: DAFI (L)

Ch3: DAFI (R)

I've set some random gains for now, but we will have audio again when locking

I noticed 2 periods of frequent IMC locklosses on the StripTool trace, and so checked the MC1 PD readout channels to see if there were any coincident glitches. Turns out there wasnt BUT - the LR and UR signals had changed significantly over the last couple of days, which is when I've been working at 1X5. The fast LR readback was actually showing ~0, but the slow monitor channel had been steady so I suspected some cabling shenanigans.

Turns out, the problem was that the LEMO connector on the front of the MC1 whitening board had gotten jiggled ever so slightly - I re-jiggled it till the LR fast channel registered similar number of counts to the other channels. All looks good for now. For good measure, I checked the 3 day trend for the fast PD readback for all 8 SOS optics (40 channels in all, I didn't look at the ETMs as their whitening boards are at the ends), and everything looks okay... This while situation seems very precarious to me, perhaps we should have a more robust signal routing from the OSEMs to the DAQ that is more immune to cable touching etc...

The south end door leaky weather seals replaced.

The aim is here to get some overpressure inside / outside so the lab partical count would not depend on outside condition.

We want to measure the IMC round-trip loss using the Isogai et. al. ringdown technique. I spent some time looking at the various bits and pieces needed to make this measurement today, this elog is meant to be a summary of my thoughts.

1. Inventory
   • AOM (in its new mount to have the right polarization) has been installed upstream of the PMC by Johannes. He did a brief check to see that the beam is indeed diffracted, but a more thorough evaluation has to be done. There is currently no input to the AOM, the function generator on the PSL table is OFF.
   • The Isogai paper recommends 3 high BW PDs for the ringdown measurement. Souring through some old elogs, I gather that the QPDs aren't good for this kind of measurement, but the PDA255 (50MHz BW) is a suitable candidate. I found two in the lab today - one I used to diagnose the EX laser intensity noise and so I know it works, need to check the other one. We also have a working PDA10CF detector (150 MHz BW). In principle, we could get away with just two, as the ringdown in reflection and transmission do not have to be measured simultaneously, but it would be nice to have 3
   • DAQ - I think the way to go is to use a fast scope triggered on the signal sent to the AOM to cut the light to the IMC, need to figure out how to script this though judging by some 2007 elogs by rana, this shouldn't be too hard...
2. Layout plans
   • Where to put the various PDs? Keeping with the terminology of the Isogai paper, the "Trans diode" can go on the MC2 table - from past measurements, there is already a pickoff from the beam going to the MC TRANS QPD which is currently being dumped, so this should be straightforward...
     
   • For the "Incident Diode", we can use the beam that was used for the 3f cancellation trials - I checked that the beam still runs along the edge of the PSL table, we can put a fast PD in there...
   • For the "REFL diode" - I guess the MC REFL PD is high BW enough, but perhaps it is better to stick another PD in on the AS table, we can use one of the existing WFS paths? That way we avoid the complicated transfer function of the IMC REFL PD which is tuned to have a resonance at 29.4MHz, and keeps interfacing with the DAQ also easy, we can just use BNC cables...
   • We should be able to measure and calibrate the powers incident on these PDs relatively easily.
      
3. Other concerns
   • I have yet to do a thorough characterization of the AOM performance, there have been a number of elogs noting possible problems with the setup. For one, the RF driver datasheet recommends 28V supply voltage but we are currently giving it 24V. In the (not too distant) past, the AOM has been seen to not be very efficient at cutting the power, the datasheet suggests we should be able to diffract away 80% of the central beam but only 10-15% was realized, though this may have been due to sub-optimal alignment or that the AOM was receiving the wrong polarization...
4. Plan of action
   • Check RF driver, AOM performance, I have in mind following the methodology detailed here
   • Measure PMC ringdown - this elog says we want it to be faster than 1us
   • Put in the three high BW PDs required for the IMC ringdown, check that these PDs are working
   • Do the IMC ringdown

Does this sound like a sensible plan? Or do I need to do any further checks?

As we suspected, the binary breakout board (D080478, no drawing available) is simply a bunch of tracks printed on the PCB to route the DB37 connector pins to two IDE50 connectors. There was no visible damage to any of the tracks (some photos uploaded to the 40m picasa). Further, I checked the continuity between pins that should be connected using a DMM.

I got a slightly better understanding of how the binary output signal chain is - the relevant pages are 44 and 48 in the CONTEC manual. The diagram on pg44 maps the pins on the DB37 connector, while the diagram on pg 48 maps how the switching actually occurs. The "load" in our case is the 4.99kohm resistor on the PD whitening board D000210. Following the logic in the diagram on pg48 is easy - setting a "high" bit in the software should pull the load resistor to 0V while setting a "low" bit keeps the load at 15V (so effectively the whole setup of CONTEC card + breakout board + pull-up resistor can be viewed as a simple NOT gate, with the software bit as the input, and the output connected to the "IN" pin of the MAX333).

Since I was satisfied with the physical condition of the BO breakout board, I re-installed the box on 1X5. Then, with the help of a breakout board, I diagnosed the situation further - I monitored the voltage to the pins on the backplane connector to the whitening boards while switching the MEDM switches to toggle the whitening state. For all channels except ITMY UL, the behaviour was as expected, in line with the preceeding paragraph - the voltage swings between ~0V and ~15V. As mentioned in my post yesterday, the ITMY UL channel remains dodgy, with voltages of 12.84V (bit=1) and 10.79V (bit=0). So unless I am missing something, this must point to a faulty CONTEC card? We do have spares, do we want to replace this? It also looks like this problem has been present since at least 2011...

In any case, why should this lead to ITMY UL glitching? According to the MAX333 datasheet, the switch wants "low"<0.8V and "high">2.4V - so even if the CONTEC card is malfunctioning and the output is toggling between these two states, the condition should be that the whitening stage is always bypassed for this channel. The bypassed route works just fine, I measured the transfer function and it is unity as expected.

So what could possibly be leading to the glitches? I doubt that replacing the BO card will solve this problem. One possibility that came up in today's meeting is that perhaps the +24V to the Sat. Box. (which is used to derive the OSEM LED drive current) may be glitching - of course we have no monitor for this, but given that all the Sat. Amp. Adaptor boards are on 1X5 near the Acromag, perhaps Lydia and Johannes can recommission the PSL diagnostic Aromag to a power supply monitoring Acromag?

What do these glitches look like anyway? Here is a few second snapshot from one of the many MC1 excursions from yesterday - the original glitch itself is very fast, and then that gives an impulse to the damping loop which eventually damps away.

And here is one from when there was a glitch when the tester box was plugged in to the ITMY signal chain (so we can rule out anything in the vacuum, and also the satellite box itself as the glitches seem to remain even when boxes are shuffled around, and don't migrate with the box). So even though the real glitch happens in the UL channel (note the y axes are very different for the channels), the UR, LR and LL channels also "feel" it. recall that this is with the tester box (so no damping loops involved), and the fact that the side channel is more immune to it than the others is hard to explain. Could this just be electrical cross-coupling?

Still beats me what in the signal chain could cause this problem.

Some good news - Koji was running some tests on the modified WFS demod board and locked the IMC for this. We noticed that MC1 seemed well behaved for extended periods of time unlike last night. I realigned the PMC and IMC, and we have been having lock streches of a few hours as we usually have. I looked at the MC1 OSEM PD readbacks during the couple of lock losses in the last few hours, and didn't notice anything dramatic . So if things remain in this state, at least we can do other stuff with the IFO... I have plugged in the ITMY sat. box again, but have left the watchdog disabled, lets see what the glitching situation is overnight... The original ITMY sat. box has been plugged into the ETMY DAQ signal chain with a tester box. The 3 day trend supports the hypothesis the sat. box is not to blame. So I am plugging the ETMY suspension back in as well...

[ericq, gautam]

To diagnose the glitches in OSEM readouts, we have removed one of the PCIE BO D37 to IDE50 adaptor boxes from 1X5. All the watchdogs were turned off, and the power to the unit was cut before the cables on the front panel were removed. I am working on the diagnosis, I will update more later in the evening. Note that according to the c1sus model, the box we removed supplies backplane logic inputs that control whitening for ITMX, ITMY, BS and PRM (in case anyone is wondering/needs to restore damping to any of these optics). The whitening settings for the IMC mirrors resides on the other unit in 1X5, and should not be affected.

I was talking with Larry yesterday, and he suggested the rack-mounted supermicro machines SYS-5017A-EP (~$400) or SYS-5018A-FTN4 (~$600) that he uses for moving data around in LIGO. They have ≥2 gigabit ethernet ports and can thus function as modbus gateways, conveniently placed in the rack close to the slow DAQ/DIO chassis and running some local ubuntu or other distro (I think Aidan uses CentOS in the PSL lab). These only have atom processors, which would be sufficient for the slow machine replacement, but there are many more powerful models with sometimes subtle differences. If we motion towards a more complete GigECam coverage in the lab it could be better to kill two birds with one stone and get something a little faster that can do the video capture/processing, since these machines will be distributed more or less strategically around the lab. Just a thought, as I have currently no clear idea what resources are required for this or how much we're throwing at this GigECam upgrade.

The new SOS sus wire finally is stored in a nitrogen filled dessicator. This was recommended by Ca. Fine Wire to minimize the aging - oxidation.

The dessicator was pumped down with " aux-drypump " to 1 Torr and than filled up with N2 to 760 Torr. This was repeated 2x and the dessicator was sealed off.

I've attached a schematic for how we will connect the Acromag mosules to the slow channel I/O curently going to c1auxex. The following changes are made:

• We are getting rid of the slow readbacks from the Anti-Image and Oplev boards, as Rana says they are unnnecessary.
• The whitening switching for the QPD is currently done by a Contec "fast" binary I/O module, but can be managed by acromag instead. This alllows CAB_1Y9_34 to  be fed directly into the Acromag box since all of its connections can now be managed slow. 
• There's no need to change the PD whitening scheme around (since the signals never get huge), so we can set those to always be on and then lose those Contec channels. This means all of the necessary pins on CAB_1Y9_10 can go to Acromag. 
• All the other backplane cables go the the fast machines only. 

Short summary:

• Looks like Satellite boxes are not to blame for glitchy behaviour of shadow sensor PD readouts
• Problem may lie at the PD whitening boards (D000210) or with the Contec binary output cards in c1sus
• Today evening, similar glitchy behaviour was observed in all MC1 PD readout channels, leading to frequent IMC unlocking. Cause unknown, although I did work at 1X5, 1X6 today, and pulled out the PD whitening board for ITMY which sits in the same eurocrate as that for MC1. MC2/MC3 do not show any glitches.

Detailed story below...

Part 1: Satellite box swap

Yesterday, I switched the ITMY and ETMY satellite boxes, to see if the problems we have been seeing with ITMY UL move with the box to ETMY. It did not, while ITMY UL remained glitchy (based on data from approximately 10pm PDT on 28Nov - 10am PDT 29 Nov). Along with the tabletop diagnosis I did with the tester box, I concluded that the satellite box is not to blame.

Part 2: Tracing the signal chain (actually this was part 3 chronologically but this is how it should have been done...)

So if the problem isn't with the OSEMs themselves or the satellite box, what is wrong? I attempted to trace the signal chain from the satellite box into our CDS system as best as I could. The suspension wiring diagram on our wiki page is (I think) a past incarnation. Of course putting together a new diagram was a monumental task I wasn't prepared to undertake tonight, but in the long run this may be helpful. I will put up a diagram of the part I did trace out tomorrow, but the relevant links for this discussion are as follows (? indicates I am unsure):

1. Sat box (?)--> D010069 via 64pin IDE connector --> D000210 via DB15 --> D990147 via 4pin LEMO connectors --> D080281 via DB25 --> ADC0 of c1sus
2. D000210 backplane --> cross-connect (mis)labelled "ITMX white" via IDE connector
3. c1sus CONTEC DO-32L-PE --> D080478 via DB37 --> BO0-1 --> cross-connect labelled "XY220 1Y4-33-16A" via IDE --> (?)  cross-connect (mis)labelled "ITMX white" via IDE connector

I have linked to the DCC page for the various parts where available. Unfortunately I can't locate (on new DCC or old or elog or wiki) drawings for D010069 (Satellite Amplifier Adapter Board), D080281 ("anti-aliasing interface)" or D080478 (which is the binary output breakout box). I have emailed Ben Abbott who may have access to some other archive - the diagrams would be useful as it is looking likely that the problem may lie with the binary output.

So presumably the first piece of electronics after the Satellite box is the PD whitening board. After placing tags on the 3 LEMOs and 1 DB15 cable plugged into this board, I pulled out the ITMY board to do some tabletop diagnosis in the afternoon around 2pm 29Nov.

Part 3: PD whitening board debugging

This particular board has been reported as problematic in the recent past. I started by inserting a tester board into the slot occupied by this board - the LEDs on the tester board suggested that power-supply from the backplane connectors were alright, confirmed with a DMM.

Looking at the board itself, C4 and C6 are tantalum capacitors, and I have faced problems with this type of capacitor in the past. In fact, on the corresponding MC3 board (which is the only one visible, I didn't want to pull out boards unnecessarily) have been replaced with electrolytic capacitors, which are presumably more reliable. In any case, these capacitors do not seem to be at any fault, the board receives +/-15 V as advertised.

The whitening switching is handled by the MAX333 - this is what I looked at next. This IC is essentially a quad SPDT switch, and a binary input supplied via the backplane connector serves to route the PD input either through a whitening filter, or bypass it via a unity gain buffer. The logic levels that effect the switching are +15V and 0V (and not the conventional 5V and 0V), but according to the MAX333 datasheet, this is fine. I looked at the supply voltage to all ICs on the board, DC levels seemed fine (as measured with a DMM) and I also looked at it on an oscilloscope, no glitches were seen in ~30sec viewing stretch. I did notice something peculiar in that with no input supplied to the MAX333 IC (i.e. the logic level should be 15V), the NO and NC terminals appear shorted when checked with a DMM. Zach has noticed something similar in the past, but Koji pointed out that the DMM can be fooled into thinking there is a short. Anyway, the real test was to pull the logic input of the MAX333 to 0, and look at the output, this is what I did next.

The schematic says the whitening filter has poles at 30,100Hz and a zero at 3 Hz. So I supplied as "PD input" a 12Hz 1Vpp sinewave - there should be a gain of ~x4 when this signal passes through the path with the whitening filter. I then applied a low frequency (0.1Hz) square wave (0-5V) to the "bypass" input, and looked at the output, and indeed saw the signal amplitude change by ~4x when the input to the switch was pulled low. This behaviour was confirmed on all five channels, there was no problem. I took transfer functions for all 5 channels (both at the "monitor" point on the backplane connector and on the front panel LEMOs), and they came out as expected (plot to be uploaded soon).

Next, I took the board back to the eurocrate. I first put in a tester box into the slot and measured the voltage levels on the backplane pins that are meant to trigger bypassing of the whitening stage, all the pins were at 0V. I am not sure if this is what is expected, I will have to look inside D080478 as there is no drawing for it. Note that these levels are set using a Contec binary output card. Then I attached the PD whitening board to the tester board, and measured the voltages at the "Input" pins of all the 5 SPDT switches used under 2 conditions - with the appropriate bit sent out via the Contec card set to 0 or 1 (using the button on the suspension MEDM screens). I confirmed using the BIO medm screen that the bit is indeed changing on the software side, but until I look at D080478, I am not sure how to verify the right voltage is being sent out, except to check at the pins on the MAX333. For this test, the UL channel was indeed anomalous - while the other 4 channels yielded 0V (whitening ON, bit=1) and 15V (whitening OFF, bit=0), the corresponding values for the UL channel were 12V and 10V.

I didn't really get any further than this tonight. But this still leaves unanswered questions - if the measured values are faithful, then the UL channel always bypasses the whitening stage. Can this explain the glitchy behaviour?

Part 4: MC1 troubles

At approximately 8pm, the IMC started losing lock far too often - see the attached StripTool trace. There was a good ~2hour stretch before that when I realigned the IMC, and it held lock, but something changed abruptly around 8pm. Looking at the IMC mirror OSEM PD signals, all 5 MC1 channels are glitching frequently. Indeed, almost every IMC lockloss in the attached StripTool is because of the MC1 PD readouts glitching, and subsequently, the damping loops applying a macroscopic drive to the optic which the FSS can't keep up with. Why has this surfaced now? The IMC satellite boxes were not touched anytime recently as far as I am aware. The MC1 PD whitening board sits in the same eurocrate I pulled the ITMY board out of, but squishing cables/pushing board in did not do anything to alleviate the situation. Moreover, MC2 and MC3 look fine, even though their PD whitening boards also sit in the same eurocrate. Because I was out of ideas, I (soft) restarted c1sus and all the models (the thinking being if something was wrong with the Contec boards, a restart may fix it), but there was no improvement. The last longish lock stretch was with the MC1 watchdog turned off, but as soon as I turned it back on the IMC lost lock shortly after.

I am leaving the autolocker off for the night, hopefully there is an easy fix for all of this...

more U4 gain, lesssss U5 gain

We found that someone had violated all rules of computer security decency and was storing our nodus password as a plain text file in their bash_profile.

After the flogging we have changed the pwd and put the new one in the usual secret place.

Summary: The demodulator input noise level was improved by a factor of more than 2. This was not as much as we expected from the preamp noise improvement, but is something. If this looks OK, I will implement this modification to all the 16 channels.

The modification shown in Attachment 1 has actually been applied to a channel.

• The two 1.5uF capacitors between VP and AN/AP were added. This decreases the bandwidth of the demodulator down to 7.4kHz
• The offset trimming circuit was disabled. i.e. Pin18 of AD831 was grounded.
• The passive low pass at the demodulator output was removed. (R18, C34)
• The stage1 (preamp) chip was changed from AD797 to OP27.
• The gain of the preamp stage was changed from 9 to 21. Also the thin film resistors are used.

Attachment 2 shows the measured and expected output signal transfer of the demodulator. The actual behavior of the demodulator is as expected, and we still keep the over all LPF feature of 3rd order with fc=~1kHz.

Attachment 3 shows the improvement of the noise level with the signal reffered to the demodulator input. The improvement by a factor >2 was observed all over the frequency range. However, this noise level could not be explained by the preamp noise level. Actually this noise below 1kHz is present at the output of the demodulator. (Surprisingly, or as usual, the noise level of the previous preamp configuration was just right at the noise level of the demodulator below 100Hz.) The removal of the offset trimmer circuit contributed to the noise improvement below 0.3Hz.

400 days plot. Satelite amp ITMY has been swapped with ETMY

Unlabeled sat.amps are labeled. This plot only makes sense if you know the Cuh-Razy sat amp locations.

I left the tester box plugged in from Thursday night to Sunday afternoon, and in this period, the glitches still appeared in (and only in) the UL channel.

So yesterday evening, I pulled the Sat. Box. out and checked the DC voltages at various points in the circuit using a DMM, including the output of the high current buffer that supplies the drive current to the shadow sensor LEDs. When we had similar behaviour in the PRM box, this kind of analysis immediately identified the faulty component as the high current buffer IC (LM6321M) in the bad channel, but everything seems in order for the ITMY box. 

I then checked the Satellite Amplifier Termination Board, which basically just adds 100ohm series resistors to the output of the PD readout, and all the resistors seem fine, the piece of insulating material affixed to the bottom of this board is also intact. I then used the SR785 in AC coupled mode to look at the high frequency spectrum at the same points I checked the DC voltages with the DMM (namely the drive voltage to the LEDs, and the PD readout voltages on the PCB as well as on the pins of the connector on the outside of the box after the termination board (leading to the DAQ), and nothing sticks out here in the UL channel either. Of course it could be that the glitches are intermittent, and during my tests they just weren't there...

I am hesitant to start pulling out ICs and replacing them without any obvious signs of failure from them, but I am out of debugging ideas...

One possibility is that the problem lies upstream of the Sat. Box - perhaps the UL channel in the Suspension PD Whitening and Interface Board is faulty. To test, I have now hooked up ITMY Sat. Box. + tester box to the signal chain of ETMY. If I can get the other tester box back from Ben, I will plug in the ETMY sat. box. + tester to the ITMY signal chain. This should tell us something...

The vacuum envelope ~1 C warmer today than 7 days ago. Bad peaks are coming down as normal.