I have remotely commited a new revision of the h1psliss model that recovers the recent ODC upgrades that were mistakenly wiped out in the most recent revision of that model. The changes are, as in the SVN log, as follows:

• all cdsEpicsOutputs in the h1psliss/ODC block are now cdsEpicsOutLong
• the #DAQ Channels entry in that block now defines CHANNEL_OUT as uint32
• the ‘STATUS’ output in the h1psliss/ODC_ISS block is now cdsEpicsOutLong

After an 'svn up h1psliss.mdl', the model should be rebuilt, reinstalled, and restarted, followed by a daqd restart, which should restore the PSL ODC channels written to frames to a working state.

The RMA replacement of the broken power supply for h1hwinj0 was delivered today. I have installed the PS as the UPS-powered unit in h1hwinj0.

At roughly 10:40 PDT h1iscex stopped running its models with an ADC timout. Rick and the PCAL team were in the VEA at the time, but we could not link any activity with a potential glitch of the IO Chassis. I restarted the system using a full power cycle of both CPU and IO Chassis. We burt restored h1calex from earlier this morning.

Per Jeff Kissel's request Betsy and I (Xavi) looked at several SYS subsystem channels to perform timing checks on the IO chassis.

These checks were in slides by Shivaraj and the slides should be added to this alog and references to the slides added. 

The channels we looked at (shown in the attached green medm screen shot) are:

H1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_1 (Master1)
H1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_2 (Master2)
H1:SYS-TIMING_Y_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 (Y-arm)
H1:SYS-TIMING_X_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 (X-arm)

Two of them are in the Master, one in the y-arm, and the third in the x-arm. It does not appear that any other channels are active at this time.

We took a week of data (in the past of today) for each of these channels and attach figures that show the time series (to check for trends) as well as histograms.  

All in all these plots look reassuring. Notable features:

1) The timing differences between adjacent points are integer multiples of 7.45ns. Mostly the integer is 1 (see Master1TimeseriesDiff.jpg, only posted it for Master 1, others look the same).

2) There do not appear to be significant drifts (e.g. < 50ns for 1 week in Master 1)

3) The spread is about 50ns (shown in figures labeled Histograms)

4) there is ~1 day periodicity in the time series for Master 2

5)  There seem to be common glitches (small ones at the level of ~0.25 us, e.g. see all time series toward the end)

Betsy and Xavi

Elli, Nutsinee

Following LHO alog17941 (PSL accelerometer detected 1Hz glitches) and LLO alog17844 (1Hz peak seen in a magnetometer). Elli left the HWSX camera on from the night of May 16th until the morning of May 18th. I have compared and attached the spectrum from two lock stretches where the  HWSX camera was turned on (May 17th 12:00:00 UTC) and off (May 15th 12:00:00 UTC). There's no evidence of HWS camera at the corner station coupled into DARM at ~45 Mpc.

At LLO, elevated 29-30Hz signal on ground sensors at EndY found the HVAC Fan Frame sitting on a rock.  I checked all I could at LHO and only found a couple things that if they were to move into the wrong spot, they could short out the springs.  I removed what I could and told bubba about what I could not.  Almost because I was unable to open the far west door in the south hallway at the corner station.

Power was interrupted to Comtrol serial adapter, so the EPICS IOC for the weather at end Y needed to be restarted.

EndX has been  transitioned to laser Hazard for Pcal work.

SEI: Getting things back up after AA/AI/IOC work

SUS: EX and EY are back, Jeff will be at EY this morning measuring AI chassis

CDS: All AA/AI boards are swapped

    Power supplies on IO all swapped.

    Some problems overnight to investigate.

    Installing cables at EY.

PSL: Going ot EX to turn on Pcal.

Fac: Moving 3IFO pallet

There will NOT be a safety meeting today

J. Kissel

I'm heading down to the X end to begin measurements of the QUAD's AI and Coil Driver Chassis. I've brought the QUAD to SAFE in prep. No signs of the trouble I briefly saw last night (see LHO aLOG 18519).

