I had queued up the DAQ changes needed for the extenal EDCU:

• stop running "epics dcu" on h1dc0
• remove all EDCU ini files from master, replace with H1EDC.ini

These changes have been reverted out of the DAQ for now.

Jonathan, Dave:

We found the error, I had introduced a bad carriage return in the edcumaster.txt file, and I remembered Keith alogging that any spaces in this file is bad. I fixed the file and restarted h1edc. Initially it was not connecting to the 3,404 guardian channels, and when guardian was started h1edc connected to the full list of 40,069 epics channels.

We will schedule a DAQ restart to switch from internal to external EDCU at the next target-of-opportunity.

I tracked the crash point down in the code.  See CDS bug 1136.

Repeating the measurements done in alog 47345, we find significant improvements. We now have good coherence between CTRL and SLOW for most of the frequency range. Due to the pole at 500 Hz the SLOW readback runs into quantization noise above 15 kHz. The ERR signal readback also has much better coherence. Between 10 and 100 Hz it seems limited by the  voltage noise of the first boost stage.

The line at ~14 kHz dominates the rms.

And here is the low frequency version.

Here are the plots for the IMC servo. The faster OpAmps also improved the IMC-F and IMC-L readbacks. The IMC_I readback shows flat noise at a relatively high voltage level. It may be limited by out-of-band noise.

First plot show current readbacks compared to the old ones.

Second plot shows the raw input signals in counts. There seems to be some excess noise between 10 and 50 Hz in IMC-F. Maybe a glitch here since the next plot looks different.

Third plot shows a full bandwidth spectrum. MC-F approaches the quantization noise between 1 and 20 Hz.

Looking back at O2, we parked the DIFF and COM VCOs at 78.786600 MHz and 78.7990 MHz, respectively, while the IMC VCO was running around 79.135 MHz.

During the last lock, we parked the DIFF and COM VCOs at 78.786600 MHz and 78.7990 MHz, respectively, while the IMC VCO was running around 78.786 MHz. The IMC VCO frequency was changed around 3/2/2019. No obvious alog.

The parking positions are unchanged, whereas the IMC VCO has moved down in frequency on top of the parking positions. This is bad! The IMC VCO needs to move ~350 kHz up in frequency.

Set the IMC-VCO_TUNEOFS to -1.7 V which puts the frequency back to 79.2 MHz.

Additional clue: there are small but noticeable changes in comb strength in a couple magnetometer channels at EX, in the same time frame. I'm not seeing anything similar in EY or CS mags. (The 1-Hz comb is present in many magnetometers; it's the change points that seems to be unique to EX.)

Hey all, 

This looks similar to what we have seen in the past from the hartmann wavefront sensor cameras. It seems like we solved the issue by changing the camera power supplies.  We can double check this by changing the HWS sync frequency at low noise and provide you with a gps time. 

Sheila, Anamaria

The first thing that comes to mind from last Tuesday is a change to the ESD driver grounding at EX (47308), which did reduce some coherence between EX magnetometers and DARM (47323)  At first it looked like this work last tuesday removed a line at 73 Hz from DARM, although looking at the summary page you can see that this line has been coming and going and was at 72.5 Hz yesterday. summary page

It's probably not the HWS because those were always showing up a few tenths of a percent below their sync frequency, so if this comb is within half a mHz it's too accurate.

Ok, I'm posting more detail on what I'm seeing in the magnetometers, in case it helps to pin this down. I've checked for any obvious/clear change points, and also compared whether the shape of the comb is similar to what's observed in DARM (same pattern of variation in peak heights). In summary, SEIRACK and SUSRACK magnetometers at EX are particularly notable.

Also, the comb does appear to be precisely on 1 Hz, unlike the HWS comb.

Detailed magnetometer report:

