40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 88 of 339 Not logged in
ID Date Author Type Category Subject
12653   Thu Dec 1 02:19:13 2016 gautamUpdateLSCBinary 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 . 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
12652   Wed Nov 30 17:08:56 2016 gautamUpdateLSCBinary output breakout box removed

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

12651   Wed Nov 30 14:54:01 2016 JohannesUpdateCDSSlow machine replacement

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.

 Quote: 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.

12650   Wed Nov 30 14:53:56 2016 SteveUpdateSUSnew sus wire stored in N2 filled dessicator

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.

Attachment 1: dessicatorC.jpg
Attachment 2: wireN2c.jpg
12649   Wed Nov 30 11:56:56 2016 LydiaUpdateCDSWiring for Acromag auxex replacement

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.

Attachment 1: auxex_acromag.pdf
12648   Wed Nov 30 01:47:56 2016 gautamUpdateLSCSuspension woes

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

Attachment 1: IMCwoes.png
12647   Tue Nov 29 18:35:32 2016 ranaUpdateIOOIMC WFS Demod board measurement & analysis

more U4 gain, lesssss U5 gain

12646   Tue Nov 29 17:46:18 2016 rana, gautamFrogsComputer Scripts / Programsgateway PWD change

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.

12645   Tue Nov 29 17:45:06 2016 KojiUpdateIOOIMC WFS Demod board measurement & analysis

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.

Attachment 1: demod.pdf
Attachment 2: WFS_demod_response.pdf
Attachment 3: WFS_demod_noise.pdf
12644   Tue Nov 29 11:07:37 2016 SteveUpdateLSCITMY UL glitches are back

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.

Attachment 1: gliching400d.png
12643   Mon Nov 28 10:27:13 2016 gautamUpdateSUSITMY UL glitches are back

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

Attachment 1: ITMY_satboxSpectra.pdf
12642   Mon Nov 28 09:45:44 2016 SteveUpdateVACRGA scan at pumpdown day 40

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

Attachment 1: RGAscan_d40.png
Attachment 2: d2_&_d7scan.png
12641   Sat Nov 26 19:16:28 2016 KojiUpdateIOOIMC WFS Demod board measurement & analysis

[Rana, Koji]

1. The response of the IMC WFS board was measured. The LO signal with 0.3Vpp@29.5MHz on 50Ohm was supplied from DS345. I've confirmed that this signal is enough to trigger the comparator chip right next to the LO input. The RF signal with 0.1Vpp on the 50Ohm input impedance was provided from another DS345 to CH1 with a frequency offset of 20Hz~10kHz. Two DS345s were synced by the 10MHz RFreference at the rear of the units. The resulting low frequency signal from the 1st AF stage (AD797) and the 2nd AF stage (OP284) were checked.

Attachment 1 shows the measured and modelled response of the demodulator with various frequency offsets. The value shows the signal transfer (i.e. the output amplitude normalized by the input amplitude) from the input to the outputs of the 1st and 2nd stages. According to the datasheet, the demodulator chip provides a single pole cutoff of 340kHz with the 33nF caps between AP/AN and VP. The first stage is a broadband amplifier, but there is a passive LPF (fc=~1kHz). The second stage also provides the 2nd order LPF at fc~1kHz too. The measurement and the model show good agreement.

2. The output noise levels of the 1st and 2nd stages were meausred and compared with the noise model by LISO.
Attachment 2 shows the input referred noise of the demodulator circuit. The output noise is basically limited by the noise of the first stage. The noise of the 2nd stage make the significant contribution only above the cut off freq of the circuit (~1kHz). And the model supports this fact. The 6.65kOhm of the passive filter and the input current noise of AD797 cause the large (>30nV/rtHz) noise contribution below 100Hz. This completely spoils the low noiseness (~1nV/rtHz) of AD797. At lower frequency like 0.1Hz other component comes up above the modelled noise level.

3. Rana and I had a discussion about the modification of the circuit. Attachment 4 shows the possible improvement of the demod circuit and the 1st stage preamplifier. The demodulator chip can have a cut off by the attached capacitor. We will replace the 33nF caps with 1uF and the cut off will be pushed down to ~10kHz. Then the passive LPF will be removed. We don't need "rodeo horse" AD797 for this circuit, but op27 is just fine instead. The gain of the 1st stage can be increased from 9 to 21. This should give us >x10 improvement of the noise contribution from the demodualtor (Attachment 3). We also can replace some of the important resistors with the thin film low noise resistors.

Attachment 1: WFS_demod_response.pdf
Attachment 2: WFS_demod_noise.pdf
Attachment 3: WFS_demod_noise_plan.pdf
Attachment 4: Screen_shot_2011-07-01_at_11.13.01_AM.png
12640   Wed Nov 23 20:08:51 2016 Koji, ranaUpdateIOOMC WFS Demod/Whitening boards removed from the IOO rack

We removed one set of the MC WFS demod board and whitening board from the IOO rack for the investigation.
The MC WFS servo loops are disabled with the EPICS screens.
Let us know when you need the MC WFS boards to be returned to the rack.

This is to investigate the signal chain and fix some issues. We ramped down the -100 V supply for the WFS QPD bias (why is it so big?), but everything else is still on. Koji is doing demod board. Rana will upload a marked up WFS whitening board schematic soon.

12639   Wed Nov 23 17:48:16 2016 rana, kojiUpdateIOOHow bad is the McWFS?

Medium.

Previous elog entries on this:

12638   Wed Nov 23 16:21:02 2016 gautamUpdateLSCITMY UL glitches are back

 Quote: 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...

I've noticed that the glitchy behaviour in ITMY UL shadow sensor readback is back - as mentioned above, I looked at the Sat. Box and could not find anything wrong with it, perhaps I'll plug the tester box in over the Thanksgiving weekend and see if the glitches persist...

