[Marie, Jenne]
Marie suggested that we run A2L, which we did. She was totally right - we should have done this a week ago! We win about an order of magnitude in sensitivity at low frequencies. This will make things much easier for the calibration team.
Attached is a spectrum showing the enormous improvement. This reduced the coherence between DARM and CHARDY, but not to the low level that CHARDP is, so there is probably more that we could do to get even better sensitivity with A2L.
Edit: The new A2L values have been saved in both the down.snap and observe.snap sdf files.
I have measured the transfer functions of the newly installed whitening chassis (alog 28010, ECR:E1600192, SN:S1101627) for the OMC DCPDs. I used LISO for fitting the data.
[1st stage for DCPD A]
Best parameter estimates:
pole0:f = 18.6776675365k +- 10.45 (0.0559%)
pole1:f = 14.3409807014k +- 6.292 (0.0439%)
pole2:f = 98.9444053052k +- 32.86 (0.0332%)
pole3:f = 10.3243596197 +- 359.4u (0.00348%)
zero0:f = 985.3423393170m +- 79.51u (0.00807%)
factor = 998.8350760502m +- 67.01u (0.00671%)
Final chi^2=0.00252952
[2nd stage for DCPD B]
Best parameter estimates:
pole0:f = 18.5698573085k +- 14.71 (0.0792%)
pole1:f = 14.6043378758k +- 9.31 (0.0637%)
pole2:f = 100.4496012696k +- 43.14 (0.0429%) > MAX
pole3:f = 10.0731025960 +- 470.5u (0.00467%)
zero0:f = 961.4535554217m +- 104.7u (0.0109%)
factor = 997.7425128879m +- 90.38u (0.00906%)
Final chi^2=0.00454374
[Small notes]
I have also measured the same transfer functions with a 4 times smaller excitation signal in order to check some sort of saturation-induced measurement error. I did not quantitatively look at these data, but plotting them on top of the above data showed excellent agreement (to my eyes).
[SVN info]
All the data, scripts and figures are checked into SVN at:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/OMCDCPDs
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Measurements/OMCDCPDs/2016-06-30
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Results/OMCDCPDs
Attached are the past 7 day pitch, yaw and sum trends for all active H1 Optical Levers
TITLE: 06/30 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Aquisition
INCOMING OPERATOR: TJ
SHIFT SUMMARY: First half of the day was dedicated to maintenance and measurments by several parties. Afterwards, locking has been fairly successful up to INCREASE_POWER several times, and we made it to NLN finally.
LOG:
15:33 Kiwamu and Evan G. to HAM6 OMC chassis measurements
16:00 Fil to LVEA getting serial #'s for vacuum racks and chassis
16:02 King Soft on site
16:18 Patrick updating MX vacuum Beckhoff
16:22 Richard to reinstall OMC AA chassis
16:25 Hugh to EX
16:36 Richard done
17:06 Fil done
17:08 Patrick done
17:09 Cheryl to IOT2L taking pics of beam dump
17:23 Kiwamu done, Cheryl done, Hugh done
17:39 Kyle back
17:59 DAQ restart
19:19 Richard to EX, EY, and MY
20:08 Richard back
20:37 reset ALS Y VCO
Between yesterday and today, Gerardo and I successfully bonded the ears to core optic mass ETM15, destined for LLO for post-O1 eventual replacement.
Ear s/n 195 bonded to S3 flat of mass June 29, 2016
Ear s/n 196 bonded to S4 flat of mass June 30, 2016
The first ear (s/n 195) has a series of bubbles along it's edge, but the surface area of these do not add up to more than the allowed amount as per E1000277, so it passes, see pix attached.
The second ear (s/n 196) has no bubbles and is nice full bond.
Inspection of the bonds this morning showed no change to the nice S4/Ear surface bond.
The small edge bubbles along the S3 Ear have migrated a bit (not worse, just moved a bit). Therefore, we decided to rewet the edge with solution to see if it would wick in and close some of the bubbles. This worked to close one of the larger bubbles, but one bubble continued to morph so we'll reinspect Monday. Note, none of the sizes of the bubbles got bigger, so the surface area of the bubble total remains the same and below spec.
Attached is a picture of what the bubbles in the ETM15 S3 Ear bond look like today (recall, it was bonded last Wed so it has now been over 5 days since initial bond). Apparently over the weekend, the bubbles ran inbound a bit further. I estimate the surface are of the bubbles to be near 20mm sq., still under the 50mm sq. spec. E1000278, although it isn't pretty. I measured the longest streaks to be almost 3mm long, with a width of 0.4mm. There are no bubbles inward from the edge near the center - anything shown in the picture is a camera reflection.
The S4 Ear bond looks unchanged from inspection last week, very good bond, very little bubbles.
Pictures of this ear bond taken by Danny at LLO just before use at LLO, indicate that the bubbles have not changed shape or size since the picture attached July 2016. Phew, said both Gerardo and I.
The CP5 level control differential pressure signal from the pump is noisy so I have set the "Smoothing" to 0.999
I would like to leave it this way overnight but if problems arise the smoothing can be reset to 0.0
C. Cahillane After taking a close look at the Hanford actuation measurements, with the addition of the January 7th measurements, it became very obvious that the actuation measurements were never compensated for time dependence. I am not sure if the same is true at Livingston. I will be investigating shortly. If so, it could be a major reason why LLO actuation uncertainty is so large... Previously, I used only calibration-week actuation measurements for LHO, meaning the kappas could not have varied too crazily in that period. But LLO had measurements more spread throughout the run. This is obviously quite important for our uncertainty budget... The systematic errors will be affected on the order of the kappas that were never applied, so about 3% for TST and 2% for PUM and UIM. The uncertainties will be smaller since removing time-dependence will cluster our measurements better. I have posted a plot similar to the one from aLOG 27290 showing the actuation magnitude variances and covariances between each day's measurements. Blue is the measurements without the kappas applied. Red is with the kappas applied. Comparing to aLOG 27290, we see UIM and PUM variances stay about the same, which makes sense because kappa_pu is not that volatile. But TST variance goes from2.5%
to2.0%
! I have added the following scripts to the calibration repository:analyze_pcal_20150928_kappa_corr H1PCALparams_20150826_kappa_corr H1PCALparams_20150828_kappa_corr H1PCALparams_20150829_kappa_corr H1PCALparams_20160107_kappa_corr
These allow me to correct the LHO time dependence in our actuation functions.
C. Cahillane I have propagated the new actuation systematic fits and uncertainties through to the final response function comparison R_C02/R_C03. The plot shows in dark red the old variance-only uncertainty and systematic error for R_C02/R_C03 reported to the PE group. The new covariance-included and correctly time-dependence compensated LHO actuation systematic error in light red. The results are dramatic. Without the DC positive biases in the actuation functions, the LHO sensing function systematic error takes over at low frequency. This pushes the LHO systematic error at 11 Hz from +5% to +9% This means the overall "deviation" at LHO is above 10% in magnitude at 15 Hz for C02 at GPSTime = 1135136350, the time of the Boxing Day event I have looked through the Livingston actuation measurements and convinced myself than a similar mistake does not exist there. As far as what I reported to the PE group for "C03", it is significantly off in both magnitude and phase due to this bug and the addition of covariance. I will update all of the O1 uncertainty results based on this information.
Added 200ml water to the crystal chiller.
B. Weaver, J. Kissel Betsy grabbed this week's charge measurements on both end station test masses; the first after the what-will-no-be-regular bias sign flipping that started last week. There is a significant jump in actuation strength in all quadrants to ETMX and ETMY, but this is the first data point of many, and the point is to see how the scatter of actuation strength changes over time. So, though this first point may be confusing, we should ride it out to see if the long term effect is as desired. We'll flip the bias back upon the next lock loss. Attached are the usual trend plots. Thanks to Betsy for running and processing the measurements from today!
Following Tuesday's install of a new Solaris QFS-NFS gateway machine, the DAQ had became more unstable with both frame writers restarting regularly. Today we reverted the system back to its old configuration to see if we can get back to a more stable system for the long weekend and ER9.
h1ldasgw0 NFS was reconfigured to export ldasg-h1-frames to both nds machines
h1ldasgw1 NFS was reconfigured to export cds-h1-frames to both nds machines
h1nds0 processes were stopped, umounted h1ldasgw2 then mounted ldas-h1-frames from h1ldasgw0
h1nds1 processes were stopped, umounted h1ldasgw2 then mounted cds-h1-frames from h1ldasgw1
The new h0vacmx.ini file was incorporated into H0EDCU_VAC.ini.
11:06PDT full DAQ restart.
This was a messy restart, h1psl0 DAQ data was held in a bad state as long as mx_stream was running on h1asc0. This was tracked primarily to monit not running on h1asc0 (it was shutdown while the special asc awgtpman was installed this week). Our /etc/start_streamers.sh file was out of date, it should not attempt to start the mx_stream process itself, rather it should kill the process and allow monit to start it. This file was modified on h1boot accordingly. We are still unsure why we do not see two copies if mx_stream on the FECs that have had start_streamers.sh manually ran. I checked and all FECs now have one, correctly configured mx_stream process. This raised the question of if the data loading is balanced between the two data concentrator ports, as the port allocation is purely on the order of the models in the rtsystab file.
on the test stand x1psl0 machine I manually ran the incorrect /etc/start_streamers.sh and this system behaved as expected. The script started a mx_stream process missing many arguments, and monit attempted to run' /etc/init.d/mx_stream start' which failed because a process of that name already exists. This is not the behaviour we saw on h1psl0.
On x1boot I made the same change to start_streamers.sh to only kill the mx_stream process and leave the restart to monit.
J. Kissel, J. Betzwieser We've recently installed CDS oscillator parts which have their phase synchronized to GPS time 0, in order to progress with the O2 calibration line scheme of PCAL cancelling suspension lines (see LHO aLOG 27733). However, when I turned the lines on the other day (see LHO aLOG 27981), I'd installed the new oscillator / cal line frequency (a copy of LLO's frequency) in the Pitch Oscillator of the optical lever lockins. These lockins still use the former unsynchronized oscillators. As such, I've swapped the calibration line frequencies such that the old frequency (35.9 Hz) is now run by the Pitch Optical lever lockin, H1:SUS-ETMY_LKIN_P_OSC (so that it's just as unsynchronized as it was during O1) and the new frequency (35.3 Hz) is run by the now synchronized cal line oscillator that *used* to run the O1 test mass calibration line, H1:SUS-ETMY_L3_CAL_LINE. These settings have been captured in the SAFE and down.snaps of the SDF system.
WP 5972 The Beckhoff vacuum controls code on h0vacmx has been updated to use the same PI controller as h0vacey (alog 27886). I have put both CP5 and CP6 on PID control. The channels in the DAQ and autoBurt request snapshots still need to be updated.
CP5 and CP6 settings and response attached. The initial increase in the CP6 pump level happened because I first had the minimum output set at 50, which was too high. I lowered it to 20 and it recovered.
Sheila, Carl, Stefen
With the ISS 2nd loop patch (see alog 28076) we successfully reached the "lowish" nosie state again. The spectrum loked the same as in alog 27990.
.
Start: Jun 30 2016 05:01:36 UTC
Loss:Jun 30 2016 05:05:22 UTC
The loss was presumably cause by a 18.04kHz mode ringing up rapidly. Carl will add more details on that.
The spectrum at lockloss shows a line in OMC DCPDs and Arm transmission QPDs - see first image.
This is not the first time I have seen this line. On 22nd June I saw it but I thought it was asociated with Terra's mode excitation experiments. On the 22nd it appeared out of nowhere, with a time constant of 16 seconds. See second image.
Today the time constant was not as short, about 20 seconds. See the third image of the ringup and fit. Today I did not see any associated increase int he ITM drive signals.
We had 2 more of these short locks, the first we again got to "lowish" noise and lost lock sudenly after a few minutes, the next time we sat at increase power (40 Watts, none of our low noise steps) and lost it after about 10 minutes.
We reverted a ring heater change from a few days ago.
During the second short lock we started the calibration measurement, but had to abort when we lost lock. What we got is saved here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Measurements/DARMOLGTFs/2016-06-29_H1_PCAL2DARMTF_4to1200Hz.xml
As a first guess it looks like the unstable mode seen at 18039Hz is a supernyquist ETMY mode. This is from the frequency shift of this mode over yesterday evening. In the first figure the change in frequency of a bunch of peaks around 18kHz is compared to the known set of 15200Hz drumhead mode frequency shift. The frequency shift is -2.5 times the ETMY mode at sample point n=50 (we'd expect -2.6 times) and then they both aproach zero frequency shift towards n=67 (ETMY ring heater was stepped). This may be contrasted to the 18002Hz mode that appears to be a subnyquist ETMY mode. Assuming this preliminary analysis is correct this mode is a 47497Hz ETMY mode.
The new HF DCPD channels allow us to see markedly more of the ringup curve (about one order of magnitude). See the comparison between the original and HF DCPD channels in the second figure.
Several modes are going through an amplitude transient. Tracking of some of the largest modes in the 18kHz area are shown in the last 2 figures showing mode amplitude vs time. Strangely the second peak at 18056 also looks like an supernyquist 47480Hz ETMY mode. The difference in amplitude transient makes me think it is real.
The arm mode spacing simulation from TCS indicates this instability occured when the mode spacings were X - 4950Hz, Y - 5015Hz. The chnage of ETMY ring heater dropped the mode spacing of ETMY by 5-10Hz. There was not instability in the last lock at this mode spacing (see the last image )however it was short.
Jeff, Kiwamu, Stefan
We had trouble engaging the ISS 2nd loop at 40W. The core issue is that the digitized signal (H1:PSL-ISS_SECONDLOOP_SIGNAL_OUTPUT) swings rail to rail without the loop, making it difficult to properly pre-set the offset adjuster (H1:PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA).
As a result, when engaged, the ISS 1st loop tended to swing into saturation.
I patched the Guardian as follows:
- Instead of trying to rely on a calculation for the offset adjuster (H1:PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA), I hard-coded it to 0.987 V, which is where it likes to sit at 40W. (THis is obviously not a long-term solution.)
- As soon as the servo comes on, I ramp H1:PSL-ISS_SECONDLOOP_REF_SIGNAL_SERVO_GAIN to zero, clear the history, and re-engage it on the diffreation power.
This seemed to engage the 2nd loop without excessive transient - back to full locking.
PS: I might have already mentioned this: but the ISS SHOULD BE AC COUPLED!
Code:
In PREPARE_ISS:
# read current servo signal value. If it is too far from the operating point, correct the offset.
#second_loop_out = cdu.avg(1, 'PSL-ISS_SECONDLOOP_SIGNAL_OUT16')
#if abs(second_loop_out) > 1.0:
# # measure current input PD value
# # Sets the ref. signal value to bring it to close to the operating point
# pd_avg = cdu.avg(1, 'PSL-ISS_SECONDLOOP_PD_14_SUM_INMON')
# ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA'] = round(0.5*((pd_avg*2.29*.0006103515625)+0.101), 6)
# time.sleep(5)
# above section commented out - instead command the value that worked (Stefan Ballmer 20160629 for 40W)
ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA']=-0.9826934814453125
In CLOSE_ISS, once the loop is closed:
# the loop is successfully locked, ramp off the loop (Stefan Ballmer 20160629 for 40W)
ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_SERVO_GAIN'] = 0
and a little later:
# clear and ramp on the loop (Stefan Ballmer 20160629 for 40W)
ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_SERVO_RSET'] = 2
time.sleep(0.1)
ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_SERVO_GAIN'] = 1
When people were engaging the offset adjuster servo with 40W into IMC, eventually H1:PSL-ISS_SECONDLOOP_REF_SIGNAL_MON_OUTPUT settled down to -0.98V and H1:PSL-ISS_SECONDLOOP_SUM14_DC_OUT16 to 39.6.
This PSL-ISS_SECONDLOOP_SUM14_DC_OUTPUT thing is a digital sum of four digital outputs, each with dewhite, so it's well behaved even with high power, unlike PSL-ISS_SECONDLOOP_PD_14_SUM which is just a readback of the second board input without dewhite.
pd_avg = cdu.avg(2, 'PSL-ISS_SECONDLOOP_SUM14_DC_OUT16')
ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA'] = round(-pd_avg*0.98/39.6, 6)
instead of
ezca['PSL-ISS_SECONDLOOP_REF_SIGNAL_ANA']=-0.9826934814453125
But you might have to fine tune the above to account for some offset in the board. I haven't changed the guardian.
biggest = prm pitch changing by 2.5urad
close second = im4 pitch changing by 1,15urad
plot and chart of top 16 optics/DOFs attached
plot of optics/DOFs in the chart - meant to attach yesterday. I
used OpLev signals when available and OSEMs when not.
UPDATE to my alog's less than descriptive title: I think the original title suggests these changes were during a 40W lock, but this is not the case.
The optic alignment changes are actually happening over 8 minutes of full lock while the input power increased from 22W, the O1 power level, to 40W.
(Richard M, Fil C, Ed M, Daniel S)
ECR E1600192.
Split Whitening Chassis S/N S1101627:
AA Chassis S/N S1102788 & S1202201:
The attached plots show the transfer functions of
Whitening chassis S1101603 was removed from ICS-R5 U18. New chassis S1101627 was reinstalled with modifications listed above. New unit is the split variant.
[Kiwamu, Carl]
First indications are that the DCPD HF channels are behaving as expected. With the OMC locked on an RF sideband the DCPD A is compared to the new DCPD HF A. The transfer function between them at low frequency has a 'f' relation which transistion fto f^3 at 10kHz as expected from the AC coupling change and the removal of 2 poles at 10kHz. Coherence is lost at about 20kHz.
I have changed the whitening gain of the AHF DCPD path (A and B) to 15dB. This pushed the noise floor in the 15-29kHz region to a factor ~2 above what I guess is ADC noise. In the attached plots the original DCPD can be seen to reach a common noise floor with the AHF DCPD path with no whitening gain at about 17kHz. Turning the whitening gain up we can get some coherence with the shot noise of the DCPD through original electronics.
A forest of new peaks is visible, mainly in the 17-29kHz region. There are 80 peaks in teh 25-26kHz band. I stepped the ETMX ring heater at 7:01 up by 0.5W and down again at teh end of lock at 7:22. This may give some mode identificatiion data.
This morning we removed the Twin T notch on the AA board by removing C3, C4, C5, C10, C11 leaving in the 100 Ohm resistors in place.
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).