As part of the investigation into the cause of the laser trips, I looked at the
status of a few bits of the TwinSafe codes.  This is a rough core dump of my notes
from the session.

    The status screen was red on "Interlock OK".  The following values were recorded
bAmpNPRORunning = 0
bAmpShutterOpen = 1
bAmpShutterClosed = 0
bILOK = 0
bILTwinSafeFBError = 0
bILSoftwareEvent = 1

StandardQX1[0-7] = 11111111
StandardQX2[0-7] = 11100000, this indicates bILDChilFlow, bILXChilFlow and bILDiodeRoomSafetyKeyLock
                             are 1
StandardQX3[0-7] = 00000000
Standard1X1[0-7] = 00100000, this indicates that bILSoftwareEvent is 1 consistent with the
                             above observation
Standard1X2[0-7] = 00000000
Standard1X3[0-7] = 00000000

Seemingly the above suggests that at some point there was a problem with the chiller.
No indication on the chiller of a problem, in fact both chillers were still running.

    TwinCAT indicates that 1 frame (out of many tens of thousands) was lost.  I don't
know if this is enough of a loss to trigger the TwinSafe safety relay or not.

J. Kissel

In order to facilitate studies of the timing systems inside the "important" (i.e. those involved in the DARM loop) IO chassis, I've turned ON the DAC DuoTone Enable switches for the h1susex, h1susey, and h1lsc0 front end computers, i.e. 
EX SUS Front End (h1susex) = H1:FEC-87_DUOTONE_TIME_DAC 
EY SUS Front End (h1susey) = H1:FEC-97_DUOTONE_TIME_DAC
OMC DCPD's Front End (h1lsc0) = H1:FEC-7_DUOTONE_TIME_DAC
which, because all of the 32nd and 31st channels on these chassis' ADC0s are otherwise empty should now pipe the DAC0's DuoTone signal back into ADC0.
Recall that the 32nd ADC0 channel on each front end is that ADC's DuoTone signal it has received from the timing slave also internal to the I/O chassis, e.g. 
H1:IOP-SUS_EX_ADC_DT_OUT_DQ
H1:IOP-SUS_EY_ADC_DT_OUT_DQ
H1:IOP-LSC0_ADC_DT_OUT_DQ
and the 31st ADC0 channel (if the H1:FEC-${DCUID}_DACDT_ENABLE button is ON) is DAC0's DuoTone, e.g. 
H1:IOP-SUS_EX_DAC_DT_OUT_DQ
H1:IOP-SUS_EY_DAC_DT_OUT_DQ
H1:IOP-LSC0_DAC_DT_OUT_DQ
should contain some useful timing diagnostics. Note, the inherent assumption in the system is that if one ADC and one DAC is well synchronized to the timing slave, then all DAC and ADCs in the IO chassis are well synchronized.

Unclear whether we'll ever need to turn these off, so they should probably go into the IOP model's SDF system when someone's more awake than I am right now.

Also -- just because I can't think of a better place to put them at the moment since there're so many open questions, I attach my notes on further data-mining-type Timing System studies that can be done now that Jim has set of the auxiliary timing system check (see LHO aLOG 18384).

J. Kissel