12637   Wed Nov 23 15:08:56 2016 ranaUpdateIMCMCL Feedback

In the Generic Pentek interface board, which is used to take in the analog 2-pin LEMO cable from the MC Servo board, there is some analog whitening before the signal is sent into the ADC.

There are jumpers in there to set whether it is 0, 1, or 2 stages of 150:15 (z:p) whitening.

12636   Wed Nov 23 11:32:13 2016 SteveUpdateVACTP3 drypump replaced again

TP3 drypump replaced at 655 mTorr, no load, tp3 0.3A

This seal lasted only for 33 days at  123,840 hrs

The replacement is performing well: TP3 foreline pressure is 55 mTorr, no load, tp3 0.15A at 15 min  [ 13.1 mTorr at d5 ]

Valve configuration: Vacuum Normal, ITcc 8.5E-6 Torr

Quote:

Dry pump of TP3 replaced after 9.5 months of operation.[ 45 mTorr d3 ]

The annulosses are pumped.

Valve configuration: vac normal, IFO pressure 4.5E-5 Torr [1.6E-5 Torr d3 ] on new ITcc gauge, RGA is not installed yet.

Note how fast the pressure is dropping when the vent is short.

 Quote: IFO pressure 1.7E-4 Torr on new not logged cold cathode gauge. P1 <7E-4 Torr Valve configuration: vac.normal with anunulossess closed off. TP3 was turned off with a failing drypump. It will be replaced tomorrow.

All time stamps are blank on the MEDM screens.

12635   Wed Nov 23 01:13:02 2016 gautamUpdateIMCMCL Feedback

I wanted to get a clearer idea of the FSS servo and the various boxes in the signal chain and so Lydia and I poked around the IOO rack and the PSL table - I will post a diagram here tomorrow.

We then wanted to characterize the existing loop. It occurred to me later in the evening to measure the plant itself to verify the model shape used to construct the invP filter in the feedback path. I made the measurement with a unity gain control path, and I think there may be an extra zero @10Hz in the model.

Earlier in the evening, we measured the OLG of the MCL loop using the usual IN1/IN2 prescription, in which above 10Hz, the measurement and FOTON disagree, which is not surprising given Attachment #1.

I didn't play around with the loop shape too much tonight, but we did perform some trials using the existing loop, taking into account some things I realized since my previous attempts. The summary of the performanceof the existing loop is:

• Below 1Hz, MCL loop injects noise to the arm control signal. I need to think about why this is, but perhaps it is IMC sensing noise?
• Between 1-4Hz, the MCL loop suppresses the arm control signal
• Between 4-10Hz (and also between 60-100Hz for the Xarm), the MCL loop injects noise. Earlier in the evening, we had noticed that there was a bump in the X arm control signal between 60-100Hz (which was absent in the Y arm control signal). Koji later helped me diagnose this as too low loop gain, this has since been rectified, but the HF noise of the X arm remains somewhat higher than the Y arm.

All of the above is summarized in the below plots - this behaviour is (not surprisingly) in line with what Den observed back when he put these in.

The eventual goal here is to figure out if we can get an adaptive feedback loop working in this path, which can take into account prevailing environmental conditions and optimally shape the servo to make the arms follow the laser frequency more closely at low frequencies (i.e. minimize the effect of the noise injected by IMC length fluctuations at low frequency). But first we need to make a robust 'static' feedback path that doesn't inject control noise at higher frequencies, I need to think a little more about this and work out the loop algebra to figure out how to best do this...

Attachment 1: MCL_plant.pdf
Attachment 2: OLG.pdf
Attachment 3: MC_armSpectra_X.pdf
Attachment 4: MC_armSpectra_Y.pdf
12634   Tue Nov 22 13:55:32 2016 JohannesOmnistructure40m upgradingAcromag Chassis

Current Acromag chassis status:

I found out that Acromag offers DIN rail mounting kits for the open boards, so we can actually fit both XT series and ES/EN series in the same boxes, depending on the signal needs. The primary design driver will be the ES footprint, but if we find we don't need that many channels in some of the units, it's interchangable. For the wiring to the front panel - for which we will have a standard front panel express design, but may order modified ones for the custom needs of the 40m, I will contract the same company that Rich used for the wiring in his DIO box (Panel mount connectors terminating in loose wires/pre-routed plugs for Acromag units). We will either run a single DIN rail along the length of the chassis, or have two in parallel across.

Lydia and I took close looks at the breakout arrangements on the rack sides, and determined that because of the many cross-connects between non-DAQ ports it is not possible to redo and debug this in a reasonable amount of time without essentially shutting down the interferometer. So instead, we will connect the chassis directly to the slots that were previously leading to the slow machines. They come in two different flavors: The ADC modules have 64 pins, while the DIO and DAC ones have 50. There are a couple things we can do:

• For ADC: Put favorite 64+ pin connector on front panel. I would advocate for the 68 pin VHDIC (SCSI-5). This standard ist widely used, has a sturdy connector, and usually off-the-shelf cables have twisted pair leads.
• For DAC+DIO: Either use favorite 50 pin connector (there are 50-pin DSUB connectors, and also 50-pin IDC connectors with backshell), or also send the signals through VHDIC connectors, tolerating a few unused lanes. I would prefer the second option, after all it all goes to some 64 pin VME-crate backplane connector in the end, so if we ever get rid of the rack-side breakouts the wiring will much more uniform.
• For good measure, we will add a few (16 maybe) BNC connectors to the front panel.
• A standardized front panel could have a variety of different connectors by default: DSUBs, BNCs, etc., to be used when needed with some initial default wiring.
• Note that THEORETICALLY we could even connect all backplane EUROCARD ports to the Acromag chassis and do the cross-connect wiring entirely inside, although that would make the inside extremely messy.

