Craned 3IFO TCS chiller to west bay (because Jodi said it really needed to be over there). I inspected the rigging in the LVEA while in there this morning. All good. I checked the flow of nitrogen too all of the LTS containers in the LVEA. All have good flow rates. Checked the electronics room air handler filters, they were O K however there was a fault on the system. One of the outdoor units of the split system had tripped a breaker. I reset the breaker and thermostat and cleared the fault. All units are functioning. Report of lights not working in the OSB kitchen, found some burned out bulbs and some defective fixtures. New fixtures on order.
Attached are the plots for the temperature and relative humidity data from the month of August from the two dry boxes and the desiccant cabinet. All plots show normal operations for the past month.
In this morning, I checked the OMC DCPD electronics chain (for both A and B) by injecting known sine wave analog signal. This was one of those items that Keita suggested me a while ago.
According to the data, I am concluding that our calibration model needs to add another pole at 10-ish kHz for accurately simulating the OMC whitening circuits.
Method
The measurement method is straightforward -- it is a swept sine measurement in a manual way.
I had a function generator by the HAM6 electronics rack which drove a single-ended-to-differential convertor (D1000931, technically speaking this is a coil driver test box). Then the differential signal is sent to the input of the OMC DCPD whitening board (D1002559, S1101603) by some clipping technique. By the way, the actual cable for connecting the OMC DCPDs were unplugged during the measurement. The excitation amplitude was set to 2 Vp-p at the function generator which resulted in 2 Vp-p in both positive and negative paths at the input of the whitening board as expected accroding to the schematic of the coil driver test box.
I then recorded the data in IOP at the full sample rate using dataviewer for 1 sec for a selected excitation frequency (and for some reason, diaggui did not want to run and hence dataviewer this time). Keeping the same excitation amplitude, I manually stepped the freqyency from 8 kHz to 100 Hz. After every step, I saved the time series of the IOP so that I can make a transfer function later. In addition, I had an oscilloscope with me which kept monitoring the excitation ampitude at the input of the whitening board. The scope told me that the excitation ampltude stayed constant at 2.02 Vp-p in each channel throughtout the measurement. The OMC DCPD had
Analysis and result
To get a transfer function from the data that I took in time series, I decided to do a sine-wave fitting for each data chunk to get the amplitude information. I wrote a small matlab script to do it. It can be found at:
aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Matlab/OMC_DCPD_AnalogChain_TimeSeries.m
The script utilizes fminsearch and spits out the best fit amplitude for each frequency measurement. Additionally, it places uncertainty or error bar by taking the standard deviation of the residual. Note that this is not a standard way to place an error bar since it does not take the number of measurement points into consideration. According to the fit, the residuals were found to be usually a few counts which is much smaller than the amplitude of signals which was about 2000 counts. So it typically places 0.1% uncertainty after all.
The result is shown in the attached pdf. By the way the lower panel in the plot says, "residual", but it should read "(measured)/(model)" instead. It shows the measured transfer function together with the expected model transfer function for comparison. It is very obvious that the measurement suggests that our model is missing some high frequency pole. The model is merely made of the analog AA response which I have already measured and fitted. Adding some random pole, I could see an extra pole at around 10.7 kHz making the fitting much better. In fact, I sort of knew that there seemed to be a high frequency pole by some other measurements which I did not post. We probably need to add this high frequency pole in our calibration model.
I have measured and fitted the AA filter response for DCPD A and B (ch13 and ch14 of S1102788 respectively). I used the same coil driver test box to produce differential signal and measured the transfer functions with SR785. The results don't show any unexpected additional high frequency poles.
The plots are shown below in line. The fitting is good up to 10 kHz.
The fitting code can be found at:
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_AA_OMC_DCPD_A.fil
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_AA_OMC_DCPD_B.fil
The analysis/plot code can be found at:
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/python/OMC_DCPD_AA_filters.py
The figures in both pdf and png formats are available at:
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_AA_DCPD_A.pdf
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_AA_DCPD_A.png
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_AA_DCPD_B.pdf
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_AA_DCPD_B.png
Independently of the above measurements, I have measured the entire signal chain of the OMC DCPD A and B by injecting random signals from the extra DAC output in LSC (a.k.a. LSC-EXTRA_AO2).
It also showed a high frequency pole at around 10.7 kHz which is consistent with the result from the manual swept sine described above.
Measurement setup
By the way, in the digital world particularly in the IOP world, LSC-EXTRA_AO2 is called DAC0_CH9, and DCPD A and B are called ADC0_CH12 and CH13 respectively.
AI filter for LSC-EXTRA_AO2 needed to be measured
Since this measurement automatically includes the AI filter for LSC-EXTRA_AO2, we need to subtract this transfer function out of the resultant measurement. So I measured and fitted it (ch10 of S1102761) by using the coil driver test box (D1000931) and a SR7850. Here is the result.
As shown in the plot above, the fitting is good up to 10 kHz. I did not see unexpected high frequency pole. The fitting code, data and results can be found at:
/aligocalibration/trunk/Runs/ER8/H1/Measurements/AAAI/LSC_EXTRA_AO_AI_v2.dat
/aligocalibration/trunk/Runs/ER8/H1/Scripts/AAAI/Liso/fit_AI_LSC_EXTRA_AO.fil
/aligocalibration/trunk/Runs/ER8/H1/Scripts/AAAI/python/LSC_EXTRA_AO2_AIfilter.py
/aligocalibration/trunk/Runs/ER8/H1/Results/AAAI/2015-08-27_AI_LSC_EXTRA_AO.png
/aligocalibration/trunk/Runs/ER8/H1/Results/AAAI/2015-08-27_AI_LSC_EXTRA_AO.pdf
This fitting result is then used in the subsequent analysis as decribed below.
Results
First of all, I attach the measured transfer functions together with the fitting result.
As I noted in the above subsection, the measured transfer functions include
In my fitting model, I newly inserted a high frequency pole at around 11 kHz as an initial guess. Without this additional high-freq pole, the fitting would be miserable above 1 kHz similarily to the one shown in the above entry or alog 21101. As for the parameters of the AA and AI filters, I have used the fitted parameters and do not try to re-fit them in this anaysis. In other words, the fitting parameters in this analysis are:
The below are the raw output from LISO:
#Best parameter estimates:
#pole6:f = 10.7609523979k +- 1.226 (0.0114%)
#Best parameter estimates:
#pole6:f = 10.7183613550k +- 1.209 (0.0113%)
The upper one represetns the fitting result for DCPD A and the lower one for DCPD B. Both of them have a pole at around 10.7 kHz.
Some SVN info
As usual, the data, codes and resultant figures are saved in svn. They can be found at:
/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-27/LSC_AO_OUT_to_OMC_DCPDs_RandNoise_0whitenings.xml
/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-27/IOPCH9to_IOPCH12_0whitening_tf.txt
/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-27/IOPCH9to_IOPCH13_0whitening_tf.txt
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_LSCCH9toOMCCH12_0whitening.fil
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_LSCCH9toOMCCH13_0whitening.fil
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/python/OMC_DCPD_AAandWhite.py
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_A_AAand0White.pdf
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_A_AAand0White.png
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_B_AAand0White.pdf
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_B_AAand0White.png
Next step
I will analyze equivalent data with one whitening stage engaged. This is more important because this is likely going to be the configuration we will run during O1.
I have measured the DCPD signal chain in the same fashion as the previous alog, but this time with the 1st whitening stage engaged.
Here is my conclusion:
Measurement setup
The measurement setup is the same as the one in the previous alog shown above. I drove LSC-EXTRA_AO2 by random noise and took transfer functions from the IOP test point of LSC-EXTRA_AO2 to that of DCPD A and B. This time the 1st stage whitening filter is engaged with 0 dB gain.
Results
Here are the measured transfer functions with the fitting results.
LISO says:
#Best parameter estimates (for DCPD A):
#pole6:f = 10.8756718522k +- 1.275 (0.0117%)
#pole7:f = 10.3442465820 +- 4.165m (0.0403%)
#zero2:f = 992.1541013425m +- 2.461m (0.248%)
#factor = 500.1410089072m +- 1.112m (0.222%)
#Best parameter estimates (for DCPD B):
#pole6:f = 10.8295424180k +- 1.26 (0.0116%)
#pole7:f = 10.4145450914 +- 4.172m (0.0401%)
#zero2:f = 998.2444937993m +- 2.463m (0.247%)
#factor = 499.8306079302m +- 1.105m (0.221%)
The result suggests that the high frequency pole (called pole6 in the fitting code) moved up by 1-2% from 10.7-ish kHz to 10.8-ish kHz in both DCPD A and B compared with the previous data without the whitening filter engaged. I don't have a good explanation for why they moved up. But the point is that the high frequency pole does exist in the whitening configuration that we want to run during O1. Therefore we should definitely include this pole in our calibration model. Additionally, the measurement done at Caltech also shows a reduction in the magnitude as frequency reaches the end of the measurement frequency band at around 6 kHz (S1101603). Therefore I start believing that this high frequency pole is real and do exist in the whitening boards. I guess this effect was not visible in my intemnsity transfer function measurement (alog 20851) because ASC-AS_C, which was my intensity reference, also uses the same whitening circuit (D1001530) as OMC DCPDs.
Another interesting thing is that LISO reports different poles and zeros for the actual whitening filters than the ones reported in DCC (S1101603, or see nice summary by Koji at alog 17647). The pole location seem to be almost the same at a few % level, but the location of zeros differ by more than 10%. This is not cool. This also makes me think that we should re-measure the whitenig filter response.
SVN info
/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-27/LSC_AO_OUT_to_OMC_DCPDs_RandNoise_1whitenings.xml
/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-27/IOPCH9to_IOPCH12_1whitening_tf.txt
/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-27/IOPCH9to_IOPCH13_1whitening_tf.txt
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_LSCCH9toOMCCH12_1whitening.fil
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_LSCCH9toOMCCH12_1whitening.fil
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/python/OMC_DCPD_AAand1White.py
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_A_AAand1White.png
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_B_AAand1White.pdf
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_B_AAand1White.png
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-08-27_DCPD_B_AAand1White.pdf
This should be a killer measurement for this long discussion which was triggered by the unexpected high frequency pole-ish behavior in the DCPD signal chain. I have measured the transfer function of the DCPD whitening filter using an SR785 tonight.
The current conclusions are that:
Motivation
There seemed to be one or perhaps multiple high frequency pole(s) at a frequency on the order of 10 kHz. We wanted to include them in the calibration model to be mroe accurately model the phase and time delay. Besides, independtly of the high frequency poles, we noticed that the whitening zero-pole pairs were not precisely at the frequencies specified in the DCC document of an early measurement (S1101603). These two things pushed us to re-measure the analog transfer function of the whitening filter, in particular the first stage which is the one we usually use in full lock.
Measurement
I again used the coil driver test box only for the reason that I wanted a single-ended-to-differential convertor. With an SR785, I performed a swept sine measurement for ch4 and ch5 which correpond to DCPD A and B respectively. The 1st stage of the whitening filter was engaged while the rest are disabled for both A and B whitening filters. The whitening gain was set to 0 dB for both A and B. These settings are nominal that we usually operate in full lock. The exctiation amplitude was 200 mVp-p in the positive and negative inputs which resulted in 2 Vp-p at highest at the positive and negative outputs. With a scope, I confirmed that there was an obvious distortion or saturation in the signal at the outputs.
Results
I fitted the measured data with four poles and one zero. See the fitting results shown below.
As shown in the plot, the fitting is good from 1 Hz to 10 kHz at 0.1% level in absolute amplitude and 0.02 deg level in the phase. Here are the raw output from LISO.
#Best parameter estimates (for DCPD A):
#pole0:f = 18.6402825833k +- 20.23 (0.109%)
#pole1:f = 14.5121291389k +- 12.5 (0.0861%)
#pole2:f = 98.9771014448k +- 60.89 (0.0615%)
#pole3:f = 10.2675781089 +- 660.2u (0.00643%)
#zero0:f = 973.9581771978m +- 151.1u (0.0155%)
#factor = 993.7495082788m +- 129.2u (0.013%)
#Best parameter estimates (for DCPD B):
#pole0:f = 18.4126906482k +- 21.61 (0.117%)
#pole1:f = 14.6312083283k +- 13.88 (0.0949%)
#pole2:f = 98.3231767285k +- 60.51 (0.0615%)
#pole3:f = 10.3405121747 +- 667u (0.00645%)
#zero0:f = 980.5696173840m +- 152.8u (0.0156%)
#factor = 993.4759822630m +- 129.8u (0.0131%)
In order to get a better fitting, I ended up adding three poles at high frequencies -- two of them seem to stay between 10 and 20 kHz while the third one tends to be at around 98 kHz. I did not need to have a delay at all because this is just an analog circuit.
SVN info
/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-09-02/DCPD_A_1whitening.dat
/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-09-02/DCPD_B_1whitening.dat
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_whitening_1st_stage_DCPD_A.fil
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Liso/fit_whitening_1st_stage_DCPD_B.fil
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/python/whitening_1st_stage.py
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/OMCDCPDs/2015-09-02_whitening_1st_stage_DCPD_A.pdf
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/OMCDCPDs/2015-09-02_whitening_1st_stage_DCPD_A.png
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/OMCDCPDs/2015-09-02_whitening_1st_stage_DCPD_B.pdf
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/OMCDCPDs/2015-09-02_whitening_1st_stage_DCPD_B.png
Are these above-Nyquist-freq poles the ones I've reported with LHO ALOG 17647?
If so, they are the high freq poles associated with the OMC DCPD in-vac preamps.
Since they exist above the Nyquist frequency (~8kHz), it is not straight forward to compensate them.
As they show up like a linear time delay at low freq, we decided to leave them uncompensated in April. (Refer Daniel S, Jeff K).
This corresponds to ~18us delay. I thought this was already accommodated in the DARM calibration model described in LHO ALOG 17951
and the following comments (particularly in LHO ALOG 18037). Were they dropped at some point?
Koji,
No. They are not the ones in DCPDC's preamp. These poles are found in the whitening board by directly measuring it.
As for preamp's super-nyquist poles, they have been incorporated in our calibration model and have been actually used in the upsampled FIR pipeline without approximating it as a time delay. So we did not drop the ones from the preamp.
For double chek my conclusion written above, I went back to the original plot in alog 21101. With the newly discovered high frequency poles of the whitening board (alog 21131) included, the measurement agrees with the model with 1-ish % descrepancy up to 5 kHz in magnitude as shown in the attached plot.
This is good enough .
The code and figure:
/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/Matlab/OMC_DCPD_AnalogChain_TimeSeries.m
/aligocalibration/trunk/Runs/ER8/H1/Results/OMCDCPDs/2015-09-01_OMC_DCPDs_timeseries_analysis.pdf
The whitening chassis was replaced by a different unit on June 28th in 2016 (alog 28010). A new measurement was taken on June 30th in 2016 (alog 28087).
Pacific Time
7:30AM - Craning of 3IFO TCS chiller for some reason.
9AM - SR3 Troubleshooting - couldn't "see" the problem early this morning, Richard swapped a bunch of stuff, don't really see it now, unconclusive
- PSL chiller flow channel troubleshooting by Jason - fixed
- OMC DC PD Measurement by Kiwamu
10AM - ODC Model update happened
- DAQ down for FW2 build/start
- Dust monitor plumbing in LVEA for 2 hours
- Harmonic Generator power supply work for a while
11AM - Guardian restart for new nodes ala Jamie - these nodes will tie into the INTENT bit - call Jamie or Betsy if you get stuck and can't push the intent button
11:30 - Ran charge measurements on ETMX and ETMY SUS
DAQ restart stuff - ongoing, Dave says it didn't go weel, troubleshooting with multiple restarts this afternoon
Locking IFO ongoing with Corey/Kiwamu.
GregM, RickS, DarkhanT, SudarshanK
We took a 10 hour long lock-stretch from ER8 and studied if there is a significant change in the time varying parameters, kappa_tst, kappa_pu, kappa_C, kappa_A and cavity pole which are described in details in DCC document T1500377. The plots of these parameters are attached below.
The real part of these parameters represents the actual change. There is no significant variation in these paramaetrs within this lock stretch. There is definitely some indiication that the variation is more during the first half hour of the lock and stabilizes after that. Essentially, these numbers should be 1 (are set at 1 at some point in time) and the imaginary part of these parameters should be zero or insignificant, however, the second plot doesnot show that. The reason might be because we are using the Calibration model form ER7 which is not the true representation of interferometer at which this data was taken plus we didnot account for time delays. However, we were only intrested in knowing the change in these parameters so this analysis was sufficient for that purpose. We will do a more thorough study once we have the new calibration model ready.
We are also looking into how these parameters are changing over a long period of time (entire ER8). The analysis is ongoing and we will post the result soon.
This is the data analyzed from last week's end-station Pcal readout calibration. The new calibration factors will be used to compare with the old calibration factors. The calibration factor currently used will only be updated if there is a significant change.
The calibration factors obtained from this particular measurement are tabulated below. The number in parenthesis is the weighted mean of our past calibrations that we have been using in our current calibration model. The new factors are comparable with the past measurements in most cases.
RxPD (N/V) | TxPD (N/V) | |
CAL-PCALX | 1.062E-09 +/- 0.85% (1.053E-09) | 1.317E-09 +/- 0.85% (1.322E-09) |
CAL-PCALY | 1.053E-09 +/- 0.65% (1.059E-09) | 1.519E-09 +/- 0.65 % (1.520E-09) |
The RxPD at ENDX shows a difference of about ~1% from our currently used calibration. We think this is because there might be some beam clipping issue again that we have seen in the past in this particular unit. The drop in optical efficiency, seen in the attached report, and the trends of the RxPD signal both point in this direction. We don't have major calibration lines running in this unit( there is a high frequency (3KHZ ) line only). Additionally, we also have a TxPD readout that we can use if we show the clipping is happening on the way out, after reflecting off the testmass, which we think is the case. There are ways to check this and we are pursuing those cross-checks.
All the data and plots have been updated to the svn and more details about the intermediate factors used during the calculation, optical efficiency etc is attached with this alog.
The summary page (T1500252) on DCC that keeps track of these calibration factors has also been updated.
Leo, Jeff We try to measure the force acting on the TM from the electrical field goes from ESD blades to the cage and other surrounding. It corresponds to F_3 in Livingston alog 16611 and gamma in LIGO-T1500467. Relation between force due to the ESD-to-Cage field and due to usual ESD differential field may be characterized by c/a (in terms of LLO Log, = gamma/alpha in DCC note). The measurements was done on Aug, 17 and Aug, 25 , each of 4 charge measurement with additional measurement in script. The additional measurements was done with zero bias voltage and signal offset voltage = +/-4 V. The sine voltage in signal was multiplied by 0.5 against the charge measurements due to voltage should not not exceed the maximum value, while the charge measurements use the amplitude of the signal voltage close to the max. Measurements was done with ESD_Night scripts with Gamma1 measurements and proceeded by ESD_analysis_gamma.m Results of c/a (=gamma/alpha): ETMX Pitch 08/17 st. dev 08/25 st. dev UL 0.32 0.03 0.30 0.04 LL 0.34 0.04 0.33 0.02 UR 0.31 0.02 0.31 0.03 LR 0.33 0.03 0.32 0.02 Yaw UL 0.31 0.03 0.31 0.04 LL 0.27 0.03 0.28 0.03 UR 0.30 0.04 0.31 0.03 LR 0.25 0.02 0.27 0.02 ETMY Pitch 08/17 st. dev 08/25 st. dev UL 0.32 0.01 0.33 0.01 LL 0.35 0.02 0.37 0.02 UR 0.34 0.02 0.32 0.02 LR 0.37 0.03 0.36 0.02 Yaw UL 0.32 0.01 0.33 0.01 LL 0.31 0.02 0.31 0.01 UR 0.34 0.03 0.33 0.02 LR 0.29 0.02 0.31 0.01
In an ideal world we would have been able to systematically investigated each stage of the SR3 chain to find where the glitch was coming from. But with the pressure of needing to get the system up and running I decided to replace all electronics and do a followup in the lab. So this morning we took down the SR3 Front end and installed a new DAC card. Replace the coil driver SN100186 with SN 100192. The AI chassis had been replaced last night. So aside from cabling replacement the SR3 drive chain is new and after 10 minutes we do not see the glitches. Of course I could go 10 min this morning and not see them. Also there was a problem with the Voltage Monitor for T2. This was in the IO chassis ADC interface so we replaced the ADC the ribbon cable and ADC interface card for the SUS Aux chassis. This fixed problem.
This screenshot show the OPlev and witness sensor for SR3 pit. The problem shows up clearly early monday morning, things got slightly better around 2 am last night for unknown reasons. This morning after the electronics were swapped, the frames are bad, and now the problem seems to be fixed.
The second screenshot is a lockloss from last night, in which you can see that before the lockloss, SR3 gets something like 1 urad of pitch in about half a second. This is visible in both the witness sensor and the oplev although the calibrations don't agree. We also had smaller glitches that weren't large enough to lock us out of lock, but we think that the large ones were happening about once every 20 minutes or more frequently.
Here's a different view of the same thing that Sheila just posted.
I have 3 1-hour plots of SR3 M3 Wit Pit, all with the same y-axis scale: (1) Aug 26th at some time when the Cage servo was running, (2) sometime last night, and (3) right now. The "right now" plot shows the lock aquisition sequence, including the cage servo being engaged, which is why the DC value changes.
The salient point is that last week, the M3 Wit Pit looked nice and clean. Last night, even though there weren't huge glitches in the time that I chose, the optic was clearly moving around much more than normal. Now, the data looks clean again.
We pulled both the power supply and the harmonic generator from the remote rack and tested them in the lab, together with spare supply and spare generator. We used a spare 9.1MHz source on the bench.
In the lab, regardless of the combinations (supply and generator), 45MHz thing was clean.
In the rack, we tested the original generator with spare and original supply, with 9.1MHz source coming from the distributor in the rack. In both of the cases there were huge 45+-2MHz-ish humps.
Evan reported in the past that using IFR at the rack didn't change the results, so we didn't bother to look at 9.1MHz source.
In all of these test cases both in the lab and rack, the only thing connected to the harmonic generator was power supply, 9.1MHz source and the network analyzer on 5x output. Everything else was terminated.
We also looked at the supply voltage in the lab. We opened the chassis and used clips to access gnd and +15V test points. Under the load, both of the units didn't show any huge high frequency noise. RMS voltage measured on the scope was about 1mV, which was dominated by some pickup (it got smaller when I hand held the chassis away from the 9.1MHz source). Fil also measured the spectrum and it was within the spec. And anyway, the harmonic generator didn't show any hump in the lab, so the power supply is pretty much exonerated.
Fil put the original units back in.
Do the other harmonic harmonic generator output spigots have excess sideband noise?
Rich, yes. I took measurements of some of the other ports of the HG in the CER a few days ago (measurements attached).
001.TXT: 45 MHz output
002.TXT: 27 MHz output
004.TXT: 135 MHz output
005.TXT: 90 MHz output
007.TXT: 36 MHz output
There's a clue in the data files you attached. Looking at the plot of the 45 MHz, you see side lobes at +/- 1MHz. Looking at the plot of 90 MHz, and 135 MHz you see side lobes with the same offset frequency. If the source of the pollution was coming into the input of the harmonic generator, then the peaks of the side lobes would scale with frequency. Given that this is not the case, you are looking for something that effects each frequency directly. In my opinion, that would most likely point to a power supply issue causing phase modulation of an amplifier common to each output spigot (based on the observation that the induced modulation is about the same in each channel and assuming that's the physical topology of the HG). There is 50dB of separation between the peak of the carriers and the side lobes, so you can produce a spectrum like that with a pretty small 1 MHz noise hump on a power supply rail. I would be wanting to look at the HG power supply directly with an RF spectrum analyzer (be sure to AC couple the power supply to the spectrum analyzer or else you will need to buy a new spectrum analyzer, 1000pF would suffice) I don't know exactly how you are measuring these noise peaks, but I guess it could also be something in the particular spectrum analyzer (if you are using a different analyzer in the shop for example). Have you looked at a "clean" signal to be sure you don't see it on all observed signals with that particular analyzer? Sorry if this is simplistic, you may well have already vetted this and wrote about it only to have me forget somewhere. I now wish I had popped the top on the HG and its power supply. I have been itching to do that for a while, but missed the opportunity while I was there this weekend. I'd be super interested to see a photo of the insides if anyone felt like looking...
The power supply is a LIGO low noise unit boxed into a standard chassis. More details here. Possible points of investigations: power cable shielding, power decoupling at the generator side, grounding issues.
I went back and looked at the IFR data from a few days ago, and it seems that this may be a problem with the 9 MHz coming from the OCXO. The first attachment shows the output of the harmonic generator when powered from the IFR versus the OCXO. The IFR measurement still has peaks around the 45 MHz, but they are much smaller than with the OCXO.
As a check, Dan and I measured the spectrum directly out of the IFR and out of the OCXO (no distribution amplifier involved). In both cases, the spectrum on either side of 9.1 MHz looks pretty clean, but the OCXO has much worse noise between 0 and 2 MHz, and the shape qualitatively matches the peaks that are seen on the outputs of the harmonic generator.
We also did some related tests, like looking at the 45 MHz spectrum of the spare HG when powered from the 9 MHz distribution amplifier. This spectrum has the same huge peaks as the primary HG.
Keita and I looked at the noise from the ±15 V power supply, but we didn't see anything outrageous. As advised, we ac coupled the spectrum analyzer with 1 nF. The spectrum seemed to be roughly a few hundred nV/Hz1/2 out to a few megahertz, but we found it hard to get a clean measurement.
I misspoke. The offset frequency of PM or FM sidebands in a multiplied spectrum remains constant, but the sideband power scales with the multiplication factor. 9.1MHz carrier (W) with sinusoidal sideband (Wm) before multiplication: COS[W*t + A*SIN(Wm*t)] Derivative of argument for angular Frequency: W + A*Wm*COS(Wm*t) After frequency multiplication of factor N: N*W + N*A*Wm*COS(Wm*t) Sideband frequency unchanged, power scaled by N That being said, the sideband power is not scaling by N in the data I saw posted. The carrier could still be amplitude modulated, but I don't see how it could be phase or frequency modulated. Sorry for my earlier flawed theory on frequency multiplication. If someone would please figure this out, I could do a much better job of warping theory to fit observation. Conclusion: There might be AM being induced on either on the 9.1MHz carrier, or somewhere inside the harmonic generator - for what little that does to help.
The direct RF spectrum of the 9.1MHz shows no side lopes at 1-2MHz offset. This describes the total power including both AM and FM sidebands. Odd harmonics generators are typically squaring up the fundamental and then filter out the desired frequency. So, they should be first order insensitive to AM.
You are right about the limiting Daniel. Evan saw sidebands on the OCXO input too. I attach a plot of the 45.5, 91, and 135 MHz spectra frequency shifted for relative comparison (Data taken from earlier post).
J. Oberling, P. King
The investigation
Today we investigated what appeared to be frozen PSL channel: H1:PSL-OSC_DCHILFLOW. Upon entering the laser diode room and comparing the data on the PSL Beckhoff computer's CHIL screen for the diode chiller to the front panel of the chiller itself, we found that all of the channels were not reading properly (flow rate, temp set point, actual temp, conductivity). These data are read into the Beckhoff computer via RS-232 connections; the flow rate is read into the PSL Interlock Control Box, and the rest of the data are read directly into the Beckhoff computer via an add-in PCI RS-232 card. Digging into the Beckhoff code it appeared that the Beckhoff data channels were not properly reading in the data from the diode chiller.
What we think happened
Back in May we performed several tests of the interlock system for the chillers to see how they behaved when certain cables were unplugged. See Peter's alog here, under "The Evidence," point e where he talks about opening and closing the interlock switch. We unplugged the cables to open the interlock and plugged them back in to close. When this was performed, we did not restart the PSL Beckhoff PC; we should have, as RS-232 is not hot-swappable. Therefore the channels for the diode chiller got stuck (interestingly enough the crystal chiller's channels have all been fine, and we performed the same test with it).
The solution
To fix this, we restarted the PSL Beckhoff PC. We first called the control room to inform them of our intentions, since restarting the PC shuts the PSL down. They put the IFO in a safe configuration (in this case they simply unlocked the IMC) and we shut the laser down and restarted the Beckhoff PC. Everything came back on just fine, the PSL fired right up without issue. Looking again at the CHIL screen the diode chiller data now matches that shown on the front panel of the diode chiller. Problem solved!
One caveat
While we are now reading data on H1:PSL-OSC_DCHILFLOW, we do not trust the actual reported flow rate. The same holds true for the crystal chiller, H1:PSL-OSC_XCHILFLOW. Back in May we replaced the turbine style flow sensors in the PSL chillers with vortex style flow sensors (no moving parts in the new sensors). With the sensor change we also had to change the flow sensor calibration, a number we received from LZH, who had tested these flow sensors (we went from ~550 pules/liter to 970 pulses/liter). Upon this change the flow rate on the crystal chiller "dropped" from ~18 lpm to 9.7 lpm, a change of almost a factor of 2. There was no associated drop in the HPO laser head flow rates (each of the 4 laser heads has its own flow sensor), therefore we do not trust this calibration number and therefore do not trust the flow rate being reported by the chillers. That being said, we can still use the reported flow rate to monitor if there is a change in flow and as an indicator that something might be wrong. The flow rate should not change, and if it does then something is not working correctly regardless of the flow rate being output by the chillers. We do, however, trust the flow rates being reported by the HPO laser head flow sensors and by the water cooled power meter flow sensors. To fix this, we will take the next opportunity when we have to swap out the running chillers for the spare chillers. Before putting the spare chiller into operation, we will hook up an external flow meter on its own water circuit (this is before hooking the chiller up to the PSL water circuit), measure the flow of the chiller and adjust the pulses/liter calibration number until the chiller reports the same flow rate as the external flow meter.
The h1fw1 computer is now only writing raw minute files to it's locally attached SSD RAID file system. The h1fw2 computer is writing science and commissioning frames to the /cds-h1-frames file system through the h1ldasgw1 computer. We will monitor the performance of this configuration and if it works reliably we will change the computer names to reflect their new usage. This should have no effect on h1nds1, other than the gap in data that occurred during the reconfiguration and restart of the frame and trend writers.
I am starting work on WP 5471 which will move the DMT to EPICS IOC from a test install to a perminant fixture. Dave will then configure the EDCU to capture the channel in the frames. There will be some interruptions on H1:CDS-SENSMON_CAL_SNSW_EFFECTIVE_RANGE_MPC and H1:CDS-SENSMON_CAL_SNSW_EFFECTIVE_RANGE_MPC_GPS.
This is follow up work on previsous work listed in the alog at: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20925
The work has been completed. The IOC is installed in h1fescript0. It will start at system boot. Dave has put the daq changes in such that it will be captured in the frames after the daq restart.
I have added the following three guardian DIAG nodes:
DAQ restart required to acquire new channel names.
These nodes will all be folded under the IFO top node, but have not yet. Waiting for go ahead from ops...
I'm also in the process of updating the GUARD_OVERVIEW screen to add these new nodes. I will post when that screen has been updated.
In discussion, we are proceeding with tying this into the READY bit. Expect an alog from Jamie - but be aware that you may need to look further at some things if you cannot hit the INTENT bit. For example, all SDF must be clean (not red) now. You may need to consult the on-call commissioner if you cannot interpret and address any red SDF differences before going into observation mode. We have some time before the start of O1, so we'll be troubleshooting this if needed this and next week.
At least twice it was just stage 2. Is something going wrong with the ISI? or is this a side effect of the SR3 problems, which could cause the MICH ASC to get a kick?
[Sheila, Anamaria, Jenne, Cheryl, Dan, Evan. Richard via phone]
SR3 glitches are still causing us grief. This is a continuation of the story started last night (alog 21046), and worked on earlier in the day (alog 21062). After some heroic efforts, we have determined that we cannot lock in this state.
To prove to ourselves that indeed it was a problem with the analog actuation chain we investigated turning different pieces of the analog electronics off. The first attached Dataviewer screenshot shows the NOISEMON channels of the SR3 M1 stage throughout this investigation. When the local damping is on, we cannot see the glitches very clearly in the noisemon channels - but we do see them in the voltmon channels (The second attached screenshot shows that the T2 voltmon channel does in fact see the glitches, so it's not a broken monitor). When the local damping is off, we only see the glitches in the noisemon channels.
Since we do not see the glitches when the AI chassis is powered off, we infer that the noise is not generated in the coil driver board. (Note that we also borrowed a triple top coil driver chassis from the H2 storage racks, S1100192, but did not swap it in since we don't think the noise is coming from there). We have not, however, determined whether the noise is coming from the AI board (probably not, since it's still there after a swap?) or the DAC.
We tried a few times to lock the IFO after the AI board swap, but we were continually losing lock before the CARM reduction is complete. Lockloss investigations showed that the problem for most of these was SR3 motion.
At this point, we have determined that we need more expert brains to have a look at the analog electronics. The owl operator shift has been cancelled, since there will be no more full IFO locking happening until this problem is resolved.
Looking at the noisemons for a 5 hour stretch when I knew no one was on site. See attached.
I would like to help here, but I am not 100% sure I follow the picture. After the AI swap (which seemed logical to me), you saw no more glitches (presumably in the noise monitors for those channels?). Then the story gets hazy. You once more tried to lock and still see SR3 motion as a lockloss initiator. What exactly is left that you suspect is causing inadvertent motion in SR3?