Displaying reports 70061-70080 of 77072.Go to page Start 3500 3501 3502 3503 3504 3505 3506 3507 3508 End
Reports until 19:31, Thursday 25 July 2013
H1 SUS
arnaud.pele@LIGO.ORG - posted 19:31, Thursday 25 July 2013 - last comment - 14:15, Friday 26 July 2013(7237)
beamsplitter noise

[Richard Dave Jeff Brett Arnaud]

Following aLog 7055

Today and yesterday we tried to understand why the beamsplitter suspension looks to be moving so much. In order to see higher frequency contents, we took a spectra with this time, test points channels (sampled at 16kHz). A large peak appears at 1900Hz for M1 top mass osem (2nd plot of the attached pdf) and M2 middle mass osem (3rd plot), as we saw few weeks ago on the TMSY after the power outage (see aLog 6338). The first and last plots are showing respectively the BS ISI motion (X and Y direction projected at the suspension point calibrated in um) and etmy suspension osem top mass signals, and none of them are showing such a feature.

To solve this, we tried fruitlessly several things

- power recycled IO chassis and front end h1susb123

- unplugged/replugged cables between satellite box/coil driver/AA chassis

to be continued [...]

Non-image files attached to this report
Comments related to this report
arnaud.pele@LIGO.ORG - 14:15, Friday 26 July 2013 (7248)

Richard fixed the problem, cf his aLog 7246.
attached is a spectra (from same template as aLog above) after rebooting the coil driver

Non-image files attached to this comment
H1 SEI
hugo.paris@LIGO.ORG - posted 18:48, Thursday 25 July 2013 - last comment - 21:18, Thursday 25 July 2013(7232)
BS Instability Fix

While trying to get he ISI-BS up and running (to either Level 2 or Level 3) we saw instabillity whenever turning the isolation loops on, and has been so for most of the week.

Judging by the high DC content of the supersensor signals coming out of the Blend filters, we deduced that there was some offset that was (not?) accidentally applied.

The CPS typically have some level of bias voltage, we compensate for this with a digital offset, so the error point of isolation loops -- which are DC coupled -- is small. Those offsets used to be set in the local basis. We are preparing (see E1300548) to roll off a new update to set those offsets in the cartesian basis. The latter way allows to keep track of the platform's alignement over time, in the basis of interest.

Looking more into the ISI-BS screens, we found that offsets were set in the "current" block of the blend filters. Those offsets are the equivalent of the upcoming update's "cartesian biases", and were probably set there to get the benefits of the update earlier. However, some BURT restore had left the local basis offsets on as well.

Having both offsets on at the same time, created a huge DC offset at the input of the isolation loops, which the actuators had a very difficult time pushing to zero, and eventually causing the (or many) watchdog(s) to trip, usually very early in the ST1 turn on process.

Local CPS biases were turned off. It was then possible to turn on Level 3 isolation loops on ISI-BS. 

One can still determine the alignment of the ISI by looking at the input to the CPS input to the blend filters.

Comments related to this report
brian.lantz@LIGO.ORG - 21:18, Thursday 25 July 2013 (7239)
good find.
Hopefully that CART BASIS change will be ready very soon, since the method you describe seems difficult to keep working well.
Please remember to mirror any biases in the CUR set of blend filters to the matching NXT set, or the blend switching will act in unexpected ways!

 
LHO General
patrick.thomas@LIGO.ORG - posted 18:32, Thursday 25 July 2013 - last comment - 18:51, Thursday 25 July 2013(7233)
dust monitors in LVEA down
I thought this was fixed by removing one of the dust monitors in the H1 PSL enclosure (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=7170), but the errors have returned:

...
Error: ../commands.c: 49: Sent command � not echoed
Received �
...
Comments related to this report
patrick.thomas@LIGO.ORG - 18:51, Thursday 25 July 2013 (7234)
I have restarted the IOC, and it is running again.

The change to the autoBurt.req file does not seem to have fixed the errors reported after running burtwb.
H1 AOS
jeffrey.kissel@LIGO.ORG - posted 18:26, Thursday 25 July 2013 (7226)
Restarting a BSC Chamber from IOP WD Trip to Fully Isolated (as of 07/25/2013)
J. Kissel, H. Paris, A. Pele

0) Identify the source of the trip. Take a look at the SUS WD screen, and see what path tripped the watchdog. Take a look at the ISI performance matrix, be sure you don't see tons of red. Take a look at the OSEM speedometers, make sure they're not swinging wildly.

Reset and restore SUS
1) Ramp down offsets, by hitting the "Pitch and "Yaw" button after the purple "ALIGNMENT OFFSETS" box.
2) Untrip the inner most watchdog (for the QUAD, you'll need to reset the reaction chain as well!)
3) Untrip the USER DACKILL Watchdog
4) Untrip the IOP Watchdog
5) Damping loops should automatically turn on (they're never turned off, really), but turn on the alignment offsets again.

Reset ISI
1) Ramp down FF01 filters, by setting the gain to 0 (only FM2's "FF01_2" in X,Y, and Z are on during Level 2)
2) Though the green arrows, lines, and blocks may be deceiving, make sure that the FF12C and FF12 banks are also not outputting anything either.
3) Turn off GND to ST1 and ST1 to ST2 sensor correction. Open each "SENSCOR" Bank and ramp the MATCH gains to zero, and turn off the outputs.
    (It's a 60 second ramp, so be patient.)
    (These will only be on if the previous user wanted them on, don't be alarmed if they're already off).
    (I say turn off the outputs because that's what makes the lights on the overview screen go red. Obviously, you don't *need* to do both.)
4) Run ctrlDown ${OPTIC/CHAMBER} from commands window
5) Untrip "Rogue Excitations" WD under ERRMON screen linked in bottom right corner
6) Untrip ST1, ST2, and USERDACKILL Watchdogs but hitting "reset all" (if that doesn't untrip the DACKILL, open up the screen and manually hit reset")
7) Damping loops should automatically turn on (they're never turned off really).

Reset and restore HEPI
1) Ramp down MASTER Gain (or just set to 0.0, since the WDs are tripped and nothing's going out anyway)
2) Run ctrlDown from commands window
3) Untrip inner most watchdog
4) Untrip USER DACKILL Watchdog
5) Slowly (!!) ramp up offsets. I use the follow ezcastep command, in absence of a script:
ezcastep 'H1:HPI-BS_MASTER_GAIN' '+0.01,100' -s '0.5'
ezcastep 'H1:HPI-BS_MASTER_GAIN' '+0.01,100' -s 0.5