Based on Rich's design I will get started on a parts list and wiring diagrams to send out to the cable company.

Attachment 1: acroplan.pdf
12633   Tue Nov 22 11:31:52 2016 SteveUpdateVACRGA is running again

The Rga was turned on yesterday.

 Quote: The RGA is removed for repaire. It's volume at atmophere and sealed.. P4 reading of 38 Torr is not correct.

Attachment 1: RGAisBack33d.png
Attachment 2: pd80-560Hz-d33.png
Attachment 3: afterRepair1d.png
12632   Mon Nov 21 19:54:13 2016 JohannesUpdateCDSacromag chassis hooked up to PSL

[Lydia, Johannes]

We connected and powered up the Acromag chassis today. It lives in 1X4 and is powered by the Sorensen +20V power supply in 1X5 via the fuse rail on the side of 1X4. For this we had to branch off the 20V path to the dewhitening and anti-image filter crate of the c1:susaux driven SOS optics. After confirming that none of the daughter modules in the crate draw from the 20V line, we added a wire leading to a new fuse we added for this unit and ran a power cable from there.

The diagnostic connector of the PSL laser is now connected to the unit and a tmux session was created on megatron that interfaces with the chassis and broadcasts the EPICS channels. We need to watch out in the coming days for epics freezes/outages, as in the past these seemed to occur around the same times we were toying with the Acromags.

 Quote: We set up the chassis in 1X7 today. Steve is ordering a longer 25 pin cable to reach. Until then the PSL diagnostic channels will not be usable.

Attachment 1: acromag_chassis.jpg
12631   Mon Nov 21 15:34:24 2016 gautamUpdateCOCRC folding mirrors - updated specs

Following up on the discussion from last week's Wednesday meeting, two points were raised:

1. How do we decide what number we want for the coating on the AR side for 532nm?
2. Do we want to adjust T@1064nm on the HR side to extract a stronger POP beam?

With regards to the coating on the AR side, I've put in R<300ppm@1064nm and R<1000ppm@532nm on the AR side. On the HR side, we have T>97% @ 532nm (copied from the current PR3/SR3 spec), and T<50ppm @1064nm. What are the ghost beams we need to be worried about?

• Scattered light the AR side interfering with the main transmitted green beam possibly making our beat measurement noisier
• With the above numbers, accounting for the fact that we ask for a 2 degree wedge on PR3, the first ghost beam from reflection on the AR side will have an angular separation from the main beam of ~7.6 degrees. So over the ~4m the green beam travels before reaching the PSL table, I think there is sufficient angular separation for us to catch this ghost and dump it.
• Moreover, the power in this first ghost beam will be ~30ppm relative to the main green beam. If we can get R<100ppm @532nm on the AR side, the number becomes 3ppm
• Prompt reflection from the HR surface of PR3 scattering green light back into the arm cavity mode
• The current spec has T>97% @532nm. So 3% is promptly reflected at the HR side of PR3
• I'm not sure how much of a problem this really will be - I couldn't find the reflectivities of PR2 and PRM @532nm (were these ever measured?)
• In any case, if we can have T<50ppm @1064nm and R>99.9% @532nm, that would be better

So in conclusion, with the specs as they are now, I don't think the ALS noise performance is adversely affected. I have updated the spec to have the following numbers now.

HR side: T < 50ppm @1064nm, T>99.9% @532nm

AR side: R < 100ppm @1064nm and @532nm

As for the POP question, if we want to extract a stronger POP beam, we will have to relax the requirement on the transmission @1064nm on the HR side. But recall that the approach we are now considering is to replace only PR3, and flip PR2 back the right way around. Currently, POP is extracted at PR2, so if we want to stick with the idea of getting a new PR3 and extracting a stronger POP beam, there needs to be a major optical layout reshuffle in the BS/PRM chamber. Koji suggested that in the interest of keeping things moving along, we don't worry about POP for the time being...

Alternatively, if it turns out that the vendor can meet the specs for our second requirement (which requires 1.5% of lambda @632nm measurement precision to meet the 10+/-5km RoC tolerance on PR3), then we can ast for T<1000ppm @1064nm for the HR coating on PR2, and keep the coating specs on PR3 as above.

Attached is a pdf with the specs updated to reflect all the above considerations...

Attachment 1: Recycling_Mirrors_Specs_Nov2016.pdf
12630   Mon Nov 21 14:02:32 2016 gautamUpdateLSCDRMI locked on 3f signals, arms held on ALS

Over the weekend, I was successful in locking the DRMI with the arms held on ALS. The locks were fairly robust, lasting order of minutes, and was able to reacquire by itself when it lost the lock in <1min. I had to tweak the demod phases and loop gains further compared to the 1f lock with no arms, but eventually I was able to run a sensing matrix measurement as well. A summary of the steps I had to follow:

• Lock on 1f signals, no arms, and run sensing lines, adjust REFL33 and REFL 165 demod phases to align PRCL, MICH and SRCL as best as possible to REFL33I, REFL165Q and REFL165I respectively
• I also set the offsets to the 'B' inputs at this stage
• Lock arms on ALS, engage DRMI locking on 3f signals (the restore script resets some values like the 'B' channel offsets, so I modified the restore script to set the offsets I most recently measured)
• I was able to achieve short locks on the settings from the locking with no arms - I set the loop gains using the UGF servos and ran some sensing lines to get an idea of what the final demod phases should be
• Adjusted the demod phases, locked the DRMI again (with CARM offset = -4.0), and took another sensing matrix measurement (~2mins). The data was analyzed using the set of scripts EricQ has made for this purpose, here is the result from a lock yesterday evening (the radial axis is meant to be demod board output volts per meter but the calibration I used may be wrong)