[Corner station]
H1:PEM-CS_MAG_EBAY_LSCRACK_*_DQ: no apparent change; comb shape dissimilar from what is observed in DARM
H1:PEM-CS_MAG_EBAY_SUSRACK_*_DQ: no apparent change; comb shape dissimilar
H1:PEM-CS_MAG_LVEA_VERTEX_*_DQ: comb not really present

[End X]
H1:PEM-EX_MAG_EBAY_SEIRACK_X_DQ: changed (decrease); comb shape similar
H1:PEM-EX_MAG_EBAY_SEIRACK_Y_DQ: no apparent change; comb shape similar
H1:PEM-EX_MAG_EBAY_SEIRACK_Z_DQ: changed (increase); comb shape similar (?)

H1:PEM-EX_MAG_EBAY_SUSRACK_X_DQ: changed (increase); comb shape similar
H1:PEM-EX_MAG_EBAY_SUSRACK_Y_DQ: no apparent change; comb shape similar
H1:PEM-EX_MAG_EBAY_SUSRACK_Z_DQ: changed (decrease); comb shape similar (?)

H1:PEM-EX_MAG_VEA_FLOOR_*_DQ: comb not really present, but neither is anything else. These channels look way too clean; there might be an issue.

[End Y]
H1:PEM-EY_MAG_EBAY_SEIRACK_*_DQ: no apparent change; comb shape similar
H1:PEM-EY_MAG_EBAY_SUSRACK_*_DQ: no apparent change; comb shape similar
H1:PEM-EY_MAG_VEA_FLOOR_*_DQ: no apparent change; comb shape similar (?)

Robert, Anamaria

Even with just 0.01 Hz resolution, there is large coherence between various magnetometers in the EBAYs and DARM. Indeed this was not the case before last Tuesday.

Separately, the 72.5 Hz that appeared in the last two days is coherent with the corner EBAY magnetometer in the ISC rack. We think it's a real peak because if the sensor were picking up DARM the large calibration lines at 35ish Hz would show better coherence. Though it does not appear to be there this morning, so not completely clear what's going on.

Danny and I had a 72.33 Hz line driving some frequency noise over the weekend during some TCS tests. We also had lines at 3.25kHz, 4.5kHz and a bunch around 23-25Hz.

Shifted ETMX HWS sync frequency from 1 Hz to 5 Hz starting at 1236485181 and shifting it back to 1 Hz at 1236494796.

What about the GPS clocks that got turned on last Tuesday?

I had trouble finding a lot of clean DARM data during the period when the HWS frequency was changed, but what I found suggested the 1-Hz was still strong. Figure 1 is from when the HWS frequency was normal. Figure is from when it was changed.

The 1 Hz comb is still present in data from the third week of ER14, see first attached plot. There is also a very bad 0.8 Hz comb visible between 420 and 500 Hz, see second plot.

The 0.8 Hz comb Pep noted is a complicated structure, but it has some symmetrical features which are centered on the 516.78 Hz line. Keith tells me this is an EX violin mode (alog 47650, alog 47179).  A plot showing data from March 25 is attached.

It seems that the work reported in https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=47766 has made the 1 Hz comb disappear.

The first attached plot shows the spectra before this change, and the second one the spectra after this change.

On the other side, the lines and 0.8 Hz comb around the ~500 Hz violin modes are still there.

   When I came in at 14:20 (07:20) the IFO was locked at NLN. Despite snow blowing and operation of the frontend loader around OSB, the IFO was noisy but remained locked. At 14:36 (07:36)the HAM1 ISI tripped and the IFO remained locked. The IFO did not lose lock until 15:31. 

This feels reminiscent of the Hartmann wavefront sensor camera refresh rate.  Team TCS is going to look at this as soon as they are finished with their currently-ongoing maintenance tasks.

EDIT: Never mind, Danny looked, and all of the refresh rates are correctly set to be much lower frequency than this.