From here on, you can follow Vincent's instructions starting at step 3, which I'll repeat here and add a little myself:


3) Turn on HEPI
     ITMY: locked. Don't worry about it. 
     BS: can only be Level 2 isolated, the IPS blends are not installed, so the command script for Level 3 is unstable. Select Level 2  for BS from the command window.
     ETMY: We have only tried Level 2. It's unclear whether Level 3 works. Select Level 2 for BS from the command window. 
4) Isolate ISI
  - Ramp up ST0 to ST1 feed-forward in X,Y and Z on BSC-ISI (there's no RX, RY, or RZ FF. This is the "FF01" bank at the top).
     - Start with Gain = 0, inputs ON, outputs ON
     - It's unclear whether FM2 "FF01_2" is associated with Level 2 isolation and FM3 "FF01_3" is associated with Level 3 isolation, and we've found that FM2 "FF0_2" works for both, so for now, we'll stick to FM2 for either level of isolation. Turn it ON
     - Making sure there's a >5 sec ramp, ramp gains to 1.0 (order and speed doesn't matter).

   Turning on the isolation loops for Level 2 and 3 are a little bit rough for the highly-sensitive inertial sensors (though the motion is not that). One must increase their watchdog thresholds during the turn on process in order for the watchdog not to trip during the turn on process. Good thresholds are: 
     - T240s: 200000
     - L4Cs: 30000
     - GS13s: 40000
Such that the system is still protected, tighten the thresholds on the CPS to 15000.
   - Make sure you have blend filters set to "750 mHz" for ST1 and "250mHz" for Stage 2, using the "SWITCH ALL" button on the top middle of the blend filter screens. We were only able get ISI-ITMY to Level 3 with ST1 set to "250 mHz."
   - Hit Level 2 or Level 3. You must be very patient, and be sure you've follow all of the above instructions to a T, or one, a few, several, or all watchdogs will trip on you and it's back to step 1. Budget 20 minutes.
   - IF THE WATCHDOG TRIPS DURING THE ISOLATE PROCESS, GO BACK to "Reset ISI" Step 4).
   - After waiting some time (a few minutes), the T240s will settle down to within +/- 2000 [cts] on the input to INPUT FILTERs. 
   - Switch the ST1 blends to "T240mHz" in all DOFs.
   - Note that if you're browsing through filter banks (specifically the ISO bank, but others as well), there will be several filters that are empty that the script will turn on, raising your suspicion when things go awry. This is such that the controller turn on process can be generic, don't worry about it. 

Stop Here if you don't want/need sensor correction or green cavity offloading

6) HEPI Green Arm Locking Offload -- on H1:HPI-ETMY only
This is only necessary if you want to keep the arm locked with the green ALS on the time scale of hours. If you don't need the green for long, or if you've switched to red control of the cavity, you don't need this. However, if you do, everything in HEPI is on as it should be. The way to turn it on in the LSC screen: SITEMAP > LSC > Overview > look for "YARM" in the bottom middle of the screen. Open the bank and turn ON the output.

7) Sensor correction
It's unclear (at least) if this is commissioned well, the low frequency performance of the cavities have not really been characterized with it on (i.e. they saw it cause excess low-frequency once, via the camera, and said "don't bother" and it stuck). However, to bring it up, 
    GND to ST1 (from GND STS2s) sensor correction:
    - In the "GROUND" bank of the ST1 SENSCOR filters,
    - Make sure the "MATCH" filter is on (it's just a ~few percent gain correction filter), ever other 
    - Turn on the output of the "MATCH" bank 
    - Make sure there's a very large tramp in the MATCH bank
    - Ramp the gain to +1.0
    ST1 to ST2 (from T240s) sensor correction:
    - In the ST2 SENSCOR filters,
    - (No MATCH filter)
    - Turn on the output of the "MATCH" bank 
    - Make sure there's a very large tramp in the MATCH bank
    - Ramp the gain to +1.0
LHO General
patrick.thomas@LIGO.ORG - posted 18:19, Thursday 25 July 2013 (7231)
dust monitor locations
I moved the list of current dust monitor locations from the whiteboard in the control room to the wiki here: https://lhocds.ligo-wa.caltech.edu/wiki/DustMonitorLocations

Please update it if you know that a dust monitor has moved.
LHO General
patrick.thomas@LIGO.ORG - posted 17:51, Thursday 25 July 2013 (7230)
updated dust monitor autoBurt.req files
I updated the autoBurt.req files in /ligo/lho/h0/target/h0dust[dr|ex|ey|lab|lvea|mx|my]. The new files mark the names ending with COMMAND as read only. I believe this may fix errors reported when writing back snapshots. I used a script which parsed the database files and wrote names marked read only if the string '[RO]' was found in the record's DESC field. Previously they were marked read only based on the record type.
H1 AOS
dale.ingram@LIGO.ORG - posted 17:13, Thursday 25 July 2013 (7229)
EX Cryopump Baffle Installation Photos
The photo collection for the baffle installation now sits in ResourceSpace.  Outreach took the prep photos on 7/19.  Mitchell shot the install photos this morning.
Images attached to this report
LHO General
justin.bergman@LIGO.ORG - posted 16:07, Thursday 25 July 2013 (7227)
ops

0800 Found multiple IPC errors on H1SEIB1,H1SEIB2,H1SEIB3---all resulting from some kind of hiccup from H1SUSB123. I reset all the IPC errors and they did not recur during the shift.

900-1030 Patrick covering; notes increasing dust counts between HAM2/3 where the cleanroom had temporarily been turned off

950 MarkB and Arnaud investigating noise on BS

950-1030  Richard disconnecting coil driver sensors on BS (DaveB running IOP bypass on SUSB123 and SEIB2)

1200 Problems with PSL refcav...Stefan/Rick investigating

1343 Frank and Luis to EY to work on racks (not working in laser hazard zone)

1400 During BS noise investigations the watchdogs were tripped for ISI-ITMY and ISI-BS. Hugo/Justin reset ITMY but found the BS suspension had Master Switch toggled (Richard) and we did not reset these WDs

1405 Colin/Pablo continuing Pcal alignment in H2 Enclosure

1425 Undergrad Andres Mellina notified operator that he would be energizing the NPRO in OSBOL per WP#4048---agreed to complete work and notify operator by 1600. Did not anticipate needing more than 5mW.

1539 Operator notified by Andres that laser work complete for the day in OSBOL.

H1 SUS
travis.sadecki@LIGO.ORG - posted 15:01, Thursday 25 July 2013 (7225)
ETMx lower structure installed

A. Ramirez, T. Sadecki

The lower structure of the ETMx has been mounted onto the cartridge.  I promise there is a monolithic suspension under that C3! (See pic).

Images attached to this report
H1 ISC
stefan.ballmer@LIGO.ORG - posted 12:08, Thursday 25 July 2013 (7224)
Instructions for Handing OFF Green Arm Cavity Lock to Red
Here is a short how-to on the scrips and procedure we use to lock on red:

I assume that the the PLL and PDH loop at EY are closed, and we have green light in the arm. I also assume the IMC is locked on Red.
-1) open dataviewer template /ligo/home/controls/sballmer/templates/HIFOYsignalsV2.xml