I've updated the appropriate fields in the restore script. Now that the DRMI locking is somewhat stable again, I think the next step towards the full lock would be to zero the CARM offset and turning on the AO path.

On the downside, I noticed yesterday that ITMY UL shadow sensor readback was glitching again - for the locking yesterday, I simply held the output of that channel to the input matrix, which worked fine. I had already done some debugging on the Sat. Box with the help of the tester box, but unlike the PRM sat. box, I did not find anything obviously wrong with the ITMY one... I also ran into a CDS issue when I tried to run the script that sets the phase tracker UGF - the script reported that the channels it was supposed to read (the I and Q outputs of the ALS signal, e.g. C1:ALS-BEATX_FINE_I_OUT) did not exist. The same channels worked on dataviever though, so I am not sure what the problem was. Some time later, the script worked fine too. Something to look out for in the future I guess..

Attachment 1: DRMIArms_Nov20.pdf
12629   Mon Nov 21 11:30:01 2016 SteveUpdatePEMrat is cut and removed

Last jump at rack Y2.

Attachment 1: rat#2.png
12628   Sun Nov 20 23:53:38 2016 awadeUpdatePSLFSS Slow control -> Python, WFS re-engaged

I made a very slighly updated version of Yinzi's script that pulls the channel names and actuator hardstop limits from an external .ini config file. The idea was to avoid having as many versions of the script as there are implimentations of it. Seems like slighly better practice, but maybe I'm wrong. The config files are also easier to read. Its posted on the elog (PSL:1758) with lastest on the 40mSVN .../trunk/CTNLab/current/computing/scripts .

If you're working off her first implimentation 'RCAV_thermalPID.py' then there is an indent issue after the if statement on line 88: only line 89 should be indended. If you deactivate the debug flag then the script fails to read in PID factors and dies.

 Quote: [yinzi, craig, gautam] Yinzi had translated the Perl PID script used to implement the discrete-time PID control, and had implemented it with Andrew at the PSL lab. Today afternoon we made some minor edits to make this suitable for the FSS Slow loop (essentially just putting the right channel names into her Python script). I then made an init file to run this script on megatron, and it looks to be working fine over the last half hour of observation or so. I am going to leave things in this state over the weekend to see how it performs. We have been running with just the MC2 Transmission QPD for angular control of the IMC for a couple of months now because the WFS loops seemed to drag the alignment away from the optimum. We did the following to try and re-engage the WFS feedback: Close the PSL shutter, turned off all the lights in the lab and ran the WFS DC offsets script Locked the IMC, optimized alignment by hand (WFS feedback turned off) Unlocked the IMC, went to the AS table and centered the spots on the WFS Ran WFS RF offsets script Re-engaged WFS servo

12627   Fri Nov 18 17:52:42 2016 gautamUpdatePSLFSS Slow control -> Python, WFS re-engaged

[yinzi, craig, gautam]

Yinzi had translated the Perl PID script used to implement the discrete-time PID control, and had implemented it with Andrew at the PSL lab. Today afternoon we made some minor edits to make this suitable for the FSS Slow loop (essentially just putting the right channel names into her Python script). I then made an init file to run this script on megatron, and it looks to be working fine over the last half hour of observation or so. I am going to leave things in this state over the weekend to see how it performs.

We have been running with just the MC2 Transmission QPD for angular control of the IMC for a couple of months now because the WFS loops seemed to drag the alignment away from the optimum. We did the following to try and re-engage the WFS feedback:

• Close the PSL shutter, turned off all the lights in the lab and ran the WFS DC offsets script : /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_DC_offsets
• Locked the IMC, optimized alignment by hand (WFS feedback turned off) /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_DC_offsets
• Unlocked the IMC, went to the AS table and centered the spots on the WFS
• Ran WFS RF offsets script - this should be done with the IMC unlocked (after good alignment has been established) /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_DC_offsets
• Re-engaged WFS servo

GV addendum 23Nov2016: The WFS have been working well over the last few days - I've had to periodically (~ once in a day) run the WFS reflief script to keep the outputs to the suspension PIT and YAW DOFs below 50cts, but the WFS aren't dragging the alignment away as we had noticed before. The only thing I did differently is to follow Rana's suggestion and set the RF offsets with the MC unlocked as opposed to locked. I've added a line to the script to remind the user to do so... Also, note that EricQ has recently cleaned up the scripts directory to remove the numerous obsolete scripts in there...

12626   Fri Nov 18 15:10:06 2016 SteveUpdateGeneral projector shipped out for repair

Vivitek D952HD sn2160130 was send out for warranty repair. It's hard to believe that it has a 5 year warranty...... RMA - WR16004483.....expected to be back by Friday, Dec 2

 Quote: The projector failed just now with a pretty loud 'pop' sound - I've never been present when the lamp goes out, so I don't know if this is usual. I have left the power cable unplugged for now... Replacement is ordered Nov 4

12625   Fri Nov 18 00:25:08 2016 JohannesOmnistructure40m upgradingAcromag Chassis Development

I had Rich show me his approach to a chassis for the Acromag modules. The document tree for his design can be found on the DCC. Note that he's using the high densitymodel ES series, which is available as a bare board variant with pluggable screw terminals:

He can fit up to 4 of these in a 2U chassis and has outsourced the wiring from front panel Dsubs to the board connectors to an external company. At the 40m (and in West Bridge) we currently only have the rail mounted XT series

At first glance the specs are very similar. Both A/D and D/A flavors have 16-bit precision in both cases. The high density ES series with Rich's layout can achieve 128 A/D per 2U, 64 D/A per 2U, or 384 DIO per 2U. Into a 4U chassis of the type we have currently we can fit ~32 XT modules (assuming two rows), which results in very similar numbers, except for the DAC, of which we could fit more.

