A while ago I wrote a script to calculate match gains for the BSC FF to match the ISI L4C's to the HEPI L4C's. This was based on Arnaud's script script to compute the match gains for the sensor correction, in alog 16208. The process was much the same, putting the St1 in 750mhz cps blends, turning off feedforward and sensor correction to the ISI and HEPI. I left the ISI's like that for 10 minutes, then calculated the transfer function between the HEPI and ISI L4C's, and took the average between .1 and .4 hz. The transfer functions all look somewhat like the attached one for the BS. Most match gains were are 1 +/-10%, but ETMY and the BS both had one value that was off by about 20%, X for ETMY, Y for the BS. Gains are installed, I'll get some performance data overnight. The script is in the SEISVN under /BSC-ISI/Common/Misc, it's called BSC_FF_gain_matching. You can see what the results look like by running (with the SEI paths loaded) BSC_FF_gain_matching('H1', 'ITMX', 1113079985, 600) and exchanging 'ITMX' for the other chambers.
Since everyone is done at EX and the winds are a blowing, we turned the BRS on and switch to the Mitt_SC.
J. Kissel, K. Izumi Using the same model I described yesterday (see LHO aLOG 17847), I've now compared it against (a) this weekend's measured DARM Open Loop Gain Transfer Functions (OLGTFs), which were taken out to 1 [kHz]: 2015-04-12 Post UIM / TST Crossover Adjustment, Post HAM6 Vent, ESD Linearization OFF, at 10 [W] input power LHO aLOG 17834 2015-04-13 Increase of input power to 15 [W], ESD Linearization OFF LHO aLOG 17835 and (b) The previous measurements shown in LHO aLOG 17847. They've solidified suspicions of we'd just barely begun to see -- there's definitely some funny business going on: - We suspect that the frequency dependence of the sensing function (i.e. optical plant) cannot be simply described by a single-pole filter, but it could also be a flaw in model of the actuation frequency dependence. - The optical gain has significantly reduced from 112e6+/-8% to 75e6+/-4%, even though Evan and Sheila have attempted to compensate for it in the DARM loop digital gain. In the first attachment, I compare all of the measurements against a model with a fixed cavity pole frequency of 389 [Hz], the number calculated to be the ideal from L1 (see LLO aLOG 15923). In the second attachment, I compare all of the measurements against a model where I've adjusted the coupled cavity pole frequency to match the model / measurement discrepancy. From the comparison of these two models, one can see several things: (1) There is a systematic difference in frequency-dependent discrepancy between the earlier, 5-300 [Hz] data and the later, post-HAM6 vent, data. This implies something systematic has changed in the time between 2015-04-06 and 2015-04-12. (2) In order to fit the discrepancy's frequency dependence, I've had to move the DARM coupled cavity pole down to an unrealistically (??) low 320 [Hz] and 290 [Hz] for the earlier and later data, respectively. The ?? is because I'm not sure what is unrealistic. (3) I've used the same time delay for *all* of the data sets. The 40 [us] was chosen *after* I'd shifted the coupled-cavity pole frequency down in order to get the phase to be flat as a function of frequency. We have no reason to suspect that the time delay would have changed over these 5 measurements, so I take this to be the residual unknown timing error (*not* the 93 +/- 30 [us] I'd said in the previous log). There are several things think might be the cause of this (arranged in order of what we think is most likely) - DARM coupled cavity pole is lower than expected because of SRCL offset, low power recycling gain, or IFO alignment - ESD / SUS isn't exactly 1/f^2 at high frequency - Some nasty frequency dependence of the linearization algorithm Kiwamu's hard at work testing the first suspicion. Stay tuned!
Jeff K, Kiwamu,
As Jeff described in the above entry, we noticed that the latest measured DARM open loops behaved as if they got a lower cavity pole (~ 290 Hz). There are several possible reasons for explaining this. This time, we started from study of a SRCL offset which can lower the DARM cavity pole. After the study, we are concluding that the discrepancy is NOT due to a SRCL offset.
(Comparison between model and measurements)
The attached plot below shows a ratio of the zero-SRCL-offset DARM TF and DARM TFs with various SRCL offsets together with the actual data that Jeff posted. The solid curves are made from simulated responses and dots are the measured ones. The numbers in the legend box represent the size of the offsets in the SRCL locking point.
As shown in the plot, the behavior of a rising wing at high frequencies are seen in both the measured data and simulation. However, apparently the measured data do not show a dip at around 200 Hz. As we know, this dip is a particular behavior of a SRCL offset which results in a detuning peak at around the cavity pole.
If we keep increasing the SRCL offset, the location of the cavity pole would become as low as measured one, but at the same time it would also make the dip much deeper. So we think the SRCL offset is NOT the one causing the low cavity pole in DARM.
I'm taking advantage of the PSL down to get some measurments on the BSCs. The measurements require high blends, no sensor correction or feedforward on the ISI. Should take 10 minutes. I will return the platforms to operating states when I have enough data.
This seismometer has given us problems for some time: alogs 15510, 14482, 9727. JeffK may point to others too.
On the attached four plots, there are four successive days, Saturday thru Tuesday at 0100pdt. The lower left panels are the Coherences between the HAM2 & HAM5 (STS-A & C) and the ITMY (STS2.) The Upper Left, Upper Right, and Lower Right panels are the ASDs of the X Y & Z DOFs respectively of STS2 A B & C.
The take away is that in general the character of the ITMY (STS2-B) ground seismometer doesn't change like the other two instruments below 100mhz while the HAM2 & HAM5 instruments change more day to day and mostly look like each other.
Details: The Z DOF is most obvious in that below 50 or 80 mhz, ITMY trends up steeply while the A & C seismos do not. For the Y DOF, the HAM2 (STS2-B) signal seems to be the outlier but the day to day doesn't follow a patten between the instruments so I ... The X DOF is pretty good with the A & C instruments tracking each other pretty closely while the B sensor kinda stays at the same power level, mostly. So, like I say, a Case, maybe.
If I remember right, it sits on some kind of thin plastic or rubber mat, while the others sit directly on the concrete. If possible, it might be useful to make it contact the the concrete floor directly by carving out three holes on the mat.
For convenience: Evidence for low-frequency broken-ness LHO aLOG 15510 LHO aLOG 14482 LHO aLOG 9727 Factor-of-2 drop in X channel gain LHO aLOG 16208 LHO aLOG 16305
J. Kissel, R. Schofield Trying to convince Robert to let us borrow the newly-returned PEM vault STS-2 (S/N 88921) (see when it was removed in LHO aLOG 12931), I tried to show him in more detail with a little less curves on a plot what was wrong with the ITMY, B, Beer Garden STS-2 (S/N 88941). In the process, we not only rediscovered the problem Hugh shows above -- that the Z DOF on ITMY, below 50 [mHz] is just junk, but we also discovered that the Y DOF on the HAM2, A, Input Arm STS-2 (S/N 89922) is also junk. The attached PDFs show 5 days worth of corner station STS2 ASDs and COHs. For HAM2, check out the Y COH .pdf first. We see surprisingly low coherence between HAM2's Y and the other two, where the other two are perfectly coherent with each other. Looking at the ASD, it also shows the HAM2 spectra are consistently discrepant between 500 [mHz] and 3 [Hz], as well as below 0.1 [Hz]. For ITMY, again, check out the Z ASD first. From there, it's obvious that every day, the motion below 50 [mHz] is just junk. This is confirmed by the coherence, which shows that HAM2 is coherent with HAM5 every day, and ITMY is coherent with neither every day. The fact that ITMY and the HAM5, C, Output Arm STS-2 (S/N 100145) are always coherent between ... nope I can't make a consistent story. DOFs are inconsistently coherent, where they should all be perfectly coherent from 1 [Hz] down to 10 [mHz]. We really just need to huddle test all four of the STSs we have available in the corner, 89921 "PEM" Back from Quanterra 89922 Currently STS A 89941 Currently STS B 100145 Currently STS C and confirm -- once and for all -- which channel of whose is busted. Unfortunately, this means a whole lot of cable lugging around the LVEA -- a pretty hefty Tuesday task. Further -- LHO really needs more low-frequency seismometers -- because (a) We're already "temporarily" using a T240 at EX (S/N 531, borrowed fron the ETF at Stanford, originally installed at LHO in Feb 2014, see LHO aLOG 9758, and D1400077) because the project couldn't find enough STS-2s for us. (b) Even *if* we use all 5 in our possession (we have one at ETMY, S/N 89938), we still wouldn't be able to have one fail without significant down time. The lab's STS2/T240 Inventory, E1200068 hasn't been updated since the last time we churned up this subject in Oct 2014. I'm working on updating it myself by beating the streets; stay tuned for a -v15. Devil's advocate (inspired by Robert): Looking at the X DOF, there are days where all corner STSs are perfectly coherent between 60 [mHz] and ~2 [Hz]. Looking at the Y DOF, there are days where ITMY and HAM5 are perfectly coherent between 60 [mHz] and ~3 [Hz]. Looking at the Z DOF, there are days where all corner STSs are perfectly coherent between 60 [mHz] and ~1 [Hz]. The above implies that the corner station ground motion is perfectly coherent between 60 [mHz] and ~1 [Hz]. This implies we could try using a single STS-2 to run sensor correction for all chambers in the corner station. In order of risk of common-mode rejection being compromised: - For the BSCs, in X&Y, we only need a good signal around the first SUS resonances at ~500 [mHz] for DeRosa's narrow-band filter (See figure 3.32 P1500005). - For the HAMs in X&Y, we only need good coherence down to the bottom (frequency) edge of Hua's polyphase FIR bump, at 50 [mHz] (See pg 4 of attachment to SEI aLOG 594) - For all chambers, in Z, we need good coherence down to 10 [mHz], the lower end of the Mittleman's tilt free filter (See pg 5 of SEI aLOG 594) So, *if* we find an STS we like in which off of it's DOFs are performing perfectly (hopefully, presumably it's the one that just came back from Quanterra, S/N 89921), then we might be able to get away with running the entire VEA off of one STS2 (or T240). Maybe.
New tags were created for the IOCs for the Davis weather stations and Met One dust monitors in the projects svn repository: trunk/epics/iocs/weather/davis/weather_monitor_ii/tags/weather_davis_weather_monitor_ii-1.1.0 trunk/epics/iocs/dust/met_one/227b/tags/dust_met_one_227b_comp_ctrl-1.4.0 There are no branches and tags for the Lighthouse dust monitors. The code was updated in place in the projects svn repository: trunk/epics/iocs/dust/lighthouse I created new target directories in /opt/rtcds/lho/h1/target: h1weathercs, h1weatherex, h1weatherey, h1weathermx, h1weathermy, h1dustdr, h1dustlab, h1dustlvea, h1dustmx, h1dustmy h1dustex, h1dustey, h1dusth1pslanteroom, h1dusth1psllaserroom Updated medm screens now live in: /opt/rtcds/userapps/release/pem/h1/medm/weather/ /opt/rtcds/userapps/release/pem/h1/medm/dust/met_one/ /opt/rtcds/userapps/release/pem/h1/medm/dust/lighthouse/ The sitemap was updated to point to these. I still need to commit them to svn. The following IOCs were stopped and restarted with the new code: Davis weather stations: h1weathercs, h1weathermx, h1weathermy, h1weatherex, h1weatherey (on h0epics2) Met One dust monitors: h1dustdr, h1dustlab, h1dustlvea, h1dustey (on h0epics) Lighthouse dust monitors: h1dusth1pslanteroom, h1dusth1psllaserroom (on the h0dust Windows virtual machine) h0epics2 had to be updated to mount /opt/rtcds. I updated the alarm handler configuration file for the dust monitors. I took the opportunity to remove the FORCEPV and HEARTBEATPV channels in this configuration file which were not connecting. Dave copied over snapshot files from this morning, changed the names from H0 to H1 and ran burtrestores with them. Jim B. made the changes for the test dust monitor running at end X. I believe he created a h1dusttst directory in /opt/rtcds/lho/h1/target. I will work on updating the wiki instructions.
R. Savage, J. Oberling, E. Merilh
Work performed on 4/9/2015.
Summary
We are investigating the channels in the PSL MEDM screens to determine what they do and if they do it correctly, and making changes when needed. We started with the LO MON on the PSL FSS MEDM screen. It is a monitor of the LO signal used in the PDH locking of the FSS servo. We found the gain to be set incorrectly to -0.00666, so we changed it to 0.0044033. We also changed the readout so that it will read 100% when the LO signal is equal to its nominal value (13.86V), >100% when larger and <100% when smaller.
Details
We have begun an effort to go through the more vaguely labeled outputs on the PSL MEDM screens to figure out what exactly they do and if they are doing it right, and making changes when necessary. We are starting with the FSS, as that is the hot item in PSL land at the moment, with the LO MON readout located at the bottom left of the FSS MEDM screen. This signal is read in percentage, but no indication what it is a percentage of.
Looking at page 1 of the FSS schematic in D040105-B shows the LO Mon as the output LOM from an ADC 10-4 directional coupler. A portion of the LO signal (used as part of the PDH locking for the FSS servo) is diverted and output so we can monitor the LO signal. This LOM is read into EPICS and sent to a filter with the simple math of: output = (signal – offset) * gain.
The offset is set to -22710.0 counts and the gain is -0.00666. As this is a monitor signal and reported as a percentage, it follows that the LO MON is reporting the percent error of the LO signal as compared to some nominal value: % error = ((signal – nominal)/nominal) * 100. This nominal value is the offset in the filter, 22710.0 counts (or 13.86V). The gain is then equal to 100 divided by the nominal value, or 100/22710.0 = 0.0044033; the gain was found to be -0.00666, so it seems the LO MON readout on the FSS MEDM screen has been misreporting the % error of the LO signal. We therefore changed the filter gain to 0.0044033.
Also, as the MEDM screen does not properly indicate that the LO MON is a % error, we turned off the offset in the filter. The math is now: output = signal * gain = signal * 100/nominal. With this change the LO MON readout will now read 100% when the LOM signal is equal to the offset, >100% when larger and <100% when smaller.
Elli, Nutsinee, Patrick The medm overview was frozen with white numbers. Restarted the computer and it came back. Burtrestored PLC1, PLC2 and PLC3 to 3:10 this morning.
Nutsinee, Elli
To take a measurement with the end-station HWS, the green beam cannot be resonant in the arm cavity. To take a measurement while the IFO is locked in red, this means we want to add a misalignment offset to one of the ALS_X/Y_PZT1/2 drivers to misalign the green beam in the cavity. Today we are working out what offset is required to do this.
First we looked at the Y arm. We looked at what offset we need to add to H1:ALS-Y_PZT2_YAW_MISALIGN_BIAS in order to offset the beam enough that green is both not resonant in the arm but the beam yet not so badly aligned that we see evidence of clipping on the HWS camera. We put -3250 counts in H1:ALS-Y_PZT2_YAW_MISALIGN_BIAS , requested 'misalign' state for H1:ALS-Y_PZT2_MISALIGN_SWITCH and 'sum' state for H1:ALS-Y_PZT2_MISALIGN_TYPE. We turned off the input to the filter at H1:ALS-Y_PZT2_YAW_OUTEN. This gave us a good image of the ETM on the EX HWS. Changing the MISALIGN_BIAS by +/- 100 counts made the image on the HWS camera noticabally worse.
When we came in this morning the interferometer was unlocked and trying to lock. We set ISC_LOCK to down and ALS_YARM and ALS_XARM to unlocked. We have left the guardian in this state. I have left the ALS-Y_PZT2 driver in it's nominal 'aligned' state (and the BIAS values have not changed). When we statred the flashes in the y-arm were about 1.2 counts, indicating good alignment. After 30mins the flashes were down to 0.8 counts, indicating the alignment had gotten worse. This suggests the hysteresis in misaligning and realigning these PZTs may noticablly effect the green alignment.
We are planning to do the same thing on the x-arm, although we have not yet gotten to a good alignment with bright flashes in H1:ALS-X_TR_A_LF_OUT this morning. But we have noticed the end-X HWS camera isn't taking images properly, so we are going to diagnose that now. We will leave the X-arm alignment as we found it this morning.
Elli, Nutsinee
After Patrick restarted the frozen Beckhoff computer at EX (alog 17861), we were able to power on EX HWS camera and align the ALS beam to the X arm. We had flashes of 0.9 counts in ALS-TRX. Looking at the HWS camera output, we could see that adding an offset of -3300 counts to H1:ALS-X_PZT2_YAW_MISALIGN_BIAS changes H1:ALS-X_PZT2_YAW_MONITOR to 8700 counts. (H1:ALS-X_PZT2_YAW_OUTEN is set to 'OFF', 'Misalign' is requested in H1:ALS-X_PZT2_MISALIGN_SWITCH and the type is set to 'sum' in H1:ALS-X_PZT2_MISALIGN_TYPE.)
There is with this alignment offset we can see some flashes from ITMx at the edge of the HWS image, as well as a little fringing from clipping on the HWS path. If we increase the offset, the clipping gets worde and if we reduce the offset the flashes from ITMx move towards the center of the image. An offset of -3300 seemed to us a good compromise between these undesirable effects. See attached HWS camera images at different offsets.
When we were finished the flashes in ALS-TRX were at 0.85 counts (they dropped about 0.05 counts in 20 minutes), so maybe moving the ALS PZTs doesn't add much of a hysteretic misalignment after all... but we will keep an eye on this. The ALS X PZTz are now running in their nominal aligned state.
Jeff/Andres will be going to EX, so we turned the BRS Switch OFF (with help from TJ & Jim W). We will turn them back ON when incursions are complete probably after Maintenance since we have winds hovering around 20mph already.
Reminder to Operators:
If the BRS Sensor Correction is being used and someone needs to go to EX, the operator needs to turn OFF BRS Sensor Correction and change the appropriate filters.
I have a script that will do this in /opt/rtcds/userapps/release/isi/h1/scripts/
To use it, navigate to this directory and then type "python BRSswitch.py OFF" or if you want to turn it back on "python BRSswitch.py ON"
If you forget, you can -h it and it will help you out.
Ross Kennedy & Ed Daw Instructions for acquiring 100kHz bandwidth ASD, cross correlation, and cross spectral density measurements with 100kHz bandwidth. 1. Check that the LVEA SR785 in the LVEA is hooked up to the OMC DCPD whitening preamplifier pick-off (channel A) and the long RG-58 cable back to the REFL electronics (channel B). I left it hooked up when we departed, but it might have been disconnected, I guess. Check also that the GPIB and wireless internet box are connected and powered up. 2. On a control room machine, cd to /ligo/home/controls/edaw_work/hfross 3. Do ./SR785broadscan - this generates a sequence of measurements covering DC-102.5kHz in 16Hz bins. There are four resulting plots, in order, ASD from the OMCDCPD1, ASD from REFLAIRQ90, cross correlation density from both ports (note that this is per Hz over 16Hz bins, so multiply by 16 to obtain cross correlation on the usual 0-1 scale), PHASE of the cross spectrum between OMCDCPD1 and REFLAIRQ90 (mainly useful to see the noise in the phase disappear at frequencies where there is extensive cross correlation. Results appear in the saved_data subdirectory. Text files of data are saved there too for more detailed information on line frequencies. Let me or ross know if this doesn't work - we can probably help fix it.
Alexa, Sheila. Evan, Daniel Koji
Unfortunately, all of these promising developments happened during a lock where the ETMY ESD was tripped, untripping it breaks the lock. Evan has edited the guardian so that it will not move past ALS unles the ESD is on, so this should not happen to us again.
Sadly, the wind started gusting to 30-35 mph while we were reseting the PUM watchdogs, and is forecast to stay that way for about 24 hours. We have locked with these kind of windspeeds before, but today we are having difficulty, perhaps because the ground motion below 1 Hz was not small even before the wind started. The BRS is on at end X with broad low frequency sensor correction, however this storm seems to be mostly along the Y direction. Evan has also increased the common tidal bandwidth again (0.08 now). We've ben keeping ALS locked for 10-15 minutes.
We finally have a complete set of medm screens for the timing system.
There are a lot of red indicators due to the fact that the svn revision numbers are reported as zeroes by the DuoTone and IRIG-B slaves. There is no indication that we are not running the firmware we think we do, but we can't really check this.
The EX fanout reports a VCXO range error which has been there for a long time and is most likely is due to a busted readback.
All other master, fanouts and slaves are reporting a green status.
J. Kissel, S. Dwyer, E. Hall, K. Arai, K. Izumi I'm embarrassed to say I'm overwhelmed by the wealth of open loop gain transfer functions (OLGTFs) that have been taken recently. But, there's also a ton of stuff to explain, so I summarize comparisons and information from the 3 OLGTFs that were taken prior to this weekend here. More to come on this past weekend's new data. Summary Points: - With a "streamlined" matlab model (similar in content to, but separate from the Noise Budget DARM loop model) we can predict the following DARM OLGTFs (measured between 5 and 300 [Hz]): 2015-03-10, Prior to DARM Loop Shape Modification LHO aLOG 17153 2015-04-02, Post DARM loop modification LHO aLOG 17642 2015-04-06, Post DCPD Analog Electronics Compensation Correction LHO aLOG 17710 to within 10% in magnitude and 5 [deg] in phase (between 5 and 300 [Hz]), with the following uncertainties (determined by the standard deviation of the model parameters for these three comparisons): - DC optical gain of 1.1e6 +/- 8% - residual, [unknown / unaccounted for] time delay of 93 +/- 30 [us] - The DCPD Analog Electronics Compensation confusingly did *not* affect the frequency dependence of the OLGTF between 2015-04-02 and 2015-04-06, even to the 10-20% level Koji suggests. As of now, based on these measurements alone, I argue that the lack of discernible change in the OLGTF suggests that we do *not* need to make any correction to our CAL-CS front end calibration. - Just because I can model the open loop gain TFs to this uncertainty level does *not* mean the overall DARM calibration has this uncertainty. We still have a (potentially) large variation in ESD actuation coefficient due to charge, a (potentially) large uncertainty in the DARM coupled cavity pole frequency, a (potentially) large optical gain fluctuation from lock to lock, and (potentially) large discrepancy between the real actuation strength and what we've measured, and all things of which we haven't realized. Detail Points: -------- - Kiwamu had put together a "simple" model of the DARM loop when he'd updated the DELTA L EXTERNAL calibration in the CAL-CS front-end filters after the second-to-last time the DARM loop shape was changed (see LHO aLOG 17151). As he mentions in his aLOG, this code lives here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/DARM_OLTFGTF_LHOaLOG17153.m That model had included Actuation Function - The QUAD SS Model that have the current foton filter file's damping filters engaged with gains that are hard-coded into the generate_QUAD_Model_Production function to gather the necessary damped SUS transfer functions in [m/N], i.e. the output of /ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/MatlabTools/QuadModel_Production/generate_QUAD_Model_Production.m using the /opt/rtcds/lho/h1/chans/H1SUSETMX.txt foton file. - An assumed DAC gain of 2^18 / 20 [V/ct]. - The UIM analog electronics chain using /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/make_OSEM_filter_model.m all parameters of which are "as designed" and not measured. This turns the [N] of drive at the UIM into [ct] of drive at the output of the ETMX_L1_LOCK_L bank. - The ESD analog electronics chain using a simple, linearized model of 2*alpha*Vbias*40^2, where 40 is the range of the DAC, Vbias is the bias voltage, in units of the DAC [V], and alpha is the force coefficient. He uses the force coefficient that has been confirmed by measurement to be (2.0 * 1.417)e-10 = 2.834e-10 [N/V^2]. (see LHO aLOG 16843) - The ESD driver's single pole filter - The correct hierarchical filters from the current foton file (same as above), with known gains grabbed from conlog. The DARM filter - Loaded in from the H1OMC foton file from the filter archive, /opt/rtcds/lho/h1/chans/filter_archive/h1omc/H1OMC_1110098950.txt, with known gains from conlog. The Sensing Function - Assuming the Actuation and DARM DC gains are correct, the remaining scale factor needed to match the OLGTF model to the measurement is what is used for the interferometer's optical gain, in [m/ct] - A single-pole zpk filter, with the pole at 389 [Hz] Time Delay - An overall true time-delay to account for *all* the high frequency behavior like anti-imaging and anti-aliasing filters. I've used this model as a template to get started, but I've made the following changes to (a) be able to compare many OLGTFs against the model that best represents the DARM loop at that time, and (b) include the now-better-known high-frequency effects: (1) Pulled out the hard-coded parameters of the model, and put them in a separate function identified by their GPS time, /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/ H1DARMparams_1109994128.m H1DARMparams_1111998876.m H1DARMparams_1112399129.m (2) I've modified the filter files chosen such that both the OMC *and* the SUS are pulling from the filter archive, not the live data. This will be come relevant later when we track changes in UIM / TST crossover, or when we begin using all stages like LLO has. (3) I've now included both the analog and digital anti-aliasing in the sensing function, and the analog and digital anti-imaging in the actuation function. The digital AA and AI filters are the same, from the function /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/S7/Common/MatlabTools/iopdownsamplingfilters.m and the analog AA and AI filters are the same, taken from .mat file inherited from the 40m, which has been pruned and now lives in /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/S7/Common/MatlabTools/analog_65k_AAAI_filter_response.mat (4) I've included the known time delays: Sensing: 1 IOP Computation Cycle (65k) + 1 OMC Computation Cycle (16k) Actuation:1 SUS Computation Cycle (16k) + 3-Cycle IOP Error Checking (65k) + 1 IOP Computation Cycle (65k) + Zero-order Hold Delay (1/2 a 65k cycle) (which total 205 [us]) and created a new parameter for the "unknown" time delay, which is fit to make the high-frequency phase flat. Known remaining flaws in the model: - Mismatch in digital compensation for analog whitening or pre-amps of the DCPDs -- but this should now be *much* better than before (see LHO aLOG 17650) - Mismatch in digital compensation for analog whitening of the SUS UIM coil driver and now the ETMY ESD Driver filter -- Measurements have shown that the UIM driver agrees quite well with the model (see LHO aLOG 4495), but this hasn't been confirmed for these SUS individually and/or after their increase in range (Integration Issue 762). -- The "temporary" ESD low-noise filters (E1500164) were compensated with their designed poles and zeros, I don't know how well they're matched. - The model uses 389 [Hz] for the DARM coupled-cavity pole, but this is a modelled value from the L1 IFO's losses (see LHO aLOG 15923). Our losses are larger, so we expect our cavity pole frequency to be higher. More to come from Paul and Daniel on this. The data out to 1 [kHz] from over the weekend should also help with getting a measured confirmation. This model is a function which takes in the parameter files, is called /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/H1DARMmodel_preER7.m, and returns the modelled and measured open loop gain as well as every single possible thing you could possibly ever want out of the model in a parameter structure (including the things that are independently computed in the model itself, like the full actuation function and the full sensing function). This model can then be looped over, which I've done with the function /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/CompareDARMOLGTFs.m I *hope* that this makes it much easier to compare a new DARM OLGTF against others as we take them.
Scott L. Ed P. Chris S. The crew cleaned 70 meters from last single door to mid station on X-1. Crevice tool cleaning remaining on that section. Beam tube pressures monitored by control room operator during cleaning operations.
Last week I tried exporting some of the blend filters mods that I had developed at ETMX, but found that at least one of the blends didn't work. Today I worked on figuring out why. I started by doing an ugly hack of Jeff's plot_current_blends script so I could look at the original LLO blends in complementary form. When I used the hack to look at what I had installed, it became immediately clear why my blend didn't work. In the attached image, I show the complementary version of the "bad" blend (solid lines) and a "good" blend. The good blend is what is currently running on st2 on all of the BSC's in X,Y,Z and RZ. It's a modification of a 250 mhz blend that we stole from LLO (they run a similar blend). The bad blend is a modified version of the 01_28 blend we use on the HAM ISI's. You can see that at .4 hz I managed to introduce a notch ( in the solid red line) that did all kinds of band things to the plant.
This happened because I was designing in foton (blind), and couldn't see the complementarity of the blends from there. I thought I was safe because I was making small adjustments and was trying minimize any phase wobbles around the blend frequency. Turns out that is not enough. I think fixing the complementarity will be relatively simple, the first image in my alog 17790 shows why I would like to get this to work, roughly an order of magnitude reduction at 1 hz, with some low frequency injection.
The amazing part is this blend runs on ITMY and ETMX.
The 2 attached pdf's are the original blends (1st pdf) and modified blends (2nd pdf) for both stages X, Z, RY, RZ , shown in both installed and complementary versions.
The successful mods I made are adding elliptical filters to the St1 90 mhz Z blend (alog 17702), a more effective elliptical to the St2 250 blends (alog 17488) and an elliptical to 750mhz St1 RZ cps blend. I haven't found the to do much good, but it doesn't do any harm that I've seen.