0) Make sure the clean room fans on HAM1 and HAM3, and the table fans on IOT2 and ISCT1 are off.
1) Align arm cavity using TMSY and ITMY to minimize H1:ALS-Y_REFL_B_LF_OUT_DQ (Out of lock is about 22000cts, a good alignment is about 9000cts).
2) Make sure you're on the beat note is on the RF PD using H1:ALS-C_TRY_A_DC_VOLTS by moving the Beam Splitter (trace 5 in template, on by default)
3) Make sure you have a RF beat node on H1:ALS-C_COMM_A_DEMOD_RFMON (you should get more than -29dBm) by moving the beam splitter (trace 6 in template, need to swap from trace 5)
4) In /opt/rtcds/userapps/release/als/h1/scripts, run CARM_handoff
5) Count the number of wavelengths in the arm if you get an even number, set H1:ALS-C_COMM_VCO_TUNEOFS (COMM VCO offset) to -1.6V, if you get odd number, set it to 1.04V (or just try both values and check which one gets you on fringe.)
6) tweak H1:ALS-C_COMM_VCO_TUNEOFS to get the error signal H1:LSC-REFLAIR_A_RF9_I_OUT close to zero.
7) In /opt/rtcds/userapps/release/als/h1/scripts, run CARM_Green2Red
H1 ISC
stefan.ballmer@LIGO.ORG - posted 01:28, Thursday 25 July 2013 - last comment - 01:36, Thursday 25 July 2013(7220)
HIFOY left locked on red light
HIFOY was left locked on red light tonight. The clean lock is starting at 08:19 UTC on 07/25/2013.

The main error signal is H1:LSC-CARM_IN1_DQ. It is calibrated in Hz Green (but not closed loop corrected - for that see my other log entry).

The noise seen by the channel is most likely IMC noise, but checking for correlations with ETMY, ITMY and their ISI's is also worth it.
Comments related to this report
jeffrey.kissel@LIGO.ORG - 01:36, Thursday 25 July 2013 (7221)
Here're the configurations of the relevant seismic isolation systems:

Chamber    HEPI                                   ISI                               SUS
HAM1       Locked                                 n/a                               n/a
HAM2       Floating, Alignment Offsets Only       Level 2 Isolated                  MC1, MC3, PRM damped Level 1.5; PR3 damped Level 1.0
HAM3       Floating, Alignment Offsets Only       Level 2 Isolated (eLIGO Blends)  MC2, PR2 damped Level 1.5 
BS         Level 2 Isolated (Position Locked)     Damping Only                      BS damped Level 2.0
ITMY       Locked                                 Damping Only                      ITMY damped Level 2.1
ETMY       Level 2 Isolated (Position Locked)     Damping Only                      ETMY damped Level 2.1, TMSY damped Level 2.0


H1 ISC
stefan.ballmer@LIGO.ORG - posted 01:04, Thursday 25 July 2013 - last comment - 13:35, Sunday 22 September 2013(7215)
Input Mode Cleaner transmitted frequency noise
(Jeff, Kiwamu, Stefan)

With the H1:LSC-REFLAIR_A_RF9_I calibrated in Hz, and the open loop transfer function measured, here is the noise it sees: Input Mode Cleaner transmitted frequency noise.
Also plotted is dark noise (shutter closed).

We do not know yet what the ugly noise ~1/f^3 noise is.
Images attached to this report
Comments related to this report
stefan.ballmer@LIGO.ORG - 01:10, Thursday 25 July 2013 (7217)
The loop transfer functions are attached:

Open loop gains:
CARM_OLG_RED.txt
CARM_OLG_GREEN.txt

Closed loop gains:
CARM_CLG_RED.txt
CARM_CLG_GREEN.txt

Inverse closed loop gains
CARM_iCLG_RED.txt
CARM_iCLG_GREEN.txt


Inverse closed loop gain with a factor of 1/2 gor Green Hz to Red Hz conversion: 
CARM_iCLG_RED_g2r_special.txt
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 10:50, Friday 26 July 2013 (7243)
S. Ballmer, J. Kissel