XT1221-000 (8 diff. channel 16-bit ADC)                          $495.00$61.88/ch
XT1541-000 (8 channel 16-bit DAC and 4 discrete I/O )    $525.00$65.63/ch
XT1120-000 (16 channel DIO)                                         $320.00$20.00/ch

ES2162-0010 (32 diff. channel 16-bit ADC)                     $2050.00$64.06/ch
ES2172-0010 (16 channel 16-bit DAC)                           $1400.00$87.50/ch
ES2113-0010 (96 channel DIO)                                      $1100.00$11.46/ch

It's cheaper to stick with the current XT models, but they need the bulkier 4U chassis. The good news is that actually all these models have 16 bit precision, which wasn't clear to me before. Lydia and I will work out what connectors we want on the boxes, and how many modules/channels we need where. Rich also got me in touch with Keith Thorne, who handles the analog I/O Acromag at LLO, and I will ask him for advice. From his documents on the DCC it seems that he is using yet another series: EN. The 968EN-4008 for example is a rail-mounted ADC with pluggable connections, but looses quite clearly in price per channel.

For a generic multipurpose DAQ interface box the ES series is the best approach in my opinion, because it offers a more compact design. We could for example fit 1 ADC, 2 DAC, 1 DIO in a 2U chassis for 32/32/96 channels. The combined price tag for this scenario would be ~\$6k.

12624   Thu Nov 17 21:54:11 2016 JohannesUpdateGeneralAchievable armloss measurement accuracy

I don't like AS110 or AS55. Neither of them are designed for DC and so the DC readout chain is hokey. How about use an actual transimpedance PD with a 100-1000 Ohm resistor and a 3 mm diode? This would eliminate the alignment sensitivity and the drifts due to electronics and room lights.

 This looks much better. I'm planning to take more data with the AS110 PD rather than AS55 when I get the chance, increase the averaging time, and also sigma filter the datapoints. That should get us to a good spot and cut down the uncertainty even further.

12623   Thu Nov 17 15:17:16 2016 gautamUpdateIMCMCL Feedback

As a starting point, I was looking at some of the old elogs and tried turning on the MCL feedback path with the existing control filters today. I tried various combinations of MCL Feedback and FF on and off, and looked at the MCL error signal (which I believe comes from the analog MC servo board?) spectrum for each case. We had used this earlier this year when EricQ and I were debugging the EX laser frequency noise to stabilize the low frequency excursions of the PSL frequency. The low frequency suppression can be seen in Attachment #1, there looks to be some excess MCL noise around 16Hz when the servo is turned on. But the MC transmission (and hence the arm transmission) decays and gets noisier when the MCL feedback path is turned on (see Attached StripTool screenshots).

Attachment 1: MCLerror.pdf
Attachment 2: MCLtest.png
Attachment 3: YarmCtrl.pdf
12622   Thu Nov 17 12:14:21 2016 ranaUpdateCamerasBasler GigE-Camera on Optimus (+Mafalda dead)

Indeed. I suggest discussing with Joe B. I believe we should use a dedicated cam network to get the camera signals from the ends and corner all into one machine. Do not use the main CDS FE network for this since it might produce weird collissions. How about make a diagram, post it to elog, and send link to Joe?

 It may be a good idea to leave the gigecam interfacing up to a dedicated machine.
12621   Wed Nov 16 17:07:12 2016 AshleyUpdateGeneralPreliminary Microphone Data

I am currently looking at the acoustic noise around both arms to see if there are any frequencies from machinery around the lab that stand out and to see what we can remove/change.

• Attachment 1 is a picture of the microphone and suspension system (bungee cords) that hangs from the cable trays to isolate it from vibrations.
• To record data, I used both the microphone (attachment 1) attach it its preamp connected to a spectrum analyzer in order get a graph of power spectral density, recording from 0-10k Hz and 10-100kHz. I started recording data at the furthest end of the x arm and worked towards the center taking measurements every couple of feet (ten rungs on the cable tray).
• The second attachment is the first 5 psd I got from the furthest end of the x arm going 10 rungs on the cable tray closer each measurement.
• Going forward, I am going to take more measurements with greater resolution at the lower frequencies from 0-200 and stepping up from there by factors of 2.

Attachment 1: first_PSD_12kHz.pdf
12620   Wed Nov 16 08:14:43 2016 SteveUpdateLSCDRMI locked on 1f and 3f signals

Nice job.

 Quote: After much trial and error with whitening gains, demod phases and overall loop gains, I was finally able to lock the DRMI on both 1f and 3f signals! I went through things in the following order tonight: Lock the arms, dither align Lock the PRMI on carrier and dither align the PRM to get good alignment Tried to lock the DRMI on 1f signals - this took a while. I realized the reason I had little to no success with this over the last few days was because I did not turn off the automatic unwhitening filter triggering on the demod screens. I had to tweak the SRM alignment while looking at the AS camera, and also adjust the demod phases for AS55 (MICH is on AS55Q) and REFL55 (SRCL is on REFL55I). Once I was able to get locks of a few seconds, I used the UGF servos to set the overall loop gain for MICH, PRCL and SRCL, after which I was able to revert the filter triggering to the usual settings Once I adjusted the overall gains and demod phases, the DRMI locks were very stable - I left a lock alone for ~20mins, and then took loop shape measurements for all 3 loops Then I decided to try transfering to 3f signals - I first averaged the IN1s to the 'B' channels for the 3 vertex DOFs using cds avg while locked on the 1f signals. I then set a ramp time of 5 seconds and turned the gain of the 'A' channels to 0 and 'B' channels to 1. The transition wasn't smooth in that the lock was broken but was reacquired in a couple of seconds. The lock on 3f signals was also pretty stable, the current one has been going for >10 minutes and even when it loses lock, it is able to reacquire in a few seconds I have noted all the settings I used tonight, I will post them tomorrow. I was planning to try a DRFPMI lock if I was successful with the DRMI earlier tonight, but I'm calling it a night for now. But I think the DRMI locking is now back to a reliable level, and we can push ahead with the full IFO lock... It remains to update the auto-configure scripts to restore the optimized settings from tonight, I am leaving this to tomorrow as well...

