40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log  Not logged in ELOG logo
Entry  Sat Nov 12 01:09:56 2016, gautam, Update, LSC, Recovering DRMI locking 
    Reply  Wed Nov 16 03:10:01 2016, gautam, Update, LSC, DRMI locked on 1f and 3f signals 
       Reply  Wed Nov 16 08:14:43 2016, Steve, Update, LSC, DRMI locked on 1f and 3f signals 5hrs.png
       Reply  Mon Nov 21 14:02:32 2016, gautam, Update, LSC, DRMI locked on 3f signals, arms held on ALS DRMIArms_Nov20.pdf
    Reply  Wed Nov 23 16:21:02 2016, gautam, Update, LSC, ITMY UL glitches are back ITMYproblemsBack.png
       Reply  Mon Nov 28 10:27:13 2016, gautam, Update, SUS, ITMY UL glitches are back ITMY_satboxSpectra.pdfITMY_UL_testerBox.png
       Reply  Tue Nov 29 11:07:37 2016, Steve, Update, LSC, ITMY UL glitches are back gliching400d.png
          Reply  Wed Nov 30 01:47:56 2016, gautam, Update, LSC, Suspension woes IMCwoes.png
             Reply  Wed Nov 30 17:08:56 2016, gautam, Update, LSC, Binary output breakout box removed 
                Reply  Thu Dec 1 02:19:13 2016, gautam, Update, LSC, Binary output breakout box restored MC1_glitch_fast.pngITMY_testerGlitch.pngITMYsatbox.pngULcomparison.pdf
                   Reply  Thu Dec 1 08:02:57 2016, Steve, Update, LSC, glitching ITMY_UL_LL ITMY_UL_LL.png
                      Reply  Fri Dec 2 11:56:42 2016, gautam, Update, LSC, MC1 LEMO jiggled IMG_3474.JPGMC1_LR_dead.png
                         Reply  Mon Dec 5 15:05:37 2016, gautam, Update, LSC, MC1 glitches are back Mc1glitches.png
                      Reply  Thu Dec 8 10:13:43 2016, Steve, Update, LSC, glitching ITMY_UL has a history glitching__ITMY-UL_2007.png
Message ID: 12653     Entry time: Thu Dec 1 02:19:13 2016     In reply to: 12652     Reply to this: 12654
Author: gautam 
Type: Update 
Category: LSC 
Subject: Binary output breakout box restored 

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

Attachment 4: ULcomparison.pdf  24 kB  | Hide | Hide all
ELOG V3.1.3-