We had made an estimate for the coil driver noise in low-noise mode (State 3, ACQ off, LP ON), and ruled it out. However, I've checked the state of the Binary IO switches, and MC2 is running in State 2, ACQ ON, LP OFF, and and MC1 and MC3 are running in State 1, ACQ OFF, LP OFF. We'll try for this measurement again, with the coil drivers in their lowest-noise mode.
stefan.ballmer@LIGO.ORG - 17:25, Tuesday 06 August 2013 (7366)
jeffrey.kissel@LIGO.ORG - 13:35, Sunday 22 September 2013 (7825)
I've plotted the above-attached, red and green, open loop gain transfer functions (see *_full.pdf attachment). Through trial and error, I figured out that the text file columns are (freq [Hz], magnitude [dB], phase [deg]). And remember these are IN1/IN2 measurements, so it's a measurement of - G, not G (which is why the phase margin is between the data and 0 [deg], not -180 [deg]). 

Also, because the data points around the UGF were so sparse, I interpolated a 50 point fit around the UGF to get a more precise estimate of the unity crossing and phase margin. See _zoom.pdf for a comparison of the two estimates. I get the following numbers (rounded to the nearest integer) for the raw estimate and the fit estimate:

The raw CARM UGF is: 136 [Hz], with a phase margin of: 33 [deg]
The Fit CARM UGF is: 146 [Hz], with a phase margin of: 30 [deg]
The raw CARM UGF is: 169 [Hz], with a phase margin of: 35 [deg]
The Fit CARM UGF is: 170 [Hz], with a phase margin of: 34 [deg]

Non-image files attached to this comment
H1 ISC
kiwamu.izumi@LIGO.ORG - posted 01:03, Thursday 25 July 2013 - last comment - 02:37, Thursday 25 July 2013(7216)
Infrared locked for the first time to the arm cavity

[Stefan and Kiwamu]

 We handed the CARM control from the green ALS beatnote sensor over to the REFL infrared demodulated signal. This worked well.

In this configuration, the PSL frequency was locked to the arm cavity and no green light was involved any more. The lock stayed for more than 20 minutes and was long enough to do some further noise investigations.

 

Update on Noise plot:

We tested two configurations :

  • (A) ordinary HIFO CARM noise setup .
    • CARM is controlled via the ALS green beatnote and the red demod signal serves as an out-of-loop sensor
  • (B) Infrared control configuration:
    • CARM is controled via the infrared REFL demod signal and the ALS beatnote serves as an out-of-loop sensor

In both cases we have three sensors to evaluate the noise performance. We had two channels for the ALS beatnote, which are REFL_SERVO_SLOW and ALS-C_COMM_A_RF_I. The difference is that COMM_A_RF_I is digitized before the common mode board and REFL_SERVO is digitized after the board. Ideally they should be always the same. The last signal is the infrared signal, REFLAIR_A_RF9_I, which is the one derived from the reflected light off of the arm cavity and demodulated at 9 MHz.

 

Configuration (A)

(Red): The infrared sensor. Therefore this is the in-loop signal for CARM

(Blue): Beat signal at ALS-C_COMM_A_RF_I. Out-of-loop.

(Green) : Beat signal at LSC-REFL_SERVO. Out-of-loop.

Configuration (B)

(Brown): The infrared sensor. Out-of-loop

(Pink): Beatnote at ALS-C_COMM_A_RF_I

(Cyan): Beatnote at LSC-REFL_SERVO. This is the in-loop error signal

Some other noise

(Black): beat-note readout electronics noise at LSC-REFL_SERVO

 

What we did:

  • Calibration of ALS-C_COMM_A_RF_I into green beat frequency.
    • This was done by tweaking the filter modules to reflect the current SR560 setup which is out of the VCO PLL.
  • Calibration of REFL_SERVO_OUT into the green beat frequency.
    • This was done by comparing this signal with ALS-C_COMM_A_RF_I and making it identical with the digital filters in the LSC front end.
  • Calibration of the LSC-REFLAIR_A_RF9_I into the green beat frequency.
    • This was done by multiplying a factor of 2 in its gain since this was already calibrated to the infrared frequency.
  • We re-edited the handing script, CARM_hanoff to reflect these changes.
    • We confirmed that the script runs fine.
  • Then we engaged the ALS CARM servo as usual.
  • We brought the PSL frequency to a resonance of the infrared light in the arm cavity by fiddling with the COMM VCO.
  • Hading over the signal from that of ALS to the REFL infrared signal
    • This was done by simultaneously zeroing LSC-REFL_SERVO_OUT_GAIN and increasing the LSC-REFLAIR_A_RF_I_GAIN in 5 seconds.
    • There was no problem since the signals were all identical due to the calbration.
  • Apart from ALS and CARM, we tried to calbrate the MC2 M3 suspension actuator by using the green beatnote as a reference.
    • According to Jeff.K the M3 actuator should have a response of 1.5e-15 m/cnts at 20 Hz.
    • However we measured it to be 6e-16 although this is not accuate since the value varied in every measurement.
Images attached to this report
Non-image files attached to this report
Comments related to this report
stefan.ballmer@LIGO.ORG - 01:14, Thursday 25 July 2013 (7218)
Attached is the attempt to calibrate MC2 using the beat-node signal. The horizontal bar is at 6e-16m/ct.
The variability is most likely due to saturation. Without frequency feed-back the beat-node signal tends to run into its range limit.