Attachment 1: 5hrs.png
12619   Wed Nov 16 03:10:01 2016 gautamUpdateLSCDRMI locked on 1f and 3f signals

After much trial and error with whitening gains, demod phases and overall loop gains, I was finally able to lock the DRMI on both 1f and 3f signals! I went through things in the following order tonight:

1. Lock the arms, dither align
2. Lock the PRMI on carrier and dither align the PRM to get good alignment
3. Tried to lock the DRMI on 1f signals - this took a while. I realized the reason I had little to no success with this over the last few days was because I did not turn off the automatic unwhitening filter triggering on the demod screens. I had to tweak the SRM alignment while looking at the AS camera, and also adjust the demod phases for AS55 (MICH is on AS55Q) and REFL55 (SRCL is on REFL55I). Once I was able to get locks of a few seconds, I used the UGF servos to set the overall loop gain for MICH, PRCL and SRCL, after which I was able to revert the filter triggering to the usual settings
4. Once I adjusted the overall gains and demod phases, the DRMI locks were very stable - I left a lock alone for ~20mins, and then took loop shape measurements for all 3 loops
5. Then I decided to try transfering to 3f signals - I first averaged the IN1s to the 'B' channels for the 3 vertex DOFs using cds avg while locked on the 1f signals. I then set a ramp time of 5 seconds and turned the gain of the 'A' channels to 0 and 'B' channels to 1. The transition wasn't smooth in that the lock was broken but was reacquired in a couple of seconds.
6. The lock on 3f signals was also pretty stable, the current one has been going for >10 minutes and even when it loses lock, it is able to reacquire in a few seconds

I have noted all the settings I used tonight, I will post them tomorrow. I was planning to try a DRFPMI lock if I was successful with the DRMI earlier tonight, but I'm calling it a night for now. But I think the DRMI locking is now back to a reliable level, and we can push ahead with the full IFO lock...

It remains to update the auto-configure scripts to restore the optimized settings from tonight, I am leaving this to tomorrow as well...

Updated 16 Nov 2016 1130am

Settings used were as follows:

1f/3f DOF Error signal Whitening gain (dB) Demod phase (deg) Loop gain Trigger
DRMI Locking 16 Nov 2016
1f MICH (A) AS55Q 0 -42 -0.026 POP22I=1
1f PRCL (A) REFL11I 18 18 -0.0029 POP22I=1
1f SRCL (A) REFL55I 18 -175 -0.035 POP22I=10
3f MICH (B) REFL165Q 24 -86 -0.026 POP22I=1
3f PRCL (B) REFL33I 30 136 -0.0029 POP22I=1
3f SRCL (B) REFL165I and REFL33I - - -0.035 POP22I=10

12618   Tue Nov 15 20:35:19 2016 JohannesUpdateGeneralAchievable armloss measurement accuracy

I had a mistake in my script that reported the wrong error after averaging several datapoints, and because I hadn't looked at the individual numbers I didn't catch it so far. Thanks to Gautam it is no more.

The updated numbers are (with fresh, more trustworthy data):

XARM: 21 +/ 35 ppm
YARM: 69 +/- 45 ppm

This looks much better. I'm planning to take more data with the AS110 PD rather than AS55 when I get the chance, increase the averaging time, and also sigma filter the datapoints. That should get us to a good spot and cut down the uncertainty even further.

12617   Tue Nov 15 20:26:35 2016 JohannesUpdateCamerasBasler GigE-Camera on Optimus (+Mafalda dead)

I powered up the existing ace100gm GigE cam with the PoE injector and tried to interface with it as described in elog 4163. After a few initial problems with IP assignment and interfacing I connected it to one of the gigabit hubs and installed the most recent pre-compiled software suite on /opt/pylon5 on optimus, after which I was able to find it with the configuration software. I named it "c1gige_bas100-1" and gave it the static IP address 192.168.113.151.

Afterwards the image acquisition worked without problems.

It may be a good idea to leave the gigecam interfacing up to a dedicated machine. I was thinking I could use Mafalda for this, and also for developing the code for framegrabbing and imager settings, but found that it was dead, burnt at the stake so to say. I guess it wasn't running anything critical, since it wasn't even connected to the network and smelled like burnt electronics. I'll get a replacement desktop for it.

Attachment 1: gige_test.png
12616   Tue Nov 15 19:22:17 2016 gautamUpdateGeneralhousekeeping

PRM and SRM sat. boxes have been switched for some time now - but the PRM sat. box has one channel with a different transimpedance gain, and the damping loops for the PRM and SRM were not systematically adjusted to take this into account (I just tweaked the gain for the PRM and SRM side damping loops till the optic damped). Since both sat. boxes are nominally functioning now, I saw no reason to maintain this switched configuration so I swapped the boxes back, and restored the damping settings to their values from March 29 2016, well before either of this summer's vents. In addition, I want to collect some data to analyze the sat. box noise performance so I am leaving the SRM sat. box connected to the DAQ, but with the tester box connected to where the vacuum feedthroughs would normally go (so SRM has no actuation right now). I will collect a few hours of data and revert later tonight for locking activities....

12615   Mon Nov 14 19:32:51 2016 ranaSummaryCDSReplacing DIMM on Optimus

