Displaying reports 62461-62480 of 83091.Go to page Start 3120 3121 3122 3123 3124 3125 3126 3127 3128 End
Reports until 11:35, Thursday 03 September 2015
H1 PEM (DetChar, PEM)
robert.schofield@LIGO.ORG - posted 11:35, Thursday 03 September 2015 - last comment - 20:56, Thursday 03 September 2015(21180)
More injections to test coupling of site activities

 

Injection

Time of first injection,

UTC

Injection spacing

Total number of injections

Good channels for environmental signal

 

Sept. 2

 

 

 

Truck braking by EY station parking area

22:56:00

5s

6

EY seismometers

 

Sept. 3

 

 

 

OSB shipping roll up door actuation

2:46:00

2:47:00

5s

5s

6

6

vertex seismometer and/or

output optics mic

Loud Bach in control room (2s bursts of music)

2:52:00

5s

12

input optics mic

Loud Underworld in control room (bass heavy)

2:55:00

5s

12

input optics mic

Single bounces on exercise/seating ball in control room

2:57:00

5s

12

HAM2 seismometer, vertex seismometer

Dropping large super ball from about 5 feet onto control room floor

2:59:00

5s

12

H1:PEM-CS_ACC_LVEAFLOOR_HAM1_Z

 

5 people jumping in synch in control room

3:01:00

5s

12

HAM2 seismometer, vertex seismometer

Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 20:56, Thursday 03 September 2015 (21191)DetChar, SEI, SUS

I've attached the result.

Quick conclusion: Dropping large super ball and people jumping in control room coupled into DARM.

In case people wonder what's the super ball looks like, I've attached a photo as well.

 