The calibration should be redone with the REFLAIR diode.
Images attached to this comment
jeffrey.kissel@LIGO.ORG - 01:17, Thursday 25 July 2013 (7219)
Here's the plot I'd made to re-create this transfer function in the model, as requested by Kiwamu and Stefan.
Non-image files attached to this comment
stefan.ballmer@LIGO.ORG - 02:37, Thursday 25 July 2013 (7222)
Some additional items:
- the REFLAIR_A_RF9_I was calibrated into Red Hz by adding a filter with a gain of 82Hz/(2*1000cts) and a z82:p1e3 cavity pole compensator.
- We noticed the the green PDH error sigal at EY (as seen at the analog Imon signal from the demos board) has about 2.5Vpkk signal at ~28kHz. Given that it sometimes bleeds over into the Q sigal, I am pretty sure that we are saturating an RF amplifier before the demos board.
H1 SUS
brett.shapiro@LIGO.ORG - posted 21:02, Wednesday 24 July 2013 - last comment - 20:36, Saturday 27 July 2013(7214)
ETMY long ISI WIT to cavity measurement agrees with quad model within a factor of 1.5
The attached plot shows a measurement of the ETMY from the ISI L witness sensor to the cavity displacement against the quad model from the suspension gnd L input to the test mass L output. Overall there is good agreement except for the factor of about 1.5 between the model and measurement (the model is greater).

relevant details:

The quad model is the MATLAB struct variable susModel in 
/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/FilterDesign/MatFiles/dampingfilters_QUAD_2013-06-14_Level2p1_RealSeismic_model.mat

The data was collected starting at GPS time 1058680016 based on Jeff Kissel's log 7194. This time was set to be some arbitrary short time after Jeff's recorded time of when the cavity was set at GPS time 1058670016. The state of the IFO at this time is given by that log, 7194, though the state of the ISI isolation at that time is questionable based on the ASDs and trend data of that time. 

The measured transfer function comes from the DTT export file: 
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/Common/Data/2013-07-23_CavityTFMeasurements_TF
There is a corresponding coherence file
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/Common/Data/2013-07-23_CavityTFMeasurements_Coh
These files are exported from the DTT file
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/Common/Data/2013-07-23_CavityTFMeasurements.xml
This TF and coherence data was exported in the following order:

1.  H1:SUS-ETMY_M0_ISIWIT_L_DQ to H1:ALS-Y_REFL_CTRL_OUT_DQ
2.  H1:SUS-ETMY_M0_ISIWIT_L_DQ to H1:SUS-ETMY_L3_OPLEV_PIT_OUT_DQ
3.  H1:SUS-ETMY_M0_ISIWIT_L_DQ to H1:SUS-ETMY_L3_OPLEV_YAW_OUT_DQ
4.  H1:SUS-ETMY_M0_ISIWIT_T_DQ to H1:ALS-Y_REFL_CTRL_OUT_DQ
5.  H1:SUS-ETMY_M0_ISIWIT_T_DQ to H1:SUS-ETMY_L3_OPLEV_PIT_OUT_DQ
6.  H1:SUS-ETMY_M0_ISIWIT_T_DQ to H1:SUS-ETMY_L3_OPLEV_YAW_OUT_DQ
7.  H1:SUS-ETMY_M0_ISIWIT_V_DQ to H1:ALS-Y_REFL_CTRL_OUT_DQ
8.  H1:SUS-ETMY_M0_ISIWIT_V_DQ to H1:SUS-ETMY_L3_OPLEV_PIT_OUT_DQ
9.  H1:SUS-ETMY_M0_ISIWIT_V_DQ to H1:SUS-ETMY_L3_OPLEV_YAW_OUT_DQ
10. H1:SUS-ETMY_M0_ISIWIT_R_DQ to H1:ALS-Y_REFL_CTRL_OUT_DQ
11. H1:SUS-ETMY_M0_ISIWIT_R_DQ to H1:SUS-ETMY_L3_OPLEV_PIT_OUT_DQ
12. H1:SUS-ETMY_M0_ISIWIT_R_DQ to H1:SUS-ETMY_L3_OPLEV_YAW_OUT_DQ
13. H1:SUS-ETMY_M0_ISIWIT_P_DQ to H1:ALS-Y_REFL_CTRL_OUT_DQ
14. H1:SUS-ETMY_M0_ISIWIT_P_DQ to H1:SUS-ETMY_L3_OPLEV_PIT_OUT_DQ
15. H1:SUS-ETMY_M0_ISIWIT_P_DQ to H1:SUS-ETMY_L3_OPLEV_YAW_OUT_DQ
16. H1:SUS-ETMY_M0_ISIWIT_Y_DQ to H1:ALS-Y_REFL_CTRL_OUT_DQ
17. H1:SUS-ETMY_M0_ISIWIT_Y_DQ to H1:SUS-ETMY_L3_OPLEV_PIT_OUT_DQ
18. H1:SUS-ETMY_M0_ISIWIT_Y_DQ to H1:SUS-ETMY_L3_OPLEV_YAW_OUT_DQ
19. H1:SUS-ITMY_M0_ISIWIT_L_DQ to H1:ALS-Y_REFL_CTRL_OUT_DQ
20. H1:SUS-ITMY_M0_ISIWIT_L_DQ to H1:SUS-ITMY_L3_OPLEV_PIT_OUT_DQ
21. H1:SUS-ITMY_M0_ISIWIT_L_DQ to H1:SUS-ITMY_L3_OPLEV_YAW_OUT_DQ
22. H1:SUS-ITMY_M0_ISIWIT_T_DQ to H1:ALS-Y_REFL_CTRL_OUT_DQ
23. H1:SUS-ITMY_M0_ISIWIT_T_DQ to H1:SUS-ITMY_L3_OPLEV_PIT_OUT_DQ
24. H1:SUS-ITMY_M0_ISIWIT_T_DQ to H1:SUS-ITMY_L3_OPLEV_YAW_OUT_DQ
25. H1:SUS-ITMY_M0_ISIWIT_V_DQ to H1:ALS-Y_REFL_CTRL_OUT_DQ
26. H1:SUS-ITMY_M0_ISIWIT_V_DQ to H1:SUS-ITMY_L3_OPLEV_PIT_OUT_DQ
27. H1:SUS-ITMY_M0_ISIWIT_V_DQ to H1:SUS-ITMY_L3_OPLEV_YAW_OUT_DQ
28. H1:SUS-ITMY_M0_ISIWIT_R_DQ to H1:ALS-Y_REFL_CTRL_OUT_DQ
29. H1:SUS-ITMY_M0_ISIWIT_R_DQ to H1:SUS-ITMY_L3_OPLEV_PIT_OUT_DQ
30. H1:SUS-ITMY_M0_ISIWIT_R_DQ to H1:SUS-ITMY_L3_OPLEV_YAW_OUT_DQ
31. H1:SUS-ITMY_M0_ISIWIT_P_DQ to H1:ALS-Y_REFL_CTRL_OUT_DQ
32. H1:SUS-ITMY_M0_ISIWIT_P_DQ to H1:SUS-ITMY_L3_OPLEV_PIT_OUT_DQ
33. H1:SUS-ITMY_M0_ISIWIT_P_DQ to H1:SUS-ITMY_L3_OPLEV_YAW_OUT_DQ
34. H1:SUS-ITMY_M0_ISIWIT_Y_DQ to H1:ALS-Y_REFL_CTRL_OUT_DQ
35. H1:SUS-ITMY_M0_ISIWIT_Y_DQ to H1:SUS-ITMY_L3_OPLEV_PIT_OUT_DQ
36. H1:SUS-ITMY_M0_ISIWIT_Y_DQ to H1:SUS-ITMY_L3_OPLEV_YAW_OUT_DQ