I did apt-get update and then apt-get upgrade on optimus. All systems are nominal.

12614   Mon Nov 14 19:15:57 2016 JohannesUpdateGeneralAchievable armloss measurement accuracy

Looking back at elog 12528, the uncertainty in the armloss number from the individual quantities in the equation for $\mathcal{L}$ can be written as:

$\delta\mathcal{L}^2=\left(\frac{T_1(1-\frac{P_L}{P_M}-2T_1)}{4\gamma}\right)^2\left(\frac{\delta T_1}{T_1}\right)^2+T_2^2\left(\frac{\delta T_2}{T_2}\right)^2+\left(\frac{T_1(1-\frac{P_L}{P_M}-T_1)}{4\gamma}\right)^2\left(\frac{\delta\gamma}{\gamma}\right )^2+\left(\frac{T_1}{4\gamma}\right )^2\left[\left(\frac{\delta P_L}{P_L}\right )^2+\left(\frac{P_L}{P_M} \right )^2\left(\frac{\delta P_M}{P_M}\right )^2\right ]$

Making some generous assumption about the individual uncertainties and filling in typical values we get in our measurements, results in the following uncertainty budget:

$\delta\mathcal{L}^2\approx\left(12\,\mathrm{ppm}\right)^2\left(\frac{\delta T_1/T_1}{5\%}\right)^2+(0.7\,\mathrm{ppm})^2\left(\frac{\delta T_2/T_2}{5\%}\right)^2+\left(2\,\mathrm{ppm}\right)^2\left(\frac{\delta\gamma/\gamma}{1\%}\right )^2+\left(140\,\mathrm{ppm}\right )^2\left(\frac{\delta P/P}{2.5\%}\right )^2$

In my recent round of measurements I had a 2.5% uncertainty in the ASDC reading, which completely dominates the armloss assessment.

The most recent numbers are 57 ppm for the YARM and 21 ppm for the XARM, but both with an uncertainty of near 150 ppm, so while these numbers fit well with Gautam's estimate of the average armloss via PRG, it's not really a confirmation.

I set the whitening gain in ASDC to 24 dB and ran LSC offsets, and now I'm getting a relative uncertainty in measured reflected power of .22%, which would be sufficient for ~25ppm accuracy according to the above formula. I'm going to start a series of measurements tonight when I leave, should be done in ~2 hours (10 pm) the latest.

If anybody wants to do some night work: I misaligned ITMY by a lot to get its reflection off ASDC. Approximate values are saved as a restore point. Also the whitening gain on ASDC will have to be rolled back (was at 0dB) and LSC offsets adjusted.

12613   Mon Nov 14 14:21:06 2016 gautamSummaryCDSReplacing DIMM on Optimus

I replaced the suspected faulty DIMM earlier today (actually I replaced a pair of them as per the Sun Fire X4600 manual). I did things in the following sequence, which was the recommended set of steps according to the maintenance manual and also the set of graphics on the top panel of the unit:

1. Checked that Optimus was shut down
2. Removed the power cables from the back to cut the standby power. Two of the fan units near the front of the chassis were displaying fault lights, perhaps this has been the case since the most recent power outage after which I did not reboot Optimus
3. Took off the top cover, removed CPU 6 (labelled "G" in the unit). The manual recommends finding faulty DIMMs by looking for an LED that is supposed to indicate the location of the bad card, but I couldn't find any such LEDs in the unit we have, perhaps this is an addition to the newer modules?
4. Replaced the topmost (w.r.t the orientation the CPU normally sits inside the chassis) DIMM card with one of the new ones Steve ordered
5. Put everything back together, powered Optimus up again. Reboot went smoothly, fan unit fault lights which I mentioned earlier did not light up on the reboot so that doesn't look like an issue.

I then checked for memory errors using edac-utils, and over the last couple of hours, found no errors (corrected or otherwise, see Praful's earlier elog for the error messages that we were getting prior to the DIMM swap)- I guess we will need to monitor this for a while more before we can say that the issue has been resolved.

Looking at dmesg after the reboot, I noticed the following error messages (not related to the memory issue I think):

[   19.375865] k10temp 0000:00:18.3: unreliable CPU thermal sensor; monitoring disabled
[   19.375996] k10temp 0000:00:19.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376234] k10temp 0000:00:1a.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376362] k10temp 0000:00:1b.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376673] k10temp 0000:00:1c.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376816] k10temp 0000:00:1d.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376960] k10temp 0000:00:1e.3: unreliable CPU thermal sensor; monitoring disabled
[   19.377152] k10temp 0000:00:1f.3: unreliable CPU thermal sensor; monitoring disabled

I wonder if this could explain why the fans on Optimus often go into overdrive and make a racket? For the moment, the fan volume seems normal, comparable to the other SunFire X4600s we have running like megatron and FB...

12612   Sun Nov 13 23:42:43 2016 LydiaUpdateSUSETMX output matrix data

I took data of the ETMX SUSPOS, SUSPIT and SUSYAW channels while driving each of the 4 face coils. I manually turned off all the damping except the side.

Excitation: I used white noise bandpassed from 0.4 to 5 Hz in order to examine the responses around the resonance frequencies. To avoid ringing things up too much, I started with a very weak drive signal and gradually increased it until it seemed to have an effect on the mirror motion by looking at the oplev signals/sensor RMS values on the SUS screen; it's possible I'll need to do it again with a stronger signal if there's not enough coherence in the data.

Finding the matrix: The plan is to estimate the transfer function of the coil drive signal with the sensed degrees of freedom (specified by the already diagonalized input matrix). This transfer function can be averaged around the resonance peak for each dof to find the elements of the matrix that converts signals to dof responses, (the "response matrix", which is the inverse of the output matrix). Each column of the response matrix gets normalized so that the degrees of freedom influence the drive signals in the right ratio.

