Day Ops: 16:00-23:59UTC (08:00-16:00PT)
State of H1: unlocked, locking and making past DRMI, but not to Low Noise
Shift Summary:
Work Today:
Issues encoutered today - locking the X arm in IR:
Environmental deturants to locking:
The HgCdTe photodiodes on the TCS CO2 laser tables have had their calibration updated. The outputs are now calibrated in volts at the PD. I've stored the new calibrations in filter banks, such that both filters need to be turned on to get correct calibration of the channel and no other gain needs to be set.
The DC inputs have:
Filter 1) Convert from counts to volts
Filter 2) Divide by gain of 510 to give voltage at the photodiode
The AC inputs have:
Filter 1) Convert from counts to volts
Filter 2) De-whiten signal. Initial whitening is AC coupled with a pole at 20Hz and a high frequency gain of 105dB. We have reversed this with a filter that has high frequency gain of -105dB, a zero at 20Hz and a pole well below any frequency we care about at 0.01Hz (we didn't put the pole at 0Hz because we don't want this thing integrating continuously).
[Alastair, Aidan]
Attached are some plots of RIN for the X and Y arm lasers. There are now channels in the front end for RIN for in loop and out of loop photodiodes on each table. Here we show the RIN and dark noise for both lasers. The in loop photodiode for the Y-arm table is giving zero response so either there is a problem with it or the beam is mis-aligned. I've only attached the data for the other 3 diodes.
The dark noise is consitent between all three diodes. The RIN of the X-arm laser is approx 5x10^-7 at 20Hz. The Y-arm laser is higher at 2x10^-7. The Y-arm result is similar to the best we measured at Caltech (also attached). It may be that the X arm is lower than we have previously measured due to the low noise enviroment. The spectrums show no excess at low frequency such as would be attributed to air motion on the table, which is good news. Also the in loop and out of loop diodes on the X-table show very similar spectrums which is good for any future intensity noise cancellation.
*****EDIT***** should say Y arm is 2x10^-6 RIN at 20Hz.
Moved electronics to reflect new rack layout for ISC-R3 per D1001426-v10. This is to allow spacing for the new 2 omega auto-centering electronics. Work consisted of moving chassis a few U slots in the rack. All electronics remained on, and no cables were disconnected. Work will continue tomorrow to run field cables from CER to HAM6 racks. This will involve working over HAM6. Fil C. & Ed M. & Daniel S.
Around the same time, we noticed a shift in the dc offset of ASAIR 90 I&Q. Not surprising; we've seen this before when people work in or near the HAM6 rack. Jenne and I adjusted the digital ASAIR 90 I&Q offsets to compensate.
model restarts logged for Wed 27/Jan/2016
2016_01_27 08:39 h1iopsusauxey
2016_01_27 08:39 h1susauxey
2016_01_27 08:41 h1iopsusey
2016_01_27 08:41 h1susetmy
2016_01_27 08:41 h1susetmypi
2016_01_27 08:41 h1sustmsy
2016_01_27 09:05 h1iopsusey
2016_01_27 09:05 h1susetmy
2016_01_27 09:05 h1susetmypi
2016_01_27 09:05 h1sustmsy
2016_01_27 09:56 h1iopsusey
2016_01_27 09:56 h1susetmy
2016_01_27 09:57 h1iopsusey
2016_01_27 09:57 h1susetmy
2016_01_27 09:58 h1susetmypi
2016_01_27 09:58 h1sustmsy
h1susey discovered to have bad 18bit-DAC card, was replaced. h1susauxey accidentally restarted.
model restarts logged for Tue 26/Jan/2016
2016_01_26 10:42 h1tcscs
2016_01_26 10:43 h1broadcast0
2016_01_26 10:43 h1dc0
2016_01_26 10:45 h1tw1
2016_01_26 10:47 h1nds0
2016_01_26 10:47 h1nds1
2016_01_26 11:10 h1sysecaty1plc3sdf
2016_01_26 11:16 h1sysecaty1plc3sdf
2016_01_26 11:18 h1sysecaty1plc3sdf
2016_01_26 11:20 h1sysecaty1plc2sdf
2016_01_26 11:24 h1sysecaty1plc2sdf
2016_01_26 11:25 h1sysecaty1plc1sdf
2016_01_26 11:43 h1sysecaty1plc1sdf
2016_01_26 11:48 h1sysecaty1plc2sdf
2016_01_26 11:52 h1sysecaty1plc2sdf
2016_01_26 12:09 h1sysecaty1plc2sdf
2016_01_26 12:14 h1sysecaty1plc3sdf
2016_01_26 14:40 h1pemcs
2016_01_26 14:42 h1oaf
2016_01_26 14:44 h1dc0
2016_01_26 14:44 h1nds0
2016_01_26 14:44 h1nds1
2016_01_26 14:44 h1tw1
2016_01_26 14:45 h1nds0
2016_01_26 14:46 h1broadcast0
2016_01_26 14:46 h1nds0
2016_01_26 14:47 h1nds0
2016_01_26 14:48 h1nds1
2016_01_26 14:51 h1nds1
2016_01_26 14:52 h1nds1
2016_01_26 14:53 h1nds0
Tuesday maintenance. New TCS model, testing new Beckhoff SDF code (was backed out), pem-oaf change to drive audio to control room. Associated DAQ restarts, multiple NDS restarts due to monit/testpoint.par problems.
model restarts logged for Mon 25/Jan/2016 No restarts reported
Using the noise injections I performed yesterday night, I could check that the coupling of DHARD picth to DARM is mostly linear and stationary.
In the attached plot:
What can we learn from this plot?
The second attached plot hows the transfer function between DARM_OUT and DHARD_P_OUT. It's quite flat and feature-less, except for the bounce and roll mode notches. This suggests to me that we could reduce the DHARD pitch coupling by adjusting the differential gain of ETMX and ETMY P2L to minimize the noise coupling.
Alastair, Aidan, Patrrick, Carlos, Jim, Dave:
Wednesday afternoon we ressurected the TCS FLIR cameras which reside on the X and Y arm TCS tables in the LVEA. We re-discovered that TiVo and Cyrus had done most of the installation work already on this system and we just needed to complete the network hookup and permit remote access to the software running on the windows server.
We verified that the Beckhoff control of the camera's power supply was working correctly.
The cameras have the network names h1flircam[x,y] the windows server is h1tcsflir. The server is running Windows7 and the flir camera software provided by the vendor (licenced via a usb dongle).
In the MSR, the gigabit ethernet cable runs from the camera to a punch through on the wall of the table enclosure. From there both X and Y cables run over to the rack by HAM4 and plug into the first two of the four port ethernet patch panel. The other end of the patch panel are ports 49-52 in the CER. We installed two short patch cables from patch ports 49,50 into the Cisco switch using switch-ports 12,14 for camera X and Y respectively.
Carlos worked on allowing user controls to remote desktop from any CDS workstations to the h1tcsflir server.
0915 -0955 hrs. local -> To and from X-end Pump won't start on either HV channel, gets to 500V then limits at 500ma -> Tempted to increase the default arc limit of 10 per minute but will consult with GammaVacuum first
1020 - 1040 hrs local -> To and from X-end Consulted with Gamma Vacuum -> They advised not exceeding 20 arc/min setting -> I tried 15 - no help -> I also unplugged the HV cable from the controller but left the SafeConn connector connected and then enabled the HV which then came up to 7500V without a problem - meaning the controller is likely OK - more to come
What type of HV cable is in service? Gamma's cable or RG58 RED? Did you pull both types of cables to have one as a back up?
While in the CER preparing for some oscillator coupling measurements, I noticed that the spare EOM driver had its input turned off, and the power supply was in standby mode. Since the input switch was turned off, I assume this was intentional and followed the instructions on the sticky note for unplugging the input from the distribution amplifier.
Injected some broad-band noise in DHARD pitch, with a shape tailored to match closely the error signal above few Hz. Analysis will follow tomorrow.
Noise shape:
zpk([0;0;-6.2832-i*25.1327;-6.2832+i*25.1327;-6.2832-i*25.1327;-6.2832+i*25.1327;37.6991-i*62.8319;
37.6991+i*62.8319;37.6991-i*62.8319;37.6991+i*62.8319;-157.0796],
[-3.1416-i*5.0265;-3.1416+i*5.0265;-6.2832;-4.3982-i*18.8496;-4.3982+i*18.8496;-4.3982-i*18.8496;
-4.3982+i*18.8496;-6.2832-i*18.8496;-6.2832+i*18.8496;-6.2832-i*18.8496;-6.2832+i*18.8496;
-251.3274],1)
gain(0.0115462)cheby1("LowPass",4,1,100)
ampl 300
1137997278 Wed Jan 27 22:21:01 PST 2016
1137997409 Wed Jan 27 22:23:12 PST 2016
ampl 600
1137997432 Wed Jan 27 22:23:35 PST 2016
1137997556 Wed Jan 27 22:25:39 PST 2016
ampl 900
1137997581 Wed Jan 27 22:26:04 PST 2016
1137997706 Wed Jan 27 22:28:09 PST 2016
ampl 2000
1137997738 Wed Jan 27 22:28:41 PST 2016
1137997884 Wed Jan 27 22:31:07 PST 2016
We just had another lockloss due to coil driver switching. This is a problem that has been with us since ER8 (also 20305) I filed my first FRS ticket, which I accidentally sent to LLO Detector engineering 4303
We also have had a number of other locklosses tonight.
One interesting one was that when we locked with a low recycling gain, our roll mode damping seemed to cause the mode to ring up. As far as I know, this is the first time this has happened here, although LLO people have complained about this. It is plausible that our spot position moved and the coupling to DARM changed sign. After Jim and I redid inital alingment Jenne was able to damp this mode using the old gains, which we have been using for almost a year now.
We also had 2 locklosses tonight due to wrong settings on ETMY ESD, we used our new down.snap to hopefully avoid any more wrong settings.
We also had 2 locklosses due to ASC coming on when the recycling gain was low. (both fixed by doing inital alignment)
H1 has 30 sender RFM channels on each arm, of which only 26 have corresponding receiver(s). So 4 are being sent and no model is using the data.
L1 has 29 senders on the X-ARM (of which there are 26 receivers), and 30 senders on the Y-ARM (of which there are 26 receivers).
So the two sites are very close in number of sending channels.
Analysis details: The base number of potential senders was derived from the main IPC file, looking for RFM0 and RFM1 ipc types. This resulted in 30 for H1-X and H1-Y, and 42 for L1-X and L1-Y. Because the ipc file is only appended to during compilation, if it has not been cleanly regenerated recently it may overcount the number of sending channels.
For each channel, I searched the models' RCG generated IPC_STATUS.adl medm file for the channel name (e.g. H1LSC_IPC_STATUS.adl). Assuming that no two ipc channels share the same name, if I found the channel name in the adl file this means it is a running sender with a receiver. For the remaining possible senders without receivers (H1-X=4, H1-Y=4, L1-X=16, L1-Y=16) I looked for the channels in the top level simulink source files (e.g. /opt/rtcds/userapps/release/*/l1/models/l1*.mdl). This showed that all four channels on H1-X and H1-Y do have sending models, and for L1-X 3 of the 16 had sending models, and for L1-Y 4 of the 16 had sending models.
If we can possibly remove some of the RFM channels which are not being received, additional RFM channels can be added to the loop with no risk.
For H1 the sending channels with no receivers are:
Tagging people interested in adding new (or rather, trading for) RFM channels. SEI: IFO Basis SEI channels CAL: Sending PCAL excitations to the corner.
Dave, Thanks for the count. For the SUSpoint motion in the IFO basis, (see ECR E1600028 , or Integration Issue 1193 , or Tech Doc T1500610 ) we need 2 RFM channels, 1 per arm for the ETMX SUS-WIT and ETMY SUS-WIT each to OAF in the corner. For completeness, I note that we also need some PCIe channels from the top level of other 12 suspensions (3 IMCs, 3 SRMs, 3 PRMs, BS, ITMX, ITMY). These can replace the GS-13 X/Y signals now being used by OAF. Evidently the RFM senders for these are living in the PEM model at LLO. I do not know why it is done this way, but it may be related to the configuration of the FE machine for ISI at LLO. ALSO (1) : for more complete monitoring, it would be useful to also send the STS-2 X/Y signal from the end to OAF. ALSO (2): For Earthquake common mode control (still hypothetical) we would need to send the End X or Y STS-2 to the corner, and ALSO send the corner X/Y out to the ends. Summary of RFM: 1 per arm from SUS to OAF (high priority) 1 per arm from ISI-GND to OAF (med priority) 1 per arm from GND-ITMY X to End X and ITMY-Y to End Y (med priority) NOTE- these signals don't need to be 16k. We want accurate data at 1 Hz and below, so 512 sample/sec would be fine. Thus, it is not crazy to think about ways to de-stress the RMF system (e.g. interleave several slow channels on one fast RFM connection, or something like this.)
The cooling system failure at the H-2 electronics building (FRS 4271) was due to a defective flex joint in the line set from a outdoor unit compressor to the building. The flex joint has been replaced and the line set and compressor are being drawn down. There will be a small vacuum pump running near the outdoor units throughout the night. If there are no more leaks, the unit will be recharged with gas and back running tomorrow. The vacuum pump will run unattended, however, if there are any issues with the running of the pump, please do not hesitate to call me. The commissioners have been apprised of this also.
1545 - 1605 hrs. local -> To and from Y-mid Next CP3 over fill to be Friday, Jan. 29th before 4:00 pm
State of H1: realigned and relocking and currently between DRMI and Engage ASC
Shift Details:
Looking at the problems from last night I began looking at the ESD this AM. Noticing that the main read back for driver was flickering on and off I by-passed the LV driver and looked only at the HV driver. It was obvious the DC bias was not present. Hoping it was not the Driver itself looked at the incoming DAC channels and all functioned except the DC bias channel. Tracked it down to the output of the IO chassis. Filiberto replaced the 18bit DAC, ribbon cable and interface card. This cleared up the issue. While working on this noticed the ESD can get into some odd states when the on/off switch is pressed. I think we still have some binary issues that latch the unit up. Was able to clear the problem by going to the BIO screen and changing states.
Boards removed: Interface Card - S1000865 18bit DAC - 101208-39 Boards Installed: Interface Card - S1500234 18bit DAC - 101208-11
Updated the corner TwinCAT system to the most recent svn. This includes the changes needed for adding the ASC-AS_A/B.RF90 channels.
The new AS_B.RF90 demod channels won't be active until the corner 4 chassis is upgraded. The AS_A.RF90 demod channels have been taken over from the old (now deleted) AS_D. Whitening channels for both AS_A and AS_B are working.
Added whitening screens for AS_A/B_RF90 to ISC-CUST_WHITENING_OVERVIEW.adl
Added related screen buttons for AS_A/B_RF90 to ASC_OVERVIEW.adl
Evan, Kiwamu,
As some of us have already noticed, there is a broadband noise with a 1/f^{0.5} shape in frequency from 60 to 200 Hz. This noise is unidentified.
Do not believe any statements in this report until futher analaysis. Something is fishy with the claibration of the cross-spectrum.
We are planing to check how stable this noise level is over the course of the entire O1.
The below shows an example spectrum of DARM.
Blue curves are twenty spectra of DARM (aka C01 frame, converted into displacement), each of which is made by the Pwelch with Hanning, detrended, 50% overwrap for a 12 minutes time series. The data starts at a GPS time of 1134604817. Green curves are the square-root of twenty cross-power-spectra of DCPD A and B which are reconstructed from the sum and null streams of the DCPDs. The DARM suppression effect was removed from the sum signal. The cross-spectra are then calibrated to the displacement using the latest O1 DARM model of the calibration group. No time varying correction (i.e. kappas) is applied. Red line is a 1/f^{0.5} line to show how steep the slope of the green curves is. I also attach the fig file.
Gabriele, Evan, Kiwamu
There was a human-error in my code for calibrating the cross-spectrum. It was removing the loop suppression after the power spectrum of the null stream was subtracted from that of the sum stream. This was fixed such that the subtraction happens after the removal of the suppression in the sum spectrum. The below is the latest plot.
The plot shows the ampitude spectral desnsities of the calibrated darm displacement (aka C01) and the calibrated cross-spectrum. The cross-spectrum should represent noises which are coherent between two OMC DCPDs.
As a coarse verification, I have eye-ball-fitted the shot noise level with the fixed cavity pole frequency of 341 Hz (shown as a dotted line in cyan). Then I subtracted the shot noise component quadratically out from the actual displacement spectrum (in black). The residual (in blue) agrees with the estimation from the cross-spectrum. In order to check the slope of the cross-spectrum, I also drew a 1/f line. The cross-spectrum seems to follow 1/f from 50-ish Hz to 150 Hz.
The fig file is attached as well.
An update can be found in entry 25106
A higher resolution version is attached. The frequency resolution is set to 0.1 Hz, 50% overlap with Hanning for 1 hour data. No new findings.
The 1 Hz comb feature (see for example alog 24695) is becoming visible in 20-50 Hz. By the way, the legend in the plot is wrong.