Rich verbally confirms that he and Peter used the measurement setup as described in LHO aLOG 47225 and D1900027, using the coil driver test box as a differential driver. They *did not* gather the test setup's transfer function, however, so this will need to be done in order to analyze the data (attached above, DCPD_Whitening_v2.zip) to the desired precision. Also note that details of the measurement files can be found on the last page of the DCPDWhiteningChanges.pdf attachment.

Also -- I opened (and subsequently closed) FRS Ticket 12453 covering the problem of "changes in frequency response as a result of input signal level" that the solution in this aLOG fixes.

Since this issue will likely impact LLO as well, I've opened up an integration issue,  IIET Ticket 12454, such that the above mentioned change becomes an ECR to be implemented at LLO as well (assuming they have the same problem).

Updated the FM1,FM2,FM3 whitening compensation filters for PDA and PDB.
They are now matched at the +-0.15% level (see plot).
And we verified that they are no loner offset dependent.

Also, to be explicit: We disabled the 12dB, 6dB and 3dB whitening gain steps in both PDA and PDB. The 24dB step is still operational.

The new foton filters are:

PDA:
FM1: zpk([10.44],[0.996],0.9734,"n")
FM2: zpk([49.63],[497.5],-0.9995,"n")
FM3: zpk([10.372],[0.9865],1.002,"n")

PDB:
FM1: zpk([10.160],[0.969],0.975458,"n")
FM2: zpk([49.72],[497.7],-1.0004,"n")
FM3: zpk([10.467],[1.000],.9973,"n")

Using this filter, we injected pink noise into both DCPDs, and plotted the PD ratio in various configurations to verify the filter compensation. Specifically, plotted are:

A(FM1,FM2,FM3)/B(noFM)
A(FM1,FM2,FM3)/B(FM1,FM2)
A(FM1,FM2)/B(FM1,FM2)
A(FM1)/B(FM1)
A(FM1)/B(noFM)
A(noFM)/B(noFM)
A(FM1,FM2)/B(FM1)
B(FM1,FM2)/A(FM1) (opposite rat!)

The xml file with the data in the plot is in /ligo/home/controls/sballmer/20190303/DCPDfinal.xml

Finally, we still will have to re-match the photo diode light levels in lock (alog 47217).

All this was done to fix the problem identified in alog 47247.

Attached are plots of

- Transfer function wit- over-without offset. The insanity is indeed gone.

- PDA: FM1, FM1FM2, FM1FM2FM3 - all normalized with their compensation filter.

- PDB: FM1, FM1FM2, FM1FM2FM3 - all normalized with their compensation filter.

In short: the current compensation is good at the 0.02dB level. One could still improve it...

The plotting MATLAB code is here: /ligo/home/controls/sballmer/20190304/DCPD