Other notes:

• I had some trouble getting the awg python library to work: I had to manually edit a CDLL statement to use the absolute path of an .so file. I wasn't sure what environment variable to set to make it look in the right folder automatically.
• The awg ArbitraryLoop object seems to be affected by cds getdata calls (The EXC signal stopes early and then stop() hangs) so I ended up doing the excitation and data reading in 2 separate scripts.
• Reminder that the watchdogs must be on "Normal" for the EXC signal to make it to the coils, so the damping must be turned off manually with the watchdogs still on if you want to drive without damping.
12611   Sat Nov 12 01:09:56 2016 gautamUpdateLSCRecovering DRMI locking

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

12610   Thu Nov 10 19:02:03 2016 gautamUpdateCDSEPICS Freezes are back

I've been noticing over the last couple of days that the EPICS freezes are occurring more frequently again. Attached is an instance of StripTool traces flatlining. Not sure what has changed recently in terms of the network to cause the return of this problem... Also, they don't occur coincidentally on multiple workstations, but they do pop up in both pianosa and rossa.

Not sure if it is related, but we have had multiple slow machine crashes today as well. Specifically, I had to power cycle C1PSL, C1SUSAUX, C1AUX, C1AUXEX, C1IOOL0 at some point today

Attachment 1: epicsFreezesBack.png
12609   Wed Nov 9 23:21:44 2016 gautamUpdateGreen LockingGreen beat setup on PSL table

I tried to realize an improvement in the mode matching onto the BBPDs by moving the lens mentioned in the previous elog in this thread. My best efforts today yielded X and Y beats at amplitudes -15.9dBm (@37MHz) and -25.9dBm (@25MHz) respectively. The procedure I followed was roughly:

1. Do the near-field far-field alignment of the arm and PSL green beams
2. Steer beam onto BBPD, center as best as possible using the usual technique of walking the beam across the photodiode
3. Hook up the output of the scope to the Agilent network analyzer. Tweak the arm and PSL green alignments to maximize the beat amplitude. Then move the lens to maximize the beat amplitude.

As per my earlier power budget, these numbers translate to a mode matching efficiency of ~53% for the X arm beat and ~58% for the Y arm beat, which is a far cry from the numbers promised by the a la mode simulation (~90% at the optimal point, I could not achieve this for either arm scanning the lens through a maximum of the beat amplitude). Looks like this is the best we can do without putting in any extra lenses. Still a marginal improvement from the previous state though...

12608   Wed Nov 9 11:40:44 2016 ericqUpdateCDSsafe.snap BURT files now in svn

This is long overdue, but our burt files for SDF now live in the LIGO userapps SVN, as they should.

The canonical files live in places like /opt/rtcds/userapps/release/cds/c1/burtfiles/c1x01_safe.snap and are symlinked to files like /opt/rtcds/caltech/c1/target/c1x01/c1x01epics/burt/safe.snap

12607   Tue Nov 8 17:51:09 2016 LydiaUpdateCDSacromag chassis hooked up to PSL

We set up the chassis in 1X7 today. Steve is ordering a longer 25 pin cable to reach. Until then the PSL diagnostic channels will not be usable.

12606   Tue Nov 8 11:54:38 2016 gautamUpdateSUSPRM Sat. Box. looks to be fixed

Looks like the PRM Sat. Box is now okay, no evidence of the kind of glitchy behaviour we are used to seeing in any of the 5 channels.

 Quote: GV Edit 2230 hrs 7Nov2016: The signs from the last 6 hours has been good - see the attached minute trend plot. Usually, the glitches tend to show up in this sort of time frame. I am not quite ready to call the problem solved just yet, but I have restored the connections to the SRM suspension (the PRM and SRM Sat. Boxes are still switched). I've also briefly checked the SRM alignment, and am able to lock the DRMI, but the lock doesn't hold for more than a few seconds. I am leaving further investigations for tomorrow, let's see how the Sat. Box does overnight.

12605   Tue Nov 8 08:51:59 2016 SteveUpdatePEMmouse hole sealed

This is where the mammal came though. It is reach able from room 108 CES

 Quote: We may have a mouse in the lab.  Do not leave any food scrap in trash ! Traps will be set.

Attachment 1: CES108rs.jpg
12604   Mon Nov 7 19:49:44 2016 JohannesUpdateCDSacromag chassis hooked up to PSL

[Lydia, Johannes]

We're waiting on the last couple electrical components to arrive that are needed to complete the acromag chassis, but it is essentially operational. Right now it is connected to the PSL Mephisto's diagnostics port, for which only a single XT1221 A/D unit is needed. We assigned the IP address 192.168.113.121 to it. For the time being I'm running a tmux session on megatron (named "acromag") that grabs and broadcasts the epics channels, with Lydia's original channel definitions. Since the chassis is 4U tall, there's not really any place in the rack for it, so we might want to move it to the X-end before we start shuffling rack components around. Once we finalize its location we can proceed with adding the channels to the frames.

For the eventual gradual replacement of the slow machines, we need to put some thought into the connectors we want in the chassis. If we want to replicate the VME crate connectors we probably need to make our own PCB boards for them, as there don't seem to be panel-mount screw terminal blocks readily available for DIN 41612 connectors. Furthermore, if we want to add whitening/AA filters, the chassis may actually be large enough to accomodate them, and arranging things on the inside is quite flexible. There are a few things to be considered when moving forward, for example how many XT units we can practically fit in the chassis (space availability, heat generation, and power requirements) and thus how many channels/connectors we can support with each.

Steve: 1X3 has plenty of room

Attachment 1: acromag_chassis_location.jpg
Attachment 2: acromag_chassis_top_view.jpg
ELOG V3.1.3-