WP 12690 Gerardo M., Patrick T. "Update the PLC code on h0vacmr to reflect the current cabling of IP13 to Beckhoff terminal 25, channels 3 and 4." This work permit has been completed. The code is now at commit efc3db6abdaf3f286903a874e7f765e9d867f9f9. There are no issues to report.
This is part of the work we are doing for the Estimator. As part of that work, we are finetuning the OSEMINF gains, which we did previously for SR3 (84298), but since we've swapped the satamps we want to check how different these new values will be compared to the current gains as well as the gains we found that last time.
I ran excitations through the H1:ISI-HAM5_ISO_{X,Y,Z} filter banks with the settings of:
Measurements can be found at /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/Common/Data/2025-07-22_1530_H1ISIHAM5_ST1_WhiteNoise_ISO_{X,Y,Z}_0p05to40Hz_calibration.xml, svn revision r12476.
As per WP 12691 we moved the CDS/GC connection off of a temporary switch. This is a follow up to WP 12580 which had left us on a temporary switch. The new switch is a larger switch and all the phones can be plugged in now.
TITLE: 07/22 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 5mph Gusts, 2mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.05 μm/s
QUICK SUMMARY: Locked for 9 hours, magnetic injections currently running. Long list of planned maintenance today, see the Trello for more details.
Workstations were updated and rebooted. This was an OS packages update. Conda packages were not updated.
TITLE: 07/22 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:
Every thing was locked and humming along until the sudden lockloss from the 6.5M Earthquake off coast of Russia.
Held in Down for ~2.5 hours while the Earth rang down.
Ran an Initial Alignment and H1 is currently at CARM_OffSET reduction.
Wind is vey low, ground motion has dropped should be a good night of locked IFO.
LOG:
No Log
@ 02:08:55 UTC Known Lockloss caused by a 6.5M Earthquake. I'm using the GEOFON site because USGS took ~ 10 min to report the quake.
Earthquake mode was activated, then less than 30 seconds later we were unlocked.
No earthquake was listed as incoming, Picket fence was lit up and had active ground motion.
After last week's satamp changes (85770), the compensation filters found in the OSEMINF filter bank for MC2, PR2, TMSX, and ETMX M0/R0/L1 were all updated to a generic compensation filter of 5.31:0.0969. I have now updated those filters based on the experimental measurements Jeff got for each satamp's channel (the same as what I did in 85746).
To update the compensation filters, I used the newest version of my script satampswap_bestpossible_filterupdate_ECR_E2400330.py, svn revision r12475. This newest version of the code allows you to specify which stage you want to update, if you aren't wanting to update every stage listed in the txt files. Here is a txt file of my inputs and the corresponding outputs for the lines of code that I ran.
I have loaded these more accurate filters in for these suspension/stages.
TITLE: 07/21 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 15mph Gusts, 12mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.06 μm/s
QUICK SUMMARY:
H1 is currently Locking at Move.
Secondary microseism looks to be falling.
All systems look great.
Brushfire look out was done by Oli today, who said... "No fires today."
Roof pictures attached.
TITLE: 07/21 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY:
Started with a locked H1, and then started Monday Commissioning for 4-hours (15-19utc/8-noonPDT). Had a lockloss at the beginning of commissioning and it took 2hrs to get back to NLN (mostly let ISC_LOCK acquire on its own...it just took a bit.).
Lockloss in the afternoon looked a bit odd with the alignment not looking great. Tried to not run an Initial Alignment (i.e. run CMFringes + PRMI), but alignment looked bad. After 45min of acquiring, went for an Initial Alignment (which wasn't trivial due to a finicky IMC--see below), and after the IA, H1's alignment looked much better. It's all a question of when to run/not run an alignment due to the BS cooling down after locklosses.
EQs continued to rumble for most of the morning (many from Japan).
LOG:
Elenna noticed that pimon that we run on nuc25 hadn't been consistently saving data. There were large periods of time that didn't have anything recorded. I first verified that it would still write log and npz files, then I redirected them to /ligo/data/pimon/locklosses/ where it will now put all of the npz files. Elenna also asked that the script saves the time series and not the PSDs, so I made that change as well. I'm not sure the file size difference, the PSDs were about 3.6Mb, so we should keep an eye on that and get rid of old ones.
Operators, please verify that pimon is running on nuc25, and restart it if necessary. The normal launch script will start it up.
Apparently, it struggles to save the time series data and will freeze up. I've changed it back to only save the PSDs on lockloss and we'll see if it survives better.
The calibration lines still appear in DHARD P and Y to varying degrees. Here is a higher resolution spectrum of DHARD P and Y, with OMC DCPD sum for reference. DHARD P shows all four calibration lines (L1 15.6 Hz, L2 16.4 Hz, L3 17.6 Hz and PCAL 17.1 Hz) between 15-18 Hz, while DHARD Y only seems to show the 16.4 Hz line in L2.
Today, Sheila and I also looked at the phasing of AS A/B 45 WFS. Our thinking was that a DARM line could be phased to be mainly in Q for each segment. The segments all show the calibration lines prominently, so they can be used as a phasing reference. It was immediately apparently that for all segments of both WFS, the DARM line is at least a factor of 2 higher in I than in Q. We decided not to make any phasing changes at this time, since rephasing these lines into Q would change the sign dramatically and may impact locking when we put DARM on RF.
Instead of redesigned the MICH ASC loops, I just updated the lowpasses to be at 12 Hz instead of 15 Hz, which should reduce the gain by 15 dB between 10-20 Hz for both pitch and yaw. I tested them today with no issues, so I adjusted the MICH ASC engagement in ISC_DRMI guardian, and updated SDF (accidentally overwrote the screenshot with my screenshot of the filter).
Based on the results from Sheila's noise budget, I adjusted this filter to 9 Hz, which has further reduced the MICH ASC coherence with DARM. New filters are in FM8, lownoise ASC engages these filters. SDFed and guardian code tested.
References are coherence from the last lock, live traces are after filter is engaged.
Elenna and I checked the FC detuning by taking it slowly from nominal -26 to -50, where we could clearly see low freq DARM was worse, and then stepping to -15 (any lower unlocked the FC in 85886) using ezcastep H1:IOP-LSC0_RLF_FREQ_OFS -s 30 '+1,35', see attached plot. The best de-tuning is close to where we already are, leaving it at -27.
Mon Jul 21 10:08:47 2025 INFO: Fill completed in 8min 44secs
Jennie, Rahul
On Tuesday Rahul and I took the measurements for the horizontal coupling in the ISS array currently on the optical table.
The QPD read 9500 e-7 W.
The X position was 5.26 V, the Y position was -4.98 V.
| PD | DC Voltage [mV] pk-pk | AC Voltage [mV] pk-pk |
| 1 | 600 | 420 |
| 2 | 600 | 380 |
| 3 | 600 | 380 |
| 4 | 600 | 420 |
| 5 | 800 | 540 |
| 6 | 800 | 500 |
| 7 | 600 | 540 |
| 8 | 800 | 540 |
After thinking about this data I realise we need to retake it as we should record the mean value for the DC coupled measurements. This was with a 78V signal applied from the PZT driver and an input dither signal of 2 Vpp at 100Hz on the oscilloscope and I think 150 mA pump current on the laser.
Rahul, Jennie W
Yesterday we went back into the lab and retook the DC and AC measurements while horizontal dither was on while measuring using the 'mean' setting and without changing the overall input pointing from what it was in the above measurement.
| PD | DC Voltage [V] mean | AC Voltage [V] mean |
| 1 | -4.08 | -0.172 |
| 2 | -3.81 | 0.0289 |
| 3 | -3.46 | 0.159 |
| 4 | -3.71 | 0.17 |
| 5 | -3.57 | -0.0161 |
| 6 | -3.5 | 0.00453 |
| 7 | -2.91 | 0.187 |
| 8 | -3.36 | 0.0912 |
| QPD direction | Mean Voltage [V] | Pk-Pk Voltage [V] |
| X | 5.28 | 2.20 |
| Y | -4.98 | 0.8 |
QPD sum is roughly 5V.
Next time we need to plug in the second axis of the PZT driver so as to take the dither coupling measurement in the vertical direction.
horizontal dither calibration = 10.57 V/mm
dither Vpk-pk on QPD x-direction = 2.2V
dither Vpk-pk on QPD y-direction = 0.8V
dither motion in horizontal direction in V on QPD = sqrt(2.2^2 + 0.8^2)
motion in mm on QPD that corresponds to dither of input mirror = sqrt(2.2^2 + 0.8^2) / 4.644 = 0.222 mm
Code is here for calibration of horizontal beam motion to QPD motion plus calibration of dither measurements.
To work out the relative intensity noise:
RIN = change in power/ power
= ( change in current/ current) / responsivity of PD
= (change in voltage/voltage) / (responsitvity * load resistance)
Therefore to minimise RIN we want to minimise change in voltage / voltage for each PD.
To get the least coupling to array input alignment we work out
relative RIN coupling = (delta V/ V) / beam motion at QPD
This works because the QPD is designed to be in the same plane as the PD array.
| PD | DC Voltage [V] mean | AC Voltage [mV] pk-pk | Beam Motion at QPD [mm] | Relative Coupling [1/m] |
| 1 | -4.08 | 420 | 0.222 | 465 |
| 2 | -3.81 | 380 | 0.222 | 450 |
| 3 | -3.46 | 380 | 0.222 | 496 |
| 4 | -3.71 | 420 | 0.222 | 511 |
| 5 | -3.57 | 540 | 0.222 | 683 |
| 6 | -3.5 | 500 | 0.222 | 645 |
| 7 | -2.91 | 540 | 0.222 | 838 |
| 8 | -3.36 | 540 | 0.222 | 726 |
These are all a factor of 50 higher than those measured by Mayank and Shiva but after discussion with Keita either we need higher resolution measurements or we need to further optimise input alignment to the array to minimise the coupling.
I previously noted a glitch about 30 seconds before lockloss in LOWNOISE ASC, 85685. However, we had two more locklosses from this state last night and I do not see such a glitch so that is a random coincidence. One of those locklosses appears to be caused by an earthquake. However, since 6/11, we have had 9 locklosses in this state that occurred exactly 47 seconds into the state, which seems suspicious, one of those occurred last night, and the lockloss with the glitch was the same.
This seems to be coincident with the engagement of a few DHARD P filters:
2025-07-14_14:26:54.641531Z ISC_LOCK executing state: LOWNOISE_ASC (522)
2025-07-14_14:26:54.642230Z ISC_LOCK [LOWNOISE_ASC.enter]
2025-07-14_14:26:54.655894Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_PIT3_OSC_CLKGAIN => 300
2025-07-14_14:26:54.656325Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_PIT4_OSC_CLKGAIN => 300
2025-07-14_14:26:54.656732Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_PIT5_OSC_CLKGAIN => 300
2025-07-14_14:26:54.657043Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_YAW3_OSC_CLKGAIN => 300
2025-07-14_14:26:54.657438Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_YAW4_OSC_CLKGAIN => 300
2025-07-14_14:26:54.657892Z ISC_LOCK [LOWNOISE_ASC.main] ezca: H1:ASC-ADS_YAW5_OSC_CLKGAIN => 300
2025-07-14_14:26:54.658134Z ISC_LOCK [LOWNOISE_ASC.main] timer['LoopShapeRamp'] = 5
2025-07-14_14:26:54.658367Z ISC_LOCK [LOWNOISE_ASC.main] timer['pwr'] = 0.125
2025-07-14_14:26:54.783581Z ISC_LOCK [LOWNOISE_ASC.run] timer['pwr'] done
2025-07-14_14:26:59.658298Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:26:59.719537Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_Y_GAIN => 200
2025-07-14_14:26:59.720456Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_Y_SW1 => 256
2025-07-14_14:26:59.846249Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_Y_SW2 => 20
2025-07-14_14:26:59.971686Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_Y => ON: FM3, FM8, FM9
2025-07-14_14:26:59.972384Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_Y_SW1 => 5392
2025-07-14_14:27:00.098073Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_Y_SW2 => 4
2025-07-14_14:27:00.223528Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_Y => ON: FM1, FM3, FM4, FM5, FM8
2025-07-14_14:27:00.224135Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CSOFT_P_SMOOTH_ENABLE => 0
2025-07-14_14:27:00.224497Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CSOFT_Y_SMOOTH_ENABLE => 0
2025-07-14_14:27:00.224868Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_P_SMOOTH_ENABLE => 0
2025-07-14_14:27:00.225188Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_Y_SMOOTH_ENABLE => 0
2025-07-14_14:27:00.225433Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 10
2025-07-14_14:27:10.225728Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:10.281803Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_TRAMP => 5
2025-07-14_14:27:10.408120Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_SW2 => 16
2025-07-14_14:27:10.533563Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P => OFF: FM9
2025-07-14_14:27:10.534285Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_SW1 => 256
2025-07-14_14:27:10.660088Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_SW2 => 4
2025-07-14_14:27:10.785453Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P => ON: FM3, FM8
2025-07-14_14:27:10.786315Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-CHARD_P_GAIN => 208
2025-07-14_14:27:10.786535Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 5
2025-07-14_14:27:15.786858Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:15.847152Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_Y_TRAMP => 5
2025-07-14_14:27:15.847580Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_Y_GAIN => 5
2025-07-14_14:27:15.848666Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DSOFT_P_GAIN => 5
2025-07-14_14:27:15.848917Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 5
2025-07-14_14:27:20.849050Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:20.906577Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ITMX_M0_DAMP_Y_TRAMP => 10
2025-07-14_14:27:20.907206Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ETMX_M0_DAMP_Y_TRAMP => 10
2025-07-14_14:27:20.907700Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ITMY_M0_DAMP_Y_TRAMP => 10
2025-07-14_14:27:20.908422Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ITMX_M0_DAMP_Y_GAIN => -0.5
2025-07-14_14:27:20.908830Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ETMX_M0_DAMP_Y_GAIN => -0.5
2025-07-14_14:27:20.909148Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ITMY_M0_DAMP_Y_GAIN => -0.5
2025-07-14_14:27:20.909562Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-ETMY_M0_DAMP_Y_GAIN => -0.5
2025-07-14_14:27:20.909789Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 10
2025-07-14_14:27:30.910055Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:30.968166Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_P_GAIN => -0.2
2025-07-14_14:27:30.968527Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_Y_GAIN => -0.2
2025-07-14_14:27:30.968806Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_L_GAIN => -0.2
2025-07-14_14:27:30.969073Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_R_GAIN => -0.2
2025-07-14_14:27:30.969343Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_T_GAIN => -0.2
2025-07-14_14:27:30.969606Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:SUS-SR2_M1_DAMP_V_GAIN => -0.2
2025-07-14_14:27:30.969838Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 10
2025-07-14_14:27:40.970003Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] done
2025-07-14_14:27:40.972085Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_P_SW1 => 1024
2025-07-14_14:27:41.097962Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_P_SW2 => 4
2025-07-14_14:27:41.223313Z ISC_LOCK [LOWNOISE_ASC.run] ezca: H1:ASC-DHARD_P => ON: FM4, FM8
2025-07-14_14:27:41.223637Z ISC_LOCK [LOWNOISE_ASC.run] timer['LoopShapeRamp'] = 10
2025-07-14_14:27:41.593743Z ISC_LOCK [LOWNOISE_ASC.run] Unstalling IMC_LOCK
2025-07-14_14:27:41.765955Z ISC_LOCK JUMP target: LOCKLOSS
I will take a look and see if there is anything unstable about these filters. Whatever is occurring seems to be too fast to be seen in the ASC signals themselves, and at first glance I don't see anything strange in the suspension channels either.
DHARD FM4 is engaged with a 10 second ramp- this is a change I made on 6/11: 84973 because we had lost lock on that day twice in the same spot. Two of the locklosses at 47 seconds occurred before that change. Then, later that day on 6/11 I reengaged a boost in DHARD P, which only has a 5 second ramp, 84980. Engaging that boost shouldn't be unstable, but maybe something bas occurrs when they ramp at different times. I'm lengthing the ramp to 10 seconds.
We had another lockloss from this state at the 00:47 mark last night, 1436615757 so I'm not sure this fixed the problem.
However, the lockloss was proceeded by a glitch about 30 seconds before, like another lockloss I noticed in this state. This could be coincidence again, but it's looking a little suspicious!
The glitch appears to be occuring due to the CHARD P change. We ramp a boost off with 2 seconds, and a new shaping and low pass on with 2 seconds, and then change the gain with 5 seconds. Looking at the step response of the shaping and lowpass filter, this ramp should probably be 10 seconds, and the gain also 10 seconds to match. I will keep the boost at 2 seconds to ramp off though. I increased the wait timer to 10 seconds to match this ramping. Model and guardian changes saved and loaded.
I am still not sure what is going on with DHARD P, but as a test I've now separated the low pass and loop shape from the engagement of the boost, since we know those individually are stable to engage. We now engage FM4 with a 10 second ramp and wait time, then engage FM8 with a 5 second ramp and wait time. I edited the ramps and gaurdian code to do so, svaed and loaded. This is kind of annoying, but it might help me debug what's going wrong here.
I watched the signals during lownoise ASC, and this time I saw no glitch in CHARD during its lownoise transition. However, I saw a glitch when the DHARD P FM4 filter was engaged, and no glitch when FM8 was engaged. Maybe the ramp of FM4 should be even longer than 10 seconds. I increased the filter ramp to 15 seconds and increased the guardian wait timer to match. Both changes saved and loaded.
We haven't had a lockloss in this state since this fix (but we've had plenty of locks), so I am going to declare this problem fixed!
Jennie W, Rahul
Yesterday we made some measurements to calibrate the spot size on the QPD as we scan the beam position across it.
We used a connector Fil made us to plug in the OT301 QPD amplifier into a DC power supply after checking it contained voltage regulators that could cope with a voltage between 12 and 19 V ( as the unit says it expects DC supply but the previous one we were using was AC with a 100mA current rating and was getting too hot so we assume that was the incorrect one). We hooked it up at 16V (this draws about 150mA of current). The QPD readout looks normal and does not have any of the strange sawtooth we saw with the original power cable.
We moved the M2MS beam measurement system out of the way of the translation stage.
To calibrate the QPD we need to change the lateral position of the M1 mirror and lens to change the yaw positioning on the QPD and measure the X and Y voltages from the QPD.
We need to check we are centred first. The QPD bullseye readout shows the beam is off a tiny bit in yaw but this was as good as we could get at centering the beam when we moved the QPD. All 8 PDs are reading about 4.6 V so this means the beam is well centred in the array plane.
We measure 11000 counts on the bullseye qpd readout at this M1 position.
|
Translation Stage inch |
QPD X (mV ) |
QPD Y (V) |
|---|---|---|
| 4.13 | 239e-3 | -1.77 |
| 4.14 | 252e-3 | -1.84 |
| 4.15 | 2.34 | -1.60 |
| 4.16 | 4.46 | -1.17 |
| 4.17 | 4.26 | -1.11 |
| 4.18 | 5.62 | -835e-3 |
| 4.19 | 7.80 | -600e-3 |
| 4.20 | 7.81 | -321e-3 |
| 4.21 | 8.45 | -222e-3 |
| 4.22 | 8.82 | +70.6e-3 |
|
4.23 |
9.19 |
771e-3 |
| 4.24 | 9.28 | 1.12 |
| 4.25 | 9.37 | 1.88 |
| 4.26 | 9.36 | 2.36 |
| 4.27 | 9.37 | 2.38 |
| 4.28 | 9.44 | 2.71 |
| 4.29 | 9.47 | 3.10 |
| 4.30 | 9.50 | 3.41 |
| 4.31 | 9.49 | 3.35 |
| 4.32 | 9.51 | 3.72 |
| 4.33 | 9.55 | 4.27 |
| 4.34 | 9.58 | 4.55 |
| 4.35 | 9.62 | 4.86 |
| 4.36 | 9.66 | 5.44 |
| 4.37 | 9.65 | 5.31 |
| 4.38 | 9.63 | 5.60 |
| 4.39 | 9.69 | 5.75 |
| 4.40 | 9.69 | 6.00 |
| 4.41 | 9.70 | 6.15 |
| 4.42 | 9.70 | 6.16 |
| 4.43 | 9.71 | 6.33 |
| 4.44 | 9.71 | 6.50 |
| 4.45 | 9.72 | 6.72 |
| 4.46 | 9.74 | 7.09 |
| 4.47 | 9.73 | 6.87 |
| 4.48 | 9.74 | 7.40 |
| 4.49 | 9.75 | 7.46 |
| 4.50 | 9.74 | 7.46 |
| 4.51 | 9.76 | 7.75 |
| 4.52 | 9.74 | 7.67 |
| 4.53 | 9.73 | 7.82 |
| 4.54 | 9.74 | 7.96 |
| 4.55 | 9.73 | 8.08 |
| 4.56 | 9.72 | 8.33 |
| 4.57 | 9.71 | 8.43 |
| 4.58 | 9.70 | 8.50 |
| 4.13 | 448e-3 | -1.98 |
| 4.12 | -1.02 | -2.34 |
| 4,11 | -1.17 | -2.14 |
| 4.10 | -2.92 | -2.43 |
| 4.09 | -4.63 | -3.30 |
| 4.08 | -5.91 | -3.18 |
| 4.07 | -6.97 | -3.40 |
| 4.06 | -8.17 | -4.24 |
| 4.05 | -8.13 | -4.28 |
| 4.04 | -8.52 | -4.47 |
| 4.03 | -8.76 | -4.77 |
| 4.02 | -8.89 | -5.27 |
| 4.01 | -9.01 | -5.45 |
| 4.0 | -9.08 | -5.44 |
| 3.99 | -9.10 | -5.85 |
| 3.98 | -9.11 | -5.91 |
| 3.97 | -9.11 | -5.93 |
| 3.96 | -9.12 | -6.16 |
| 3.95 | -9.12 | -6.18 |
| 3.94 | -9.13 | -6.34 |
| 3.93 | -9.13 | -6.49 |
| 3.92 | -9.12 | -6.49 |
| 3.91 | -9.13 | -6.61 |
| 3.90 | -9.11 | -6.55 |
| 3.89 | -9.11 | -6.70 |
| 3.88 | -9.10 | -6.46 |
| 4.13 | ||
I plotted the data from lowest reading on the translation stage to highest and fitted the linear region using Calibrate_QPD.m which is attached.
Data is shown in attached pdf.
The slop of the linear region in V/inch is 112 V/inch. Which means to if the beam moved 8.93 e-3 inches on the QPD in yaw, the yaw readout would change by 1 Volt.
I altered the code to plot in mm and the constant is 4.4 V/mm.
D'oh I read the scale on the translation stage wrong so the x readings are actually lower by a factor of 10.
This makes the slope 44.1 V/mm which is more in line with the 65.11 V/mm Mayank and Shiva found for the QPD calibration here.
Ours could be different because we have a slightly different beam size and we moved the QPD in its housing to centre it which could have changed X to Y coupling in the QPD readout.
This implies our beam diameter on the QPD is around 0.4mm which makes a lot more sense considering the diode is 3mm!
As a cross-check we used the QPD 'bullseye' readout unit and Rahul changed the translation stage in yaw and we measured the beam dropping from 10400 counts in the middle of the QPP to 100s of counts at the edges.
| Translation Stage [inch] | QPD Sum Counts |
|---|---|
| 0.413 | 10400 |
| 0.365 | 500 |
| 0.413 | 10400 |
| 0.49 | 400 |
diode size ~ ((0.49-0.365)*0.0254*1000) = 3.175 mm.
I redid the graphs for the horizontal motion of the input beam to X motion on the QPD with better labels (first attached graph) and did a fit for the Y data on the QPD collected at each horizontal position of the input beam (second attached graph). The third graph attached is comparing both fits on one graph.
If we take into account the input beam horizontal axis is not aligned with the QPD, we can work out the resultant calibration relative to the mirror displacement as:
V change along mirror displacement axis = sqrt((change V in X)^2 + (change V in Y)^2)
Calibration = V change along mirror displacemnt axis/change in mirror position
= 4.644 V/mm.
angle of QPD horizontal axis with mirror displacement axis = tan^-1(Voltage change V in Y/ Voltage change in X) = 38.8 degrees.
I got the above caluclation of the QPD calibration in the horizontal direction wrong as I use the total change in voltage we measured across the whole range of horizontal scan and not just the linear region where the beam is close to centred on the QPD.
The horizontal beam scan calibration is actually:
sqrt(11.8^2 + 44.1^2) = 10.6 V/mm
with an angle of tan^-1(11.8/44.1) = 14.9 degrees to the X direction on the QPD.
Ibrahim, Rahul
The first round of B&K test results for BBSS & HRTS were posted in LHO alog 84654 . Now were are presenting the second round of test results after making the following improvements on BBSS - (a) added four side dampers (D1101299), two on each side, (b) two lower structure Y-brace strut - D1900589. Please see figure (IMG_2926) for reference. We have also removed the four optical posts which were earlier attached to the HRTS. Finally we attached four Vibration Absorbers (D1002424) to BBSS.
The B&K test results are attached below as a pdf document. We have taken 9 measurements with different boundary conditions, each of which is explained below. For each case the tri-axis accelerometer was mounted on the BBSS frame (marked as position P1 or P2 here) - X axis is along the longitudinal side of the BBSS, Y axis is the vertical and Z is transverse. For HRTS, it's shown in page 9 of the pdf document.
Test 1a (see page 2): case - BBSS (without HRTS) and no side dampers or Y-brace attached to BBSS, Accelerometer position P1.
Test 1b (see page 3): case - BBSS & HRTS and no side dampers or Y-brace attached to BBSS, Accelerometer position P1.
Next ,side dampers and Y-brace attached.
Test 2a (see page 5): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer position P1. Hammer hits on the center of the structure.
Test 2b (see page 6): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer position P2. Hammer hits on the center of the structure.
Test 3 (see page 7): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer position P1. Hammer hits on the side of the structure (left or right).
Test 4 (see page 8): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer position P2. Hammer hits on the side of the structure (left or right).
Test 5 (see page 9): case - BBSS & HRTS with side dampers and Y-brace attached to BBSS (No Vibration Absorbers), Accelerometer attached to HRTS. Hammer hits on HRTS.
Next ,side dampers Y-brace and Vibration Absorbers attached.
Test 6a (see page 11): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the center of the structure (X axis or longitudinal direction).
Test 6b (see page 12): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the center of the structure (Y axis or vertical direction).
Test 6c (see page 13): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the center of the structure (Z axis or transverse direction).
Test 7a (see page 14): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the side of the structure (X axis or longitudinal direction).
Test 7b (see page 15): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the side of the structure (Y axis or vertical direction).
Test 7c (see page 16): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P1. Hammer hits on the side of the structure (Z axis or transverse direction).
Test 8a (see page 17): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the center of the structure (X axis or longitudinal direction).
Test 8b (see page 18): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the center of the structure (Y axis or vertical direction).
Test 8c (see page 19): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the center of the structure (Z axis or transverse direction).
Test 9a (see page 20): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the side of the structure (X axis or longitudinal direction).
Test 9b (see page 21): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the side of the structure (Y axis or vertical direction).
Test 9c (see page 22): case - BBSS & HRTS with side dampers, Y-brace attached to BBSS and Vibration Absorbers, Accelerometer position P2. Hammer hits on the side of the structure (Z axis or transverse direction).
The raw data (.csv files) generated by the B&K software are stored at the following location,
/ligo/home/rahul.kumar/Desktop/scripts/bnk_csv_files
Attached below is a pdf document in which I have repeated tests 6abc and 7abc accelerometer / hit location data, but with the HRTS removed (called as test 8abc and 9abc). In both the cases the Vibration Absorbers (VA) are attached to the BBSS. There are no VA on the HRTS.
