I installed a DSUB9 breakout board at the DSUB9 rear panel output from the output mode cleaner DC photodiode prewhitening amplifier board in rack ISC R5. This is to enable acquisition of broadband (initially 100kHz bandwidth) power spectral densities of the DC photodiode output.
Posted below are the March temperature and relative humidity data from the Long Term Storage (LTS) Dry Boxes in the VPW. DB1 and DB4 are in use and partly loaded with parts. DB2 and DB3 were turned on on 03/31/15 and will be reported next month. The trends look good, with mean rH at 0.23% and 0.27% and temperature at 71F for both boxes. The humidity spikes are incursions into the cabinets to add or remove parts. I am not sure what caused the almost 10 degree temperature drop in DB1 (not recorded in DB4) on 03/23/15, however there were no spikes in the rH during this time. Will investigate if a trend develops.
Next Tuesday is the HAM6 vent!
Aiden will be coming up next week to work on the ETM tables.
Tuesday maintenance 8-12 will continue even though 3IFO is done.
Safety Meeting:
Before commissioning commenced this morning, I received the all clear to rebuild, install and restart the SUS ITMX & ITMY models that were modified last night to include DARM_CTRL signals (see LHO aLOG entry 17599). - SDF snapshots were taken of both ITMs in SAFE state and checked into the svn - BSC-ISIs were transitioned to OFFLINE state - Models compiled, installed and restarted, with no issues - ITMs WDs un-tripped and recovered to ALIGNED state - BSC-ISIs WD'd un-tripped and recovered to FULLY_ISOLATED state As, suspected, it was necessary to restart the DAQ process, which was carried-out courtesy of Jim B at approx 09:30am [PT], with no issues.
Sheila, Koji, Dan, Evan
Today we recovered a 35 Mpc lock and put the necessary steps in the Guardian.
For EY bounce mode damping, the DARM→EY element in the LSC output matrix is set to −1 and L3 ISCINF is enabled. Length feedback is entirely disabled on EY at this point. Then in the M0 DARM damping filter module, the +60° rotator and the bandpass are enabled, and the gain is −0.1.
Since this new damping feedback topology is not fully implemented on the ITMs, the DARM error signal is routed through LSC-YARM and into IX L3. In M0 DARM filter module, there is no phase rotation, only the bandpass at 9.7 Hz. I found that I needed to flip the sign of the gain compared to what we used to use; −80 seemed to damp the mode alright. Since this is a hack and likely will not be necessary 24 hours from now, it has not been put into the Guardian.
In both cases I have removed the 120 dB of gain from the bandpass FM and put it in a separate FM. This 120 dB is no longer sensible when using DARM control rather than DARM error.
Sheila has pointed out that any test mass which uses this damping scheme is ineligible to be used for feedfoward subtraction of other length DOFs, unless we come up with some workaround.
As mentioned yesterday, we reverted the HAM6 centering scheme so that we could keep the interferometer ASC working.
Consequently, we now see scattering shelves in the DARM spectrum if the OMC ASC gain is set to 1. Setting it to 0.2 makes the DARM spectrum less painful to look at.
Although tonight's campaign of noise coupling measurements was cut short by the PSL tripping, Koji and I managed to get a MICH→DARM transfer function with good coherence from 20 Hz to 400 Hz. The DTT files are attached.
For quiet data, one can look at 2015-04-01 07:50:15 to 07:55:15.
Now that we have a reliable readback of the EY ESD state, the EX→EY transition has been reenabled in the Guardian.
The new final state is LSC_FF, which enables the MICH and SRCL feedforward and adds a cutoff to the SRCL loop.
Koji, Evan
The NPRO shut off at around 08:11:00 UTC.
The interferometer was locked with no measurements or injections running.
PSL restarted without issues at ~7:30 this morning.
It is not clear if the cause of the trip was an NPRO shutdown or a flow sensor glitch. Investigation ongoing.
In the future, if the PSL drops out like this don't hesitate to call me at any time of day or night, any day of the week (home 509 627-1129, cell 509 539-4354).
I will either walk someone through the restart or come in myself and restart the system. I prefer not to leave it down for longer than necessary.
With help from Evan Hall, Jeff Kissel and Ross Kennedy, got preliminary spectra from REFL-I and IMC-I, with the idea of identifying high frequency lines. A plot and some data are attached. Here are the frequencies of lines and clusters identified in these plots. They were taken with the SR785 box next to WHAM1, using the GPIB/ethernet bridge to the control room and Eric Quintero's readout scripts. There are two attached figures, one with the two ASDs in separate planes, the other with them overlaid. Notice that the cavity length mode at around 36kHz is not in exactly the same place in the two channels, and neither is the first harmonic at around 70kHz. Other narrow peaks, however, do line up. REFL-Q Frequency ; ASD 1. 2440Hz ; 21uVrms/rtHz 2. 13.9kHz ; 16uVrms/rtHz 3. 34.4kHz ; 16uVrms/rtHz - broadband, bandwidth 1.2kHz 4. 40.4kHz ; 9.7uVrms/rtHz 5. 56.7kHz ; 13.0uVrms/rtHz 6. 60.9kHz ; 5.7uVrms/rtHz 7. 62.4kHz ; 7.4uVrms/rtHz 8. 65.6kHz ; 6.6uVrms/rtHz 9. 66.3kHz ; 6.3uVrms/rtHz 10. 70.2kHz ; 18.9uVrms/rtHz - broadband, bandwidth 3kHz IMC-I Frequency ; ASD 1. 2453Hz ; 2uVrms/rtHz 2. 13.9kHz ; 16uVrms/rtHz 3. 38kHz ; 4uVrms/rtHz - broadband, bandwidth 1.2kHz, but does not line up with REFL-Q peak 3. 4. 40.6kHz ; 2.4uVrms/rtHz 5. 56.5kHz ; 2.4uVrms/rtHz 6. 62.4kHz ; 2.4uVrms/rtHz 7. 65.6kHz ; 3.1uVrms/rtHz - double peak, just resolved. 8. 69.1kHz ; 3.1uVrms/rtHz 9. 76.6kHz ; 9.3uVrms/rtHz - broadband, bandwidth 3kHz, but does not line up with REFL-Q peak 10.
If we want to monitor some or all of these lines, it wouldn't be such a difficult job to make a heterodyning circuit for the port in question, and feed the output to an additional DAQ channel.
Here's a linear scale plot of the same peaks measured in IMC-I and REFL-Q.
I took the transfer function between H1:OMC-DCPD_A_OUT and H1:OMC_DCPD_B_OUT while the IFO was still at RF Readout.
The balance of the PD at DC is actually very good (delta<0.5%) but they are not well matched between 10-100Hz.
The difference is as much as 20%. The noise at high frequency is due to shotnoise between two PDs.
This could be caused by a mismatch between the V2cnt filters in the filter modules and the actual preamplifier filters in the vacuum chamber.
I'll look into this issue in the daytime as I don't want to screw up the overall calibration for DARM.
J. Kissel, E. Hall, S. Dwyer After getting back to a reasonable DARM spectrum, we began experimenting with the new DARM_CTRL damped 9 [Hz] highest vertical mode. We quickly discovered that the change made for the ITMs won't work, because the single pipe in which ISC control comes into the suspension -- which is what we'd picked off the control point from to feed to the top mass -- can no longer contain DARM signals after we split / redistributed the LSC and OMC front-end code (i.e. there are no DARM to ITM output matrix elements in the LSC control). Evan hacked around the problem for tonight by using the input matrix to pipe DARM_ERR straight through the YARM bank, and out to the ITMs. However, for a more permanent solution, I've modified the ITM models (again) to include a new PCIe receiver of the H1:OMC-CAL_DARM_CTRL IPC channel (already being broadcast in the corner for the CAL-CS calibration of DELTA L EXTERNAL), which is now piped separately from DARM_ERR into the main QUAD block, and fed to the top mass for bounce damping. The model changes for h1susitmx and h1susitmy are complete, I've confirmed that they can compile, and I've committed the changes to the userapps repo. The attached screen shots show the various portions of the model that were changed. We (either Stuart or myself) will install and restart the front-end process in the morning.
J. Kissel, D. Barker, J. Batch, J. Warner, S. Aston Advised by J. Smith that LHO is suffering from Major-Carry transition glitching (LHO aLOG 17555), we've taken advantage of the front-end model restart chaos to re-calibrate the BSC SUS 18-bit DACs -- i.e. taken all front-end "user" processes (i.e. the SUS code) offline, and restarted the IOP process for the h1susex, h1susey, and h1susb123 front end computers / I/O chassis, which runs each chassis' DAC cards through their auto-calibration procedure. Those front ends include DACs for H1SUSETMX, H1SUSTMSX, H1SUSETMY, H1SUSTMSY, H1SUSITMX, H1SUSITMY and H1SUSBS. Sadly, I realize while writing this entry, and after rereading Josh's entry (LHO aLOG 17555), that he says that it's the -2^16 transitions that are most of the glitches. Indeed, I even got an email I got from P. Fritschel today, en passant, reminding me that J. Betz and he have shown that the recalibration procedure does not reduce the -2^16 [ct] transition glitching (see G1401269). Hurumph. Anyways, the re-calibration will at least help with the drift in glitchiness of the other two transitions ( 0 and +2^16 , potentially seen in, e.g. 16354). I attach procedural notes that I gathered during the restart process (I learned quite a bit!) P.S. There may be a "danger" that auto calibration of the 8th DAC (or DAC cardNum 7 if you count from zero) on the h1susb123, which house the control for the PUM on ITMX and ITMY, as the h1susb123 dmesg reports that the AUTOCAL failed for this DAC: [6643729.576353] h1iopsusb123: 18-bit dac card on bus 36; device 4 [6643729.576367] h1iopsusb123: pci0 = 0xdfefe000 [6643729.576391] h1iopsusb123: dac pci2 = 0xdfefc000 [6643729.576398] h1iopsusb123: DAC I/O address=0xdfefc000 0xffffc90011b08000 [6643729.576403] h1iopsusb123: DAC BCR = 0x40000 [6643729.576427] h1iopsusb123: DAC BCR after init = 0x20040000 [6643729.576432] h1iopsusb123: DAC OUTPUT CONFIG = 0xff [6643734.724703] h1iopsusb123: DAC AUTOCAL FAILED in 5133 milliseconds [6643734.724712] h1iopsusb123: DAC OUTPUT CONFIG after init = 0x102ff with BCR = 0x40000 [6643734.724719] h1iopsusb123: set_8111_prefetch: subsys=0x8111; vendor=0x10b5 I've confirmed that for every other DAC card (5 in EX, 5 in EY, and the other 7 on B123) we re-calibrated today, the dmesg claims success.
Its actually worse even than the lower crossing not going away. There's evidence that over time the glitches grow back, and after time the reset isn't as effective on some channels. I refer you to LLO alog 16376
J. Kissel, D. Macleod, J. Betzwieser WP #5124 The hardware injection team wished to have separate filter banks for transient hardware injections -- one CBC and one for BURST -- to ease the automation of recording the information for later processing. There was previously only one called TRANSIENT. As such, Duncan modified the /opt/rtcds/userapps/release/cal/common/models/CAL_INJ_MASTER.mdl library part, committed to the repo, that corner of which I updated, and recompiled, installed, and restarted the /opt/rtcds/userapps/release/cal/h1/models/h1calcs.mdl front end model/code. Details: - See attached screen shot for what the hardware injection corner of the h1calcs.mdl looks like now, with the update. - The ODC vector for transient injections is now also split into BURST and CBC bits. - This required a DAQ restart. - I confirmed that there were no SDF system differences before restarting, so there was no need to capture a new safe SDF file. - Since this was merely an update to the library part, there are no changes to the top-level model, so there's nothing to commit once finished.
J. Kissel, S. Dwyer As we battle against wind again tonight, Sheila asked "Are there windy blends on the ITMs?" I replied, "No, but we can easily copy them from the ETMs." As such, I've copied and pasted FM10, the 90mHz blends, of the H1ISIETMX CPS, L4C, and T240, CUR filter bank on ST1 into the corresponding CUR and NXT filter banks of H1ISIITMX, H1ISIBS, and H1ISIITMY. I attach a comparison between the 45mHz and 90mHz blends, generated by /ligo/svncommon/SeiSVN/seismic/Common/MatlabTools/plot_current_blends.m (where I've removed the RY filters by hand, because they're split between two banks and therefore what would be plotted can't be trusted) 'cause I've never seen such a comparison before -- at least their complementary filter form. We'll need more time with the IFO when it's more stable, but preliminary results -- where we'd switched the blends on ITMX in X and ITMY in Y to 90 [mHz] -- say that it isn't better. But they're preliminary, and I can't rule out that I've screwed up the copy-and-paste process. I'll double check everything once I don't have two more aLOGs to write. P.S. Questions about the blend filters: 90mHz: - Do we really like these 90 [mHz] blends? - Seems like we should roll off the T240s way faster above 10 [Hz], like is done in the 45 [mHz] blends. - Do the Q's of the 0.5 and 1 [Hz] notches need to be that deep, or that what's *really* giving us the improvement when it's windy? - Seems like the notches are at the wrong frequency, and could be moved down to get similar notching as the 45 mHz blends, and to better match the 0.43 [Hz] mode of the QUAD. Or maybe it's matching the 0.56 [Hz] pitch mode, which is actually the problem under windy conditions? 45mHz: - Do we really like that much *un*complementarity in the 45 [mHz]? Maybe at this low a frequency, the loop gain is large enough -- even without the boost -- that any phase wiggle doesn't impact the stability during ramp up or nominal operations. But it'll certainly change the isolation loop error signal at low frequency when switching *between* blends. But also maybe not, because we've been able to successfully switch between 90 and 45 mHz blends on the ETMs for months now...
J. Kissel, S. Dwyer, J. Warner Jim spent some more time trying to understand the difference in noise change in the HAM5 and HAM6 ISI X&Y directions (see LHO aLOG 17521) today, but left the HAMs in an odd configuration, where his new elliptic low-passes were turned ON for HAM5 X&Y and HAM6 X only. Having trouble locking the DRMI, we've turned these filters OFF. Not because we actually have reason to think they're the problem, but because we want one less thing to think about whether it *could* be the problem. Also, because we otherwise can't think of how the additional elliptic low-pass can make anything *worse* -- except if it's only installed sporadically in random HAMs as Jim left it -- Jim has copy-and-pasted the filter to every HAM chamber in the X&Y DOFs, such that we *could* turn on the elliptic for *every* HAM in X&Y if we think it'll help. These filters currently live in FM5 of the "current" CPS blend filter banks in X&Y (see attached example, called "EllipseP"), and they have a nice slow ramp time, such that you can turn them off and on willy-nilly. BUT because they're in a separate bank the blend switching doesn't work with them. Of course, if we end up really liking these filters, we'll combine them with the 01_28 blends, and we will be able to again blend-switch to our hearts' desire.
J. Kissel, K. Izumi WP #5128 As per Rana's suggestion (LHO aLOG 17473), we've switched from using (the equivalent of) DARM_ERR to using (the equivalent of) DARM_CTRL for the error signal used for the M0/Top Mass, highest Bound and Roll mode damping of the QUADs on the ETMs. Details: - Thankfully, this did *not* require adding any new IPCs -- all we did was replace the DARM_ERR M0 top-mass input "from" tag with a copy of the L3_ISC_DIST_L "from" tag, which is equivalent to the output of the L3 ISCINF L filter bank, which is post-IPC-signal-conditioned equivalent to the DARM_CTRL pick-off in the OMC model that's (of course!) already sent via RFM IPC from the corner to the end station. See attached screenshots. - Because the all of the top level QUAD models are unhooked from the library (thanks to how tidal has been implemented differently at both sites, and which ASC sensor is used for damping the violin modes), this was an easy swap of "from" tags to the just-below-top-level QUAD block in each of the four QUAD models: /opt/rtcds/userapps/release/sus/h1/models/ h1susetmx.mdl h1susetmy.mdl h1susitmx.mdl h1susitmy.mdl and required no DAQ restart. This also therefore doesn't impact LLO or the QUAD library parts. All top level models have been committed to the repo. - The models were compiled, installed, and then the restart was coupled with the recalibration of the QUAD computer's 18-bit DACs (separate aLOG pending).
SUS ADC move, ETM to AUX
Richard, Jim, Stuart, Jeff, Dave:
The second ADC in the h1susex, h1susey IO Chassis were removed and inserted as a fith ADC in the h1susauxex, h1susauxey chassis. The IOP models h1iopsusex and h1iopsusey were modified to remove ADC1. This did not affect the SWWD code, it only reads ADC0 channels. The IOP models h1iopsusauxex and h1iopsusauxey were modifed to add ADC4. These models were started when the front ends were powered back up after the hardware swap.
PEM Mainsmon DAQ rate increase [WP5123]
Robert, Dave:
I increased the DAQ data rate for the PEM MAINSMON channels, including the quadrature sum, from 256Hz to 1024Hz as approved by Peter in DCC document T1400768. I discovered that the ODC part in the model did not differentiate between end stations, resulting in duplicate channels in the DAQ ini files. I renamed these parts ODC_X and ODC_Y to remove the duplication. The 60Hz mains AC voltage now looks like a clean sine wave in the DAQ (please see attached image). This closes WP5123.
Suspensions recalibration of 18bit-DACs
Jeff, Jim, Dave:
Jeff restarted the SUS QUAD IOP models to perform a recalibration of the 18bit-DAC cards. He noted that some restarts completed too rapidly for the calibration to have been performed successfully (should be 5 seconds per DAC card). This was an intermittent problem, we should investigate on the DTS.
The restart without sufficient time for AUTOCAL is likely CDS Bugzilla 792, that is fixed in tagged release 2.9.1 (as well as trunk). We installed RCG 2.9.1 at LLO today. Only Y-end SUS, SEI rebuilt so far
[Richard M, Filiberto C, Stuart A] Further debugging and refinement of the ESD Driver remote restart has been carried out during today’s maintenance period. Yesterday, it was reported that the Y-end ESD Driver could remotely be turned on, but oddly, not off (see LHO aLOG entry 17570). The sequencer module was swapped out for the spare, which rectified the issue (see LHO aLOG entry 17589). With the aim of eventually being able to hook-up ESD Driver Analogue and Digital monitors, it was first necessary to swap an ADC from the SUS front-end into the SUSAUX IO chassis (as per the latest version of D1002741). This also required these ADC's be relocated in the IOP models, which was carried out courtesy of David B. Moving the ESD monitoring ADC also necessitated channel name changes in the ESD Monitor MEDM screens I generated yesterday. It was also found during debugging that the single START/STOP button latched high, so I've added another button to enable latching the ESD reset channel low. Therefore, to toggle the state of the ESD Driver, from active to idle or visa versa, it is necessary to go high for ~1 second, then return to low. n.b. nominally this channel should be low. If all is well with Beckhoff, then this should be sufficient to transition the state of the ESD Driver. At Jeff K's request, I've also added a large ESD Active display to help users quickly identify the state of the ESD Driver (Red = Off, Green = On). This is determined by evaluating if the ESD DC bias channel monitor is above or below a threshold of 200 counts and the ESD reset channel is set low. The modified ESD Monitor MEDM screens for each state can be seen below. The updated MEDM screens have been checked into the cds userapps svn:- /opt/rtcds/userapps/trunk/sus/common/medm/quad/ U SUS_CUST_QUAD_MONITOR_EX_OVERVIEW.adl U SUS_CUST_QUAD_MONITOR_EY_OVERVIEW.adl Digital monitors are now reporting values, however, these should be ignored until the cabling is hooked-up.
Just a reminder that each ETM ESD Driver Monitor Overview MEDM screen is available via Sitemap e.g. X-arm -> ETM/TM -> ETMXESD (see Sitemap snapshot below).
Sheila, Ed, Ross, Evan
This morning we had another incident where we seemed to have glitches in the channel H1:ALS-Y_REFL_CTRL_OUT_DQ that could have been the cause of ALS locklosses, similar to what was described in alog 15242 and alog 15402. Some screenshots are attached. There is a distinctive pattern in the REFL CTRL signal, and the error signal (ALS-Y_REFL_ERR_OUT_DQ) has a large glitch, as well as the transmitted green light (ALS-C_TRY_A_LF_OUT_DQ). Today these things were happening only every 10-15 minutes, but that is often enough to prevent locking. As before this problem went away after a while, without us doing anything to fix it. Several screen shots are attached. These glitches sometimes show up in the X arm, but that could be because the DIFF control imposes them on the X arm even if the originate in the Y arm. The glitches still happen when we had tidal off, and COMM unlocked, so I would not think that there was anyway a glitch that originated in the X arm could have been imposed on the Y arm. There are no coincident gliches in the Optical levers or in the Fiber control or error signals.
It would be good to know how often these glitches happen, how intermitent the problem has been over the last several months, and how often they coincide with a lockloss. Ed and Ross started to look into this, and started a script to identify these glitches in a way that is easier than looking though a time series. I made an attempt to use omega scan on ligodvweb, but I ran into trouble producing a plot.
I am wondering if anyone from Detchar has tools that could be helpful (and maybe used from the control room?) in finding times when these glitches have happened.
We don't currently have glitch-finding algorithms running on those channels, but we'll start running them today and also produce results for the last week. In the meantime, just looking at one event, it looks like a BRMS from 50 to 100 Hz on ALS-Y_REFL_CTRL_OUT_DQ would do a good enough job of finding these.
The primitive code for finding these ALS glitches is attached; it uses the MATLAB frontend to NDS2 to get the data, and in this data it searches the H1:ALS-Y_REFL_ERR_OUT_DQ channel for the following: a data sample that exceeds 20000 counts, followed in less than 500 bins (30ms) by at least one sample that is lower than -20000 counts. This is a crude bipolar burst search of the channel, and it seems to find ALS glitches with high efficiency. There seem to be three classes of ALS glitches - 1) streams of large glitches that occur far from IFO locks, where the ALS servo is just not working very well/ hopping between spatial modes, 2) smaller glitches coincident with losses of lock 3) other smaller glitches whilst locked that are not coincident with loss of lock. I have also attached 4 pdfs. Attachments are explained below: 1. findalsglitch.m - a glitch search code that downloads and searches a predetermined amount of full rate data from ALS-Y_REFL_ERR_OUT_DQ 2. rangealsglitch.m - a code that calls findalsglitch.m multiple times, after breaking a predetermined data stretch into manageable chunks. 3. A pdf of a stream of large glitches in ALS occuring when the machine is out of lock 4. A pdf of a small ALS glitch during a lock stretch where the IFO did not lose lock coincident with the glitch. 5. A pdf of a small ALS glitch during a lock stretch coincident with an IFO loss of lock. 6. A zoomed in version of 5 showing the shape of the glitch in detail.
Here is one more example of this kind of glitch, I think this is an example of the Y arm ALS glitch causing a lockloss.