I've recovered FULL ISOLATION on the SEI system at the end station, as well as damped all the SUS. While watching/waiting for the ISI to isolate, I noticed that H1 SUS ETMY's M0 L damping loop output was consistently rather large (was +/- ~700 [ct], where it's normally +/- 1 [ct]). Pulled open a dataveiwer trace, and found the main chain ringing at ~5 [Hz] with consistent amplitude in L. Grabbed a few "quick" spectra in DTT, narrowed down the frequency and to demonstrate the problem for this aLOG....

... and the problem disappeared. I turned on the L, P and Y damping loops after just getting enough data for the "V T R damping loops ON, L P Y damping loops OFF" measurement. And no 5 [Hz] oscillation. All DOF's damping outputs restored to just barely above 1 [ct]. *sigh*

So I'll leave the title up to gather enough attention such that a little forensics can be done, but at least the SEI / SUS at EY pass these superficial, tired Jeff, tests (isolating the SEI system and turning on the damping loops for the SUS).

As mentioned in LHO aLOG 18518, I'm going to come in early again and measure H1 SUS ETMY's AI chassis, but I'll leave the SEI/SUS system in its up-and-running state overnight before I attack.

J. Kissel

I've measured high precision transfer functions of every relevant channel of H1 SUS ETMX's AI chassis today from 10 [Hz] to 100 [kHz]. This was mostly a dress rehearsal because EY wasn't available, but eventually we may be using both QUADs to actuate DARM so we'll need these for calibration accuracy, and this felt like a good time to measure, since the rest of the world was down for upgrades. I'll measure EY tomorrow.

The messages: 
- all channels are functioning fantastically, 
- there is a DC gain of 0.9897 +/- 0.0001 [V/V] on all AI chassis' channels I've measured, 
- the notch frequency is 65883 +/- 374 [Hz], 
- and by 2 [kHz] there's already a 2% drop in gain from that (though we're not surprised by this).
We will use these measurements (well, ETMY's are more important currently, but...) to inform the calibration model.

Attached are several things:
2015-05-19_H1SUSETMX_AIChassis.pdf
Plots of the results, showing the full frequency response from 10 to 1e5 [Hz] and a zoom in on the gravitational wave band.
The last plot shows the data analysis performed to transform the raw data into the final answer -- I measured the full signal chain both with the device under test (DUT) and by-passing it as a reference, and then taking the ratio to find just the DUT's response.

2015-05-19_AIChassis_Measurement.pdf
Diagrams showing the measurement setup. Thanks to the good Dr. O'Rielly for the verbal list of tips/tricks/"gotchas."

2015-05-19_H1SUSETMX_AIChassis_Meast_Pics.pdf
Pictures of the setup to aide the diagram.

Details:
All raw measurements, and results can be found committed to the CalSVN repo here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/ElectronicsMeasurements/

The analysis script which takes out the reference transfer function and makes plots:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/ElectronicsMeasurements/process_H1SUSETMX_AI_Measurements_20150519.m

Of particular interest for the future is the SR785 measurement readout scheme, in which I used a GPIB box configured against a portable wireless router that can access the CDS network (thanks to Elli and Evan for helping me with this). As such, I could run the GPIB measurements from a nearby work-station, and all data retrieval is automatic without the need for clumsy floppy-disk or USB drives. Note that this process uses the latest checkout of the github repo for this stuff maintained by Eric Quintero at the 40m Lab,
https://github.com/e-q/netgpibdata/
which has now been checked out in an "official" location here:
/ligo/svncommon/NetGPIBDataGIT/netgpibdata/
where the key function (for a transfer function measurement) is
/ligo/svncommon/NetGPIBDataGIT/netgpibdata/SRmeasure
and parameter file template
/ligo/svncommon/NetGPIBDataGIT/netgpibdata/SPSR785template.yml
So to take such a measurement, you
- Connect the GPIB to the SR785 and to the wifi router
- Setup of the SR785 "OUTPUT" button to have Destination as "GPIB," GPIB Control as "SR785," and GPIB Address as "[some number]," where "[some number]" is defined in the first few lines of parameter file. 
For this measurement setup, I tried to make the measurement parameters as identical to what I found on the LLO CDS machines in
/data/brian/gpib/configuration.py
where Brian told me to hunt. My configuration file now lives in the CalSVN repo in the same place as everything else for these measurements,
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/ElectronicsMeasurements/TFSR785_AIChassis_Config.yml
thus, to run a given measurement, I can run the following command (assuming I'm in the CalSVN ElectronicsMeasurements directory),
]$ /ligo/svncommon/NetGPIBDataGIT/netgpibdata/SRmeasure ./TFSR785_AIChassis_Config.yml
and ~10 minutes later I get a happy little .txt file export of the measurement from the SR785 in that directory. Sweet!

Using the data from May 17th lock strech where spherical power was stable and the calculation method from alog16558 and alog16579, the estimate power absorbed by ITMX was 390 +/- 40 parts per billion (agrees with what has been previously calculated in alog16603).

The primary source of uncertainty comes from assuming 10% uncertainty in the arm power.

As Kiwamu suggested, I used 3.1% (measured value) for PRM transmissivity instead of 2.97% which is vender's value.

The arm buildup = 1233 cts, recycling gain = 38, CR power to PRC = 19W, power stored in the arm = 102360W, and the absorbed power = 40 mW. Yields the absorbtion in the ITMX coating to be 390 +/- 40 ppb.

Richard, Jim, Dave:

We programmed all the remaining IO Chassis timing slave FPGA's today. In the morning we did MY and EY. This afternoon Jim did all the corner station chassis (SUS, SUSAUX, SEI, PSL, ISC)

We replaced all18bit DAC cards with new firmware versions in: h1susey, h1susb123, h1sush2a, h1sush34. Remaining SUS to do, h1sush56, h1sush2b. We have enough modified cards to do h1sush56 tomorrow, using the one card which fails on autocal* for the OMC DAC.

We had to shuffle some DAC cards around to make space for the new DC power supply. Details will be posted tomorrow.

We powered up all frontends. There is a problem with h1seib3, looks like the 16chan Contec BIO card is not being seen by the front end (it was in the slot we needed to use for the DC power supply). Will fix this tomorrow.

Some FECs have large positive IRIG-B values which will eventually come back down.

* 18-bit DAC card S/N 101208-05 fails its autocal. I replaced its firmware chipset and re-tested on DTS, it still fails. Jeff and Dan H suggest for now we install on h1sush56 for the OMC drive.

Dan, Greg, Jim, Dave:

Dan found that one of the LDAS Q-Logic fiber channel switches is reporting receive errors. These errors correlate to the SATABOY RAID controller reported errors, and in turn to the fw0 restarts.

We first changed which the long-haul single mode fiber optics pair which is used between buildings. Instead of using the first pair of the A-Block, we moved to the first pair of the B-Block. The change was done at 15:00 PDT this afternoon. This did not fix the problem, h1fw0 restarted 50 minutes later and Dan saw errors on the Q-Logic switch.

Following the philosophy of "one change at a time", we are swapping out the single mode fiber optics cable in the LDAS server room which connects to the Q-Logic switch to the LDAS patch panel. It that does not improve the situation we will do the same in the MSR.

Sudarshan, Dave:

After the PSL front end restart following the DC power and FPGA reprogramming, we manually burt restored all four models to 13:10 PDT. The safe.snap files for the PSL most probably should be updated.

Summary

Our current quad distribution scheme for DARM should be compatible with the new low-noise ESD driver. Most of our rms drive to the ESD happens below 3 Hz, so the extra compensation required for the new 2 Hz / 50 Hz pole/zero pair shouldn't cost us anything.

Details

In the ETMY ESD drive we currently have passive filters installed (D1500113), with a pole at 1.6 Hz and a zero at 53 Hz. We digitally compensate for these in the L2L drivealign filter for L3.

If we remove these passive filters and install the new low-voltage driver (D1500016), we will instead have two poles at 2.2 Hz and two zeros at 50 Hz, and we'll compensate these digitally in the same way. So we will effectively have an extra pole around 2 Hz and an extra zero around 50 Hz, compared to what we have now.

I've attached a set of spectra of the ETMY ESD drive in full lock. The blue is our current drive. The red is my projection of the drive we would have if we install the new driver and compensate accordingly. It seems that most of the rms in the drive comes from 3 Hz and below, so the total rms (about 3×10³ ct) won't change much when we change the digital compensation.