I've moved the contents of Stefan's results from his home directory on the local file system into the calibration SVN (though I've not yet modified his plotting script for the new directories and/or to spit out the right file names).

I used the follow commands to do so:
Data:
    cd /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Data/OMCWhiteningChassis/2019-03-04/
    cp /ligo/home/controls/sballmer/20190304/DCPD/SRS00* ./
    cp /ligo/home/controls/sballmer/20190304/DCPD/srs00* ./
    cp /ligo/home/controls/sballmer/20190304/DCPD/47254_20190303213* ./

Script:
    cd /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Scripts/
    cp /ligo/home/controls/sballmer/20190304/DCPD/plotData.m plot_omcdcpdwhiteningmods_20190304.m

Results:
    cd /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Results/OMCWhiteningChassis/
    cp /ligo/home/controls/sballmer/20190304/DCPD/PD*.png ./
    rename 's/PD/2019-03-04\_H1OMC\_WhiteningChassisTFs\_PD/' PD*.png

Thus the new script name to plot the data is:
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Scripts/plot_omcdcpdwhiteningmods_20190304.m

which should be modified to analyze the following data:
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Data/OMCWhiteningChassis/2019-03-04/
        SRS00*.78D
        srs00*.asc
using the notes in the file
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Data/OMCWhiteningChassis/2019-03-04/
        47254_20190303213544_DCPDWhiteningChanges.pdf

and to produce plots and results with similar file tags as
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Results/OMCWhiteningChassis/
        2019-03-04_H1OMC_WhiteningChassisTFs_PD*.png
(or the code should be re-written to use your favorite fitting code [maybe in python using IIRrational] and produce plots and results with similarly explicit file names with indications of the date, the interferometer, and WhiteningChassisTFs in the file name.)

Lilli S.,

First, I have renamed the data files in dir /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Data/OMCWhiteningChassis/2019-03-04/, so that they match what is described in note /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Data/OMCWhiteningChassis/2019-03-04/47254_20190303213544_DCPDWhiteningChanges.pdf

The test box has been factored out. (Test box data: /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Data/CoilDriverTestBox/S1900070/)

The fitting script is /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Scripts/fit_OMCDCPDWhiteningChassis_20190304.py 

The results are in the table below. The fitting plots are in the attachments.

The low-freq poles/zeros roughly match Stefan's results. In O1 and O2 we used 1 stage of whitening (FM1), and the high freq poles were at [(14.34e3 + 14.60e3)/2, (18.68e3 + 18.57e3)/2, (98.94e3 + 100.45e3)/2] Hz. The new fitting for FM1 is consistent with O1 and O2.

Take PDA FM1FM2FM3 noDC as an example, manually build TF by removing the high-freq zeros, and plot the residual -> see diff.pdf 

By ignoring the high-freq zeros, there's little impact on magnitude, but there's phase difference at higher freq (~<1 deg below 5k Hz).

Concluding from the results of the fit above, I'll be updating the calibration model parameters to change from the previous measurement of the DCPD whitening chassis (before O2, when the nominal configuration was to only have the first stage of whitening -- "F1" or "FM1" -- on; see LHO aLOG 28087) from 
                          PDA            PDB              PDA          PDB             PDA            PDB
    uncompOMCpoles_whitening = [(14.34e3 + 14.60e3)/2, (18.68e3 + 18.57e3)/2, (98.94e3 + 100.45e3)/2];
to the new fitted measurement results, and choosing the new nominal configuration, with all three filters on (the 1st and 3rd stages, which are whitening and the 2nd stage which is a low pass, i.e. "FM1FM2FM3" or "3 filt"), and using the 5 V_DC offset fit results because it's more representative of the nominal running conditions of the chassis (with the poles rounded to the nearest Hz) 
                          PDA            PDB               PDA             PDB                 PDA             PDB
    uncompOMCpoles_whitening = [(11.346e3 + 11.521e3)/2, (32.875e3 + 32.863e3)/2, (32.875e3 + 32.863e3)/2];

Lilli S.,

The residual contribution plot is attached. This was generated using /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Scripts/fit_OMCDCPDWhiteningChassis_20190304-vsOriginal.py

(based on reference model modelparams_H1_20190118)

The results is averaged after using different poles/zeros in PDA and PDB, instead of using the same set of averaged poles/zeros in PDA and PDB.

Per Jeff's request that the original DCPD files be included, I am attaching the data extending down to 0.5Hz for the OMC DCPD Whitening chain as taken on the floor by signal injection into the front panel of the Split Whitening Chain via an SR785

Attached are two plots:

A) The comparison of TFs:

1. All low-freq z:p + high-freq p + out-of-band z from IIRrational fitting

2. Dead reckoned z:p = [500, 1, 1]:[50, 10, 10]

3. Low-freq z:p from Stefan's fitting in 47257

4. Low-freq z:p from Stefan's fitting in 47257 + high-freq p from IIRational

B) The comparison of contribution residuals, by using the latest H1 model 20190301

The scripts live in

/ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Scripts/fit_OMCDCPDWhiteningChassis_20190304-compareTF.py

/ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Scripts/fit_OMCDCPDWhiteningChassis_20190304-compareRes.py