Note, the cavity signal H1:ALS-Y_REFL_CTRL_OUT_DQ is calibrated in Hz. The ISI witness signals are calibrated in nm. The calibration of the optical levers is unknown.

The measured transfer function was scaled by multiplying it by 
7.0982e-12 [m/Hz] / 1e-9 [nm/m] = 0.0070982 [m^2 / (nm Hz)]
The 7.0982e-12 [m/Hz]  comes from
lambda*L/c
where lambda = (1064e-9 / 2) [m], for the green light wavelength
L = 4000 [m], for the arm length
c = 299792458 [m/s], for the speed of light
Images attached to this report
Comments related to this report
brett.shapiro@LIGO.ORG - 19:31, Thursday 25 July 2013 (7236)
Brett and Jeff

Summary:

I have managed to account for the missing 1.5 factor by adding in the pitch to cavity transfer functions. See the first attached figure. The black curve is the model of the SUS point longitudinal to cavity. The red curve is the same measurement of the SUS point witness sensor (H1:SUS-ETMY_M0_ISIWIT_L_DQ) to cavity (H1:ALS-Y_REFL_CTRL_OUT_DQ) transfer function measured in log 7214. Thus, the same factor of 1.5 exists between these curves. It turns out that the cavity also has a lot of coherence in the same frequency band from the SUS point pitch witness sensor (H1:SUS-ETMY_M0_ISIWIT_P_DQ). So, I followed the assumption that I could account for the missing factor by simply measuring the pitch to cavity transfer function, converting it to length coordinates, and adding it to the longitudinal transfer function. The blue curve is this transfer function converted to length units. The conversion from rotation to length units was done using the measured transfer function from the pitch SUS point witness to the length SUS point witness. The magenta curve is the coherent sum of the two transfer functions. This magenta transfer function agrees much better with the model.


Details:

What I hadn't taken into account before is that the measured transfer functions between the ISI and cavity are passive. Thus, there are 6 simultaneous excitations influencing the cavity through ETMY which are the 6 DOFs of STG2 of the ETMY ISI. It turns out that 2 of these excitations are coherent to the cavity as well as themselves. The two are the ISI pitch witness and the ISI longitudinal witness. The argument justifying/explaining why one must sum the pitch and long witness to cavity transfer functions in order to agree with the modeled SUS point long to cavity transfer function is intended to be explained in detail in a future document. It will be summarized briefly here.

Since the witness long and pitch TFs have good coherence in a band around 1 Hz, (where the measurement needed help matching the model), the long and pitch displacement can be thought of as transformed versions of the same noise. Fundamentally, the noise must be thought of together as a single long-pitch source (analogous to how SUS long and pitch modes are really long-pitch modes), rather than thinking of them separately. The relation projecting the long-pitch seismic motion into long and pitch components is determined by the coherent transfer function between long and pitch. 

To get the right measurement to match the model, we must find the transfer function between the long-pitch seismic source and the cavity signal. Since none of our measurements directly measure this long-pitch source, we must effectively recreate is with the measured transfer functions from its components. Those transfer function components are then summed coherently as described in the summary above and in the attached plot.
Non-image files attached to this comment
brett.shapiro@LIGO.ORG - 19:53, Thursday 25 July 2013 (7238)
It seems that during these measurements, the ETMY ISI was indeed only damped while the ITMY ISI was isolated. This is evident given the large discrepancy in measured ISI WIT L and P ASDs between the two ISIs. See the attached figure.

This data is collected in the DTT file 
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/Common/Data/2013-07-23_CavityASDMeasurements.xml
and exported in the file
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/Common/Data/2013-07-23_CavityASDMeasurements_Export

The exported data is exported in the following order:

1. H1:ALS-Y_REFL_CTRL_OUT_DQ
2.  H1:SUS-ETMY_M0_ISIWIT_L_DQ
3.  H1:SUS-ETMY_M0_ISIWIT_T_DQ
4.  H1:SUS-ETMY_M0_ISIWIT_V_DQ
5.  H1:SUS-ETMY_M0_ISIWIT_R_DQ
6.  H1:SUS-ETMY_M0_ISIWIT_P_DQ
7.  H1:SUS-ETMY_M0_ISIWIT_Y_DQ
8.  H1:SUS-ETMY_L3_OPLEV_PIT_OUT_DQ
9.  H1:SUS-ETMY_L3_OPLEV_YAW_OUT_DQ
10. H1:SUS-ETMY_MASTER_OUT_F1_DQ
11. H1:SUS-ETMY_MASTER_OUT_F2_DQ
12. H1:SUS-ETMY_MASTER_OUT_F3_DQ
13. H1:SUS-ETMY_MASTER_OUT_LF_DQ
14. H1:SUS-ETMY_MASTER_OUT_RT_DQ
15. H1:SUS-ETMY_MASTER_OUT_SD_DQ
16.   H1:SUS-ITMY_M0_ISIWIT_L_DQ
17.  H1:SUS-ITMY_M0_ISIWIT_T_DQ
18.   H1:SUS-ITMY_M0_ISIWIT_V_DQ
19.   H1:SUS-ITMY_M0_ISIWIT_R_DQ
20.   H1:SUS-ITMY_M0_ISIWIT_P_DQ
21.   H1:SUS-ITMY_M0_ISIWIT_Y_DQ
22.   H1:SUS-ITMY_L3_OPLEV_PIT_OUT_DQ
23.   H1:SUS-ITMY_L3_OPLEV_YAW_OUT_DQ
24. H1:SUS-ITMY_MASTER_OUT_F1_DQ
25. H1:SUS-ITMY_MASTER_OUT_F2_DQ
26. H1:SUS-ITMY_MASTER_OUT_F3_DQ
27. H1:SUS-ITMY_MASTER_OUT_LF_DQ
28. H1:SUS-ITMY_MASTER_OUT_RT_DQ
29. H1:SUS-ITMY_MASTER_OUT_SD_DQ

Note, the cavity signal H1:ALS-Y_REFL_CTRL_OUT_DQ is calibrated in Hz. The ISI witness signals are calibrated in nm. The calibration of the optical levers is unknown. The MASTER_OUTs calibration is also unknown to me.
The fist column of the exported data is the frequency vector. Each exported channel then follows in order, occupying the remaining columns. The transfer function export in 7214 above follows a similar pattern, except that each channel occupies two columns. The first is the real part of the transfer function data, the second is the complex part.
Non-image files attached to this comment
brett.shapiro@LIGO.ORG - 20:36, Saturday 27 July 2013 (7256)
After doing some modeling in MATLAB, the analysis in 7236 stating that it is necessary to consider both the pitch and longitudinal seismic noise in the transfer function to the cavity looks to be incorrect. The transfer function between the longitudinal ISI witness sensor and the cavity motion should indeed replicate the quad MATLAB model transfer function between the suspension point and test mass L DOF. Thus, it appears there is a calibration error of 2 in measured transfer function.
H1 SUS
jeffrey.kissel@LIGO.ORG - posted 15:26, Monday 22 July 2013 - last comment - 07:58, Monday 29 July 2013(7154)
18 bit DAC Noise Revisited, with Excitation and at Low Frequency
To date and the best of my knowledge, the only measurements of the 18-bit DAC noise have been those performed by J. Heefner, documented in T0900338, where the DAC noise is quoted as 150 [nV/rtHz] (and flat in the frequency band he probed). We'd learned from eLIGO (lessons by Tobin, myself,Matt, and Nic) that a DAC's noise floor changes when excitation is present, so Jay had measured the DAC noise while injecting a single-frequency line at ~100 [Hz], and then measured the high-frequency asymptote (his plots are on a linear x axis, without a grid so one can really only see the results above 100 Hz).

In the interest of suspension performance in the 0.1-10 [Hz] band where cavities are currently sensitive to their optic's motion, I've now characterized the noise in detail at low-frequency (0.05-1e3 [Hz], with focus on 0.05-50 [Hz] band), using a realistic output spectrum as the requested voltage. The results are attached and described below. Since the results are clearly non-linear, we may need to try different input spectra (working a little harder than I did to balance the SR785 range vs. noise) to really understand it. Naturally, we should also develop a model of the quantization noise, to see if we can differentiate this from just bad, non-linear electronics noise. Finally, we should also perform this same measurements on a 16-bit DAC.

Note that, by default, the user-model-to-IOP-model exchange is done with zero-padding, as has become the default configuration for all models.

--------
Plots and Captions

2013-07-21_2119_H1SUSMC2_DACOutput_ModeCleanerLocked_ASDs.pdf
During a fully functional Input Mode Cleaner lock, this is the output voltage requested of the DAC at all three stages. The spectra seen at the TOP/M1 stage is totally confusing to me, so I ignored it, as it was distracting to this study to try and figure out. More on that to come later. As such, (and also informed by the input range vs. noise floor of the SR785 at these frequencies), I chose the Middle / M2 stage spectra as my representative spectra.

experimentalsetup.pdf
Diagram of how the experiment was set up. For this study, I commandeered the H1 SUS QUAD Test Stand. This is a fully-production quality test stand, running up-to-date software, and up to which nothing is hooked, so it was the perfect test bed. The Pomona box that was used to switch between output channels (borrowed from MIT) was a easy, convenient way to grab the signals, keeping them shielded, without having to mess with the usual breakout boards and clip leads -- a set up usually fraught with excess unwanted noise.

2013-07-21_H1SUSQUADTST_DACNoise.pdf The Results
PG1: Here is the digitally requested spectrum, calibrated into voltage out of the AI filter (i.e. cts at the COILOUTF_??_EXC point, multiplied by the gain of the DAC, 20 / 2^18 [V/ct]). It is compared with the measurement noise floor (for the low-frequency, 0.05 - 50 [Hz] band, with -10 [dBVpk] SR785 input range), and the measured DAC noise with no digital output requested. The "traveling notches" in the requested drive are used to carve out at the DAC noise without disrupting the main frequency content of the signal. Note that because of SR785 range vs. noise issues, I sent out a requested signal with a factor of 10 less RMS voltage at 1e-2 [Vrms]. This is compared with the M2 stage (with 1e-1 [Vrms]) and 

PG2 - 4:
The measured DAC noise output at the AI chassis for 3 DAC channels. We see, rather obviously that none of the notches below 10 [Hz], indicating a several elevated DAC noise floor. I've included a quick by-eye fit to the noise, which indicates that the DAC noise is 6e-6 * (10 [Hz] / f) [V/rtHz], with this excitation. 