No more super ball during observing run =(

Images attached to this comment
Non-image files attached to this comment
H1 INJ (INJ)
peter.shawhan@LIGO.ORG - posted 11:35, Thursday 03 September 2015 (21181)
HardwareInjection records added to GraceDB in preparation for scheduled burst injections
We have planned to do a series of burst hardware injections during ER8, but that has been held up for a long time while we sorted out how to get them properly recorded in GraceDB so that, if an event is identified by the low-latency analysis, it's known immediately if it's a hardware injection.  I finally solved this problem and have created HardwareInjection records in GraceDB for all of the burst hardware injections scheduled between now and the end of ER8.  There won't actually be injections at ALL of those times, but they're pre-marked anyway.

The next step is to actually turn on the burst hardware injections.  I will talk with the operators and, if there are no objections, turn those on.  Note that operators should free to pause or disable the burst injections (using the MEDM injection control screen) if there is any concern that they might interfere with ongoing activities; just please remember to re-enable them when it's OK for them to resume.

For reference: I did this with the new 'gracedb_burst_sync' script in HardwareInjections/Details/tinj.
H1 AOS
david.barker@LIGO.ORG - posted 10:54, Thursday 03 September 2015 (21178)
CDS model and DAQ restart report, Wednesday 2nd September 2015

ER8 Day 17

model restarts logged for Wed 02/Sep/2015
2015_09_02 06:43 h1fw0

unexpected restart of h1fw0

H1 PSL
edmond.merilh@LIGO.ORG - posted 10:23, Thursday 03 September 2015 (21176)
PSL Weekly Report - Past 10 day Trends
Images attached to this report
LHO General
corey.gray@LIGO.ORG - posted 09:28, Thursday 03 September 2015 (21175)
DAY OPS Hand Off

9/3 DAY Shift:  15:00-23:00UTC (08:00-16:00PDT), all times posted in UTC

Handed an H1 which has been locked since about 11:45utc (4:45amPT), and range is hovering around 66Mpc.  So we are GREEN with Intent Bit, Observatory Mode and even GWI.stat!  (Yesterday GWI.stat was pink since there were Hardware Injections in progress.....but see my boo-boo below.)

Seismically we look quiet and winds are under 10mph.

Jim mentioned for the next lockloss, one will have to hit INIT on the ISC_LOCK (and if nothing happens,  select DOWN).

16:10:40UTC:  Out of Observation Mode!  I accidentally hit the "Toggle hardware output on/off button", thus dropping us out of Observation mode!  (I meant to look at the Hardware Injection filter bank [button above toggle] to see what it looks like today vs. yesterday since GWI.stat is not in Injection mode.  My mistake!)  At any rate the Toggle button toggles the OUTPUT button for that filter bank.  I toggled it back to where it was (with the help of SDF), and then went back to Observation Mode.

16:12 UTC:  Back to Observation Mode!

Plan For the Day:

Will stay in Observation mode as much as possible, but know that PEM Injections will most likely be occurring at some point.  As of 16:23UTC, I had contacted LLO & they mentioned recently going down for calibration work (probably for another ~30min).  Then they'll go back to Observation for lunch, and then after they hope to do some Commissioning.

Bubba mentioned wanting to tip toe into the LVEA to make a grouting measurement (will call him during a lockloss or if it could be done in parallel with PEM injections later.)

H1 General
jim.warner@LIGO.ORG - posted 07:33, Thursday 03 September 2015 (21172)
Shift Summary

Mostly a quiet night of commissioning.

Evan was in and out of CER, taking measurements on 9 Mhz  work. 

~13:45 Locked, concurrent with LLO 

Periodic glitches with simultaneous saturations on ETMY causing big drops in range.

H1 DetChar
peter.shawhan@LIGO.ORG - posted 07:09, Thursday 03 September 2015 (21170)
GWIstat fixed
Cheryl emailed me overnight to mention that GWIstat was reporting an incorrect status for LLO -- it was reporting "Not OK" (red) while LLO was actually observing (OK+Intent).

I investigated and found that this was due to additional bits that became active recently in the GDS-CALIB_STATE_BITMASK and are being (correctly) summarized by Chad Hanna's gstlal processes, which my gwistat_collector process polls.  When I wrote the gwistat_collector parsing code during ER7, I had assumed that only 9 bits of GDS-CALIB_STATE_BITMASK were going to be used.  Maddie announced upcoming changes to the h(t) calibration channels and expansion of the bitmask on August 24, but it didn't register with me that it would affect GWIstat.  Scanning the hoft frame files, I see that the extra bits were turned on starting on August 28 at both sites.

So, the GWIstat status display has been generally incorrect since August 28, but is fixed now.  I apologize for the confusion.

For reference, here's how I checked to see when the extra bits first appeared:
pshawhan@> hostname -f
ldas-pcdev1.ligo.caltech.edu
pshawhan@> cd /archive/frames/ER8/hoft/L1
pshawhan@> /home/pshawhan/hwinj/monitor/FrBitmaskTransitions -c L1:GDS-CALIB_STATE_VECTOR -m fe00 L-L1_HOFT_C00-1124[89]/*.gwf 
1124802560.000000  0x00000000  Data starts ( )
   *** *** ***                 Data gap from 1124833796 to 1124833820
1124833820.000000  0x00003e00  9 on, 10 on, 11 on, 12 on, 13 on
1125003264.000000  0x00003e00  Data ends ( 9 10 11 12 13 )
H1 ISC
evan.hall@LIGO.ORG - posted 05:03, Thursday 03 September 2015 - last comment - 13:48, Thursday 10 September 2015(21167)
Excess 45.5 MHz noise in DARM is gone

Dan, Daniel, Evan

Summary

The addition of a 9.1 MHz bandpass on the OCXO output has removed the broadband excess noise between DCPD sum and null. The dashed lines in the figure show the sum and the null as they were three days ago (2015-08-31 7:00:00 Z), while the solid lines show the sum and the null after the filter was inserted.

Details and review

Since at least June (probably longer), we've had a broadband excess noise between the sum and null DCPD streams. Stefan et al. identified this as 45.5 MHz oscillator noise a few weeks ago (20182).

In parallel, we switched the 9 MHz generation from an IFR to the OCXO (19648), and we installed Daniel's RFAM driver / active suppression circuit (20392), but the excess noise remained (20403). For a while we suspected that this was 45.5 MHz phase noise (and hence not supressed by the RFAM stabilization), but the shape and magnitude of the oscillator phase noise coupling (20783) were not enough to explain the observed noise in the DCPDs, under the assumption that the OCXO phase noise is flat at high frequencies (20582). For that matter, the shape and magnitude of the oscillator amplitude noise coupling were also not enough to explain the observed noise in the DCPDs, assuming a linear coupling from the RFAM (as sensed by the EOM driver's OOL detector) (20559).

Daniel et al. looked at the 45.5 MHz spectrum directly out of the harmonic generator in CER, and found that most of the noise is actually offset from the 45.5 MHz carrier by 1 MHz or so (20930), which is above the bandwidth of the RFAM suppression circuit. This suggested that the noise we were seeing in the DCPDs could be downconvered from several megahertz into the audio band.

Yesterday there was a flurry of work by Keita, Fil, Rich, et al. to find the source of this excess noise on the 45.5 MHz (21094 et seq.). Eventually we found circumstantial evidence that this excess noise was caused by baseband noise out of the 9.1 MHz OCXO.

Tonight we installed a 9.1 MHz bandpass filter on the OCXO output. This has removed the huge 1 MHz sidebands on the 45.5 MHz signal, and it also seems to have greatly lowered the coherence between DCPD A and DCPD B above a few hundred hertz.

Loose ends

The chain from OCXO to filter to distribution amplifier currently involves some BNC, since we could not find the right combination of threaded connectors to connect the filter to the amplifier. This should be rectified.

Also, it appears that our sum is lower than our null in a few places (400 Hz in particular), which deserves some investigation.

Images attached to this report
Non-image files attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 10:44, Thursday 03 September 2015 (21177)

"NULL>SUM" problem is just DARM loop. You're talking about 10%-ish difference, and DARM OLTF gain is still 0.1-0.2 at 400Hz.

See attached.

I don't know how to obtain official DARM OLTF model, so I just took 2015-08-29_H1_DARM_OLGTF_7to1200Hz_tf.txt in 

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/DARMOLGTFs/

The coherence for this OLTF measurement was much larger than 0.95 for the entire frequency range shown on the plot.

On the bottom is |1+OLTF|. I interpolated this to the frequency spacing of SUM and NULL spectra, and plotted SUM*|1+OLTF|, SUM, and NULL at the top.

Note that DARM OLTF template measures -1*OLTF.

Images attached to this comment
rich.abbott@LIGO.ORG - 11:00, Thursday 03 September 2015 (21179)
Nice work.  After O1 we can figure things out now you have narrowed it down.
stefan.ballmer@LIGO.ORG - 08:50, Friday 04 September 2015 (21207)
Nice work!
lisa.barsotti@LIGO.ORG - 16:26, Friday 04 September 2015 (21224)
 Great job! 

Following up on the discussion during the commissioning meeting today, at LLO Evan's equivalent plot of the coherence between the two OMC PDs is already below 10^-3 (below 3 kHz).
Images attached to this comment
evan.hall@LIGO.ORG - 13:48, Thursday 10 September 2015 (21374)

Fil and I replaced the BNC cable with an SMA/N cable.

H1 ISC
jenne.driggers@LIGO.ORG - posted 03:49, Thursday 03 September 2015 (21169)
MC2 M2 saturations causing lockloss during CARM offset reduction

I have been blaming the MICH Pit ASC loop now for a while for some locklosses that we've been seeing during the CARM offset reduction steps, specifically around the Switch_to_QPDs step (cf alog 20988).  However, when looking at MC2 for the glitch patterns from last night, I saw that perhaps we are saturating MC2's M2 coils and losing lock as a result.  

Attached below are 4 examples of this lockloss type from today.  Normally, the MC2 M2 Master out channels are well below 10,000 cts peak-to-peak, but just prior to lockloss they start to grow, and then cross over the 130k DAC count limit.  Since the IMC is near the core of all loops relating to common mode things, I still have not disentangled why this is happening, but maybe we can work on preventing it from being a problem.

Images attached to this report
H1 General
cheryl.vorvick@LIGO.ORG - posted 00:08, Thursday 03 September 2015 (21166)
OPS EVE Summary: IFO locked for more than 12 hours! Range increased steadily over the lock.

Shift Timeline:

00:45 - drop out of observing - PEM injections and violin damping resume

05:01 - went to observing

06:02 - forced lock loss for tests

 

Currently:

I had to align both TMSX and TMSY to get the green arm powers above 1.  Possibly related to the very nice 12+ hour lock we had.

 

Sheila's changes loaded

Jim is relocking

 

 

Tasks handed off from Corey:

 

- sheila, complete changes from last tnight

changes - guardian line uncommented

filters - changed from ramp to immediate

--- reloaded 07:01UTC

 

- gerardo, watch the voltages, should be about 7kV on HOVE_MY.adl - still at 7kV, handed off to Jim

 

- Robert and Anamaria - OEM injections - done now

H1 General
corey.gray@LIGO.ORG - posted 23:25, Wednesday 02 September 2015 - last comment - 11:44, Thursday 03 September 2015(21165)
Returning SDF To "Safe" State (aka Removing Differences)

After making a few "OBSERVE.snap" files for a few SDF nodes during the DAY shift, I tried taking the nodes back to their "safe.snap" files, but some of the nodes ended up having differences!  Since we need to have ZERO differences to allow going to OBSERVATION Mode, I did what I could to make the differences as close to a "safe" state as possible.  For the "safe" files which had differences, I looked used whatever .snap file which got us as close to GREEN as possible. 

Here are the Nodes I worked on, the .snap file they are currently running, and a note about differences observed:

    1.    SUS-ITMX:  safe & GOOD!——> but now has nutsinee differences!
    2.    SUS-ITMY:  safe & GOOD!
    3.    SUS-ETMX *:  safe_150902_124725 & (1) Diff:  H1:SUS-ETMX_L2_DAMP_MODE1_GAIN ???, set point 0 & currently 50—>violin 1004.54Hz
    4.    ISI-ITMy:  safe_150902_124924 & GOOD!
    5.    SUS-ETMY:  safe_150902_151039 & GOOD!
    6.    HPIITMY **:  safe_150810_115155 & (1) Diff (H1:HPI-ITMY_OUTF_H2_TRAMP?? , set point 60 & currently 5)—accept
    7.    ISIBS:  safe_150902_151938 & GOOD!
    8.    HPIBS:  safe & GOOD!

* The SUS-ETMx difference was a gain change Nutsinee made.  She returned the gain to 0.

** The HPIITMY difference was a Time Ramp, so I ACCEPTED.

Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 11:44, Thursday 03 September 2015 (21182)

Dan found that one of the modes was rung up and switched the gain for ITMX L2 DAMP MODE1,7,8,9,10 back to 0. The changes can be accepted.

H1 ISC
nutsinee.kijbunchoo@LIGO.ORG - posted 19:30, Wednesday 02 September 2015 - last comment - 11:53, Thursday 03 September 2015(21160)
Added ITMX L2 DAMP MODE 1, 7, 8, 9, 10 gains to Guardian

To damp ALL 8 frequencies of the ITMX first harmonics.

 

MODE1 damps 996.53

MODE7 damps 995.36

MODE8 damps 995.64

MODE9 damps 992.43, 992.79, 994.28, and 994.73

MODE10 damps 996.25

 

MODE1, 7, 8, 10 MUST stay on if MODE9 is on.

The damp settings have been added to the table.

Images attached to this report
Comments related to this report
nutsinee.kijbunchoo@LIGO.ORG - 22:31, Wednesday 02 September 2015 (21164)

997.7169 Hz and 998.6645 Hz identified.

daniel.hoak@LIGO.ORG - 08:21, Thursday 03 September 2015 (21174)

Tonight while collecting OMC modescan data at high power (with DARM on AS45), we found that one of the ITMx modes was ringing up with these new damping filters.  The frequency was 995.645 Hz.  We were able to construct a narrowband filter for this mode (FM5 on ITMX Mode8) and damp it easily, with positive gain and no phase shift.  Since we weren't sure which of the new filters rang up the mode, we zeroed all of the gains (for filter banks mode1, 7,8,9, and 10) and also commented them out of the guardian.  We'll have to work out later today which filter was providing the signal that was 180deg out of phase.

nutsinee.kijbunchoo@LIGO.ORG - 11:53, Thursday 03 September 2015 (21183)

MODE9 damps four frequencies with 180 deg but will ring up the other four which have 0deg. I contructed individual filters for them and 995.6447 was one of them. However, I only set MODE9 gain to 40 while the others have gains of 100 hoping that they will be damped faster than being rung up by MODE9. Not sure what's wrong but if anything gonna ring up 995.647 it's the MODE9 filter.

 

How high did it get rung up? I watched it for hours before letting Guardian turned it on but didn't see anything then.

H1 SUS (CAL, CDS, ISC)
jeffrey.kissel@LIGO.ORG - posted 16:07, Wednesday 02 September 2015 - last comment - 21:57, Wednesday 02 September 2015(21142)
The Case of the Missing 85:300 Hz z:p Pair -- Solved: The FAST I MONs Won't See It Because Of Their Construction.
J. Kissel, D. Tuyenbayv

After a quick look at the results from the UIM driver measurements taken for calibration purposes (see LHO aLOG 20846), and hearing similar whisperings of confusion from Darkhan in his detailed fitting analysis (progress continues, aLOG pending), I got the chance yesterday to quickly take a look myself to confirm my initial suspicions about the FAST I MON response to DAC drive measurements we took, and how they're "missing" the 85:300 zero:pole pair; see LHO aLOG 21127. I drove myself nuts for a half-a-day trying to reconcile the overall gain on the UL coil with what was expected to be sure *that* was right -- assuming it would provide clues if I couldn't reconcile it. I couldn't. 

I subsequently measured the respose of all UIM drivers of all QUADs and confirm that I was not insane. While the jury is still out on my sanity, at least I can confirm that
- The FAST I MON / TEST L EXC response for all four coils on all four of the Modified UIM Drivers are missing the expected 85:300 Hz zero:pole pair 
  EDIT: This is because the FAST I MONs are immune to this frequency response. See Below.
- This measurement techniue reports a factor ~2 less drive strength on the ETMY UL and LR channels, likely a busted monitor board.
- ITMY's UR and LR monitor board signals are total hosed.
I'll update the Integration Issue #9 with the later two bits of information.

EDIT: Why are the FAST I MONs Insensitive to the 85:300 [Hz] zero:pole pair? Turns out I just can't follow my own math. As it clearly states in My Notebook, you need to divide the current monitor by the output impedance -- i.e. whatever's in-between the voltage monitor pick-off and the coil current pick-off. Hence my equation I copied in LHO aLOG 21127,
                  R24_{MON}       1                   1     1       1      
DC calibration  = --------- x ---------- x G_{ADC} x --- x --- x ------- 
                  R25_{MON}   2 R5_{UIM}             E2O   CBG   G_{DAC} 
is wrong, and it should be
                  R24_{MON}       1                   1     1       1    
DC calibration  = --------- x ---------- x G_{ADC} x --- x --- x ------- 
                  R25_{MON}    2 Z_{OUT}             E2O   CBG   G_{DAC} 
where Z_{OUT} is formed by the whole R4, R5, and C12 ( = R27, R23, C26) network. This network is from where the 85:300 [Hz] zero:pole pair originates. Once I divided the transfer function with the right impedance -- voila! -- the 85:300 zero:pole pair appears.

The message again: The FAST I MONs are immune to the very frequency response we want to measure. So is every other monitor circuit, so we *have* to measure these drivers using analog electronics if we want to characterize this pole zero pair with any high precision than calculating what it should be from the component values. That being said, I don't think we'll time for this. In its stead, in case we don't find time, I checked the relevant resistor values inside spare modified UIM driver, and they we *at worst* 0.3% discrepant for all four channels on the spare. It's *very* regrettable that the monitor board appears to be giving discrepantly low DC transconductance, because that begets suspicion that the compenents are wrong, but I would be MUCH more inclined to blame the monitor board than the actual coil driver circuit given that the coil balancing gains are so similar, and using the stage hasn't brought up any issue.

Importance of this in the big picture: this re-opens the mystery of the frequency-dependent residual seen between naive model and measurment in the early results of the UIM actuation strength in LHO aLOGs 21015 and 21049. 

Stay tuned for Darkhan's results fitting the coil driver response poles and zeros that *are* there. After O1, we'll look into perfectly compensating all of these electronics, so we never have to think about this again.

Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 21:57, Wednesday 02 September 2015 (21161)
To further the explore the impact of not having measured the 85:300 z:p pair in the transconductance of the driver, let's explore how the uncertainty in the components affects the uncertainty in the DC impedance, zero and pole frequency.

Given what I saw when I measured the spare UIM driver -- for example, for the R5 = R23 = 2000 [ohm], I consistently measured between 1996 and 1993 [ohms]. Let's take a worst case scenario of 2000 +/- 10 [ohm] or +/- 0.5% -- let's say the all the relavent components have relative uncertainty to be 0.5%. We know the pole frequency of the impedance can be computed analytically as
Zpole.freq_Hz = 1 / (2*pi*(R4.value+R5.value)*C12.value) 
              = 1 / (2*pi*(750 + 2000)*0.68e-6) 
              = 85.1096 [Hz].
and the zero frequency of the impedance can be computed analytically as
Zzero.freq_Hz = 1 / (2*pi*R4.value*C12.value) 
              = 1 / (2*pi*750*0.68e-6) 
              = 312.0685 [Hz].
Recall the the transconductance is a function of the output impedance of both differential legs and the coil impedance,
TC [A/V] = Vg / (2*Zout + Zcoil)
where Vg is the voltage gain of the circuit prior to the output impedance. For the modified UIM driver, Vg = (1 + R3/R10) = (1 + R20/R15) = 2.5. 
Having Zout in denominator is why the response (i.e. the TC) of the driver has a zero at Zpole = 85 [Hz] and a pole at Zzero = 312 [Hz].

Through standard uncertainty propagation, one can obtain
Zpole.relunc = sqrt( ( ( R4.absunc^2 + R5.absunc^2 ) / ( R4.value + R5.value )^2 ) + C12.relunc^2 )
             = 0.0063 
             = 0.63 %
Zpole.absunc = pole.relunc * pole.freq_Hz
             = 0.5388 [Hz]
Zzero.relunc = sqrt( R4.relunc^2 + C12.relunc^2 )
             = 0.0071
             = 0.71%
Zzero.absunc = zero.reunc * zero.freq_Hz
             = 2.2067 [Hz]

In summary, again, if we assume a realistic spread on the component value, the pole and zero frequency will have an uncertainty of around 0.7% uncertainty, i.e. negligible.

I'll note that the compensation filters for the UIM are compensating the z:p = 85.1:312.1 [Hz] with a z:p = 299.67:85 [Hz] filter. Even if we include the above quoted uncertainty in the knowledge of the zero:pole pair, mis-compensating it as we have is at MOST a 5% systematic error by 1 [kHz], which is much less that the systematic error we're searching for in the UIM scale factor residuals, which is greater than 50% by 1 [kHz]. We'll update the model with this analytically calculated z:p pair (accompanied with the fits of the z:p = 10:1 [Hz] low-pass filters which *can* be resolved clearly from the FAST I MON measurements).
Non-image files attached to this comment
H1 CAL
kiwamu.izumi@LIGO.ORG - posted 15:36, Tuesday 01 September 2015 - last comment - 17:09, Thursday 30 June 2016(21101)
OMC DCPD signal chain,maybe missing 10-ish kHz pole in our model

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.

Non-image files attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 19:28, Tuesday 01 September 2015 (21123)

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

Images attached to this comment
Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 21:24, Tuesday 01 September 2015 (21124)

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

  • Random noise excitation in LSC-EXTRA_AO2
  • Output of the LSC-EXTRA_AO2 at the ISC rack is connected to a spear RF patch panel and routed all the way to the HAM6 area.
  • In the HAM6 area, the excitation signal is split into two by a BNC tee and drives the A and B inputs (corresponding to ch4 and ch5 respectively) of the whitening board (D1002559, S1101603).
    • Note that this time the connections are made in a single-ended manner, so that it does not exctie the negative leg of the differential receiver in the whitening board.
  • I took a transfer function from the IOP channel of LSC-EXTRA_AO2 and that of OMC DCPD A and B in order to avoid confusion from IOP's up/down-sampling filters.

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

  • AI filter of LSC-EXTRA_AO2
  • AA filter of DCPD A or B
  • flat response of the whitening filters (as I set them to 0dB with no whitening stages engaged)

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:

  • high-freq pole at around 11 kHz
  • scale factor (which should be close to 0.5 because I am driving only one leg of the differential receiver)
  • delay presumably due to some computation cycle

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.

Images attached to this comment
Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 23:00, Tuesday 01 September 2015 (21126)

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:

  • The whitening board seems to consistently show a high frequency pole at around 11 kHz
  • The zero and pole location of the 1st whitening stage seem to be inaccurate by 12% at most
  • We should  re-measure the whitenig board in a wide frequency band

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

Images attached to this comment
kiwamu.izumi@LIGO.ORG - 01:45, Wednesday 02 September 2015 (21131)

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:

  • A measurement of the whitening filter tells that we need to have two poles at high frequencies-- one at around 18 kHz and the other ar around 14 kHz
    • ( In addition, another pole at 98 kHz gives us a better fitting )
  • The whitening zero-pole pairs need to be updated in the calibration model and perhaps in the OMC front end model in order to accurately compensate the filter response.

 


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

Images attached to this comment
Non-image files attached to this comment
koji.arai@LIGO.ORG - 02:32, Thursday 03 September 2015 (21168)

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?

kiwamu.izumi@LIGO.ORG - 07:12, Thursday 03 September 2015 (21171)

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.

kiwamu.izumi@LIGO.ORG - 12:16, Thursday 03 September 2015 (21184)

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

Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 17:09, Thursday 30 June 2016 (28101)

The data for the whitening filters in the above entries are obsolete as of 30/6/2016.

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).

Displaying reports 62461-62480 of 83091.Go to page Start 3120 3121 3122 3123 3124 3125 3126 3127 3128 End