Notes:
- Even though the SR785 measurement is focused on the 0.05 - 50 [Hz] band, the full spectrum out to several [kHz] is requested during all measurements.
- It's unclear to me why the shape and level of the DAC noise changes when I switch to the higher measurement band (10 to 810 [Hz]). Since I saw the DAC noise floor after the natural 100 [Hz] roll-off of the output spectra while retaining the 30 [Hz] notch (and it was Sunday at 8pm), I didn't bother traveling the notch any further, and therefore only have one measurement for each channel in this band.

-----------
Details:
The template for the mode cleaner output request spectra can be found here:
${SusSVN}/sus/trunk/HSTS/H1/MC2/Common/Data/2013-07-21_2119_H1SUSMC2_DACOutput_ModeCleanerLocked_ASDs.xml

The input spectra is defined by the following AWGGUI Foton String which filtered white ("uniform") noise:

amplitude  = 100000 to get 1e-2 [Vrms]

zpk([1.3;1.3;1.3;1.3;1.3;1.3],[0.3;0.3;0.3;0.3;0.3;0.3],1,"n")ellip("LowPass",4,1,80,100)
notch(0.47,10,200)notch(0.5,10,200)notch(0.52,10,200)
notch(0.9,10,200)notch(1,10,200)notch(1.1,5,200)
notch(4.7,10,200)notch(5,10,200)notch(5.2,5,200)
notch(10,5,200)notch(11,5,200)notch(12,2.5,200)
notch(30,5,200)notch(32,5,200)notch(34,2.5,200)
I'm *sure* there's a more elegant way of defining it, but ... so it goes.

The captured digital output spectra templates can be found here:
${SusSVN}/sus/trunk/QUAD/H1/QUADTST/Common/Data/18Bit_DACNoise_2013-07-21/
2013-07-21_H1SUSQUADTST_DACNoise_COILOUTF_AvgASDw0p45-0p5-0p55HzTipleNotch_ASDs.xml
2013-07-21_H1SUSQUADTST_DACNoise_COILOUTF_AvgASDw0p9-1-1p1HzTipleNotch_ASDs.xml
2013-07-21_H1SUSQUADTST_DACNoise_COILOUTF_AvgASDw4p5-5-5p5HzTipleNotch_ASDs.xml
2013-07-21_H1SUSQUADTST_DACNoise_COILOUTF_AvgASDw10-11-12HzTipleNotch_ASDs.xml
2013-07-21_H1SUSQUADTST_DACNoise_COILOUTF_AvgASDw30-32-34HzTipleNotch_ASDs.xml


The raw SR785 data files can be found here:
${SusSVN}/sus/trunk/QUAD/H1/QUADTST/Common/Data/18Bit_DACNoise_2013-07-21/SCRN*.TXT
with a key to what each number means in
${SusSVN}/sus/trunk/QUAD/H1/QUADTST/Common/Data/18Bit_DACNoise_2013-07-21/2013-07-21_MeasNotes.txt

The data is analyzed, and plots are produced with the following script:
${SusSVN}/sus/trunk/QUAD/H1/QUADTST/Common/Scripts/plot18bitdacnoise_20130721.m  



Non-image files attached to this report
Comments related to this report
christopher.wipf@LIGO.ORG - 13:43, Thursday 25 July 2013 (7223)

I used Matlab to model the quantization noise associated with Jeff's measurement.  Here's the punchline: The "hiFreq" measurement series is consistent with quantization noise. The excess noise seen in the "loFreq" measurements is not.

The attached plot tells the story.  The blue curve (mostly submerged under the red one) is the spectrum of Jeff's excitation, calculated with double precision as the front end would do.  The solid red curve is what you get after applying 4x interpolation, and rounding the signal so it matches the 18-bit precision of the DAC.  The 18-bit curve overlaps the double-precision curve almost everywhere -- except in the bottom of the notch and past the cutoff of the LP filter.  In those two places, it's limited by round-off error, also known as "quantization noise".  This noise floor is shown by the dotted red curve, which is the spectrum of the double signal minus the 18-bit signal.

The black curves are taken from Jeff's measurements.  For the solid curves, the excitation was on; for the dotted curves it was off (requested DAC output = 0).  The dotted curves are presumably limited by the electronics noise of the DAC. As for the solid curves, the "hiFreq" data reaches the quantization noise limit in the notch and outside the LP cutoff.  The "loFreq" data appears to be running into some other noise floor.  As Jeff noticed, the loFreq and hiFreq curves suspiciously disagree about the depth of the notch.

Side notes

  • I checked the round-off method used within the front end code (controller.c).  It's set up to round the DAC outputs to the nearest integer, which is better than the normal C behavior of just lopping off the fractional part.
  • The 4x interpolation doesn't actually do anything to benefit the quantization noise here.  This surprised me at first: I thought the noise was supposed to improve as the square root of the interpolation factor.  But in fact, this depends on the signal.  Interpolation only helps you when you have a signal that often moves the DAC output by one or more steps.  It doesn't have any perceptible effect on a signal that's constant, or mostly constant.  And Jeff's excitation is so tiny and so heavily low-passed that the DAC output is held constant much of the time.  If you rescale the excitation so it uses the full DAC range, then the quantization noise goes down, and you do see the expected improvement from interpolation.

Suggested next steps

  • If the excess noise in the loFreq measurements is something real, can we pin down the source?  Is it already present at the AI chassis input?
  • How about a direct measurement of the quantization noise, by adding testpoints in the IOP before and after the round-off?
  • We could use some noise shaping sorcery to push the quantization noise floor below the electronics noise of the DAC.
Non-image files attached to this comment
daniel.sigg@LIGO.ORG - 07:58, Monday 29 July 2013 (7262)
The dominant noise source of a low noise DAC, when driven near its full range is the integrated non-linearity (INL). The exact shape of this noise might depend on the exact drive, ie., it could very well be different for a broadband signal vs single frequency, it might look different for high vs low frequency drive signals.
Displaying reports 70061-70080 of 77072.Go to page Start 3500 3501 3502 3503 3504 3505 3506 3507 3508 End