We re-checked IMC locking, arm alignments (we were able to lock and dither align both arms today, and also made the michelson spot look reasonable on the camera) and made sure that the AS and REFL spots were in the camera ballpark. We then proceeded to remove the heavy doors off ITMY and BS/PRM chambers. We also quickly made sure that it is possible to remove the side door of the OMC chamber with the current crane configuration, but have left it on for now.
The hunt for clipping now begins.
I say just fix the clipping. Don't worry about the PRM OSEM filters. We can do that next time when we put in the ITM baffles. No need for them on this round.
In the afternoon, we took the heavy door off the OMC chamber as well, such that we could trace the AS beam all the way out to the AP table.
In summary, we determined the following today:
Attachment #5 is extracted from the 40m CAD drawing which was last updated in 2012. It shows the beam path for the output beam from the BS all the way to the table (you may need to zoom in to see some labels. The drawing may not be accurate for the OMC chamber but it does show all the relevant optics approximately in their current positions.
EQ will put up photos from the ITMY and BS/PRM chambers.
Plan for Monday: Reconfirm all the findings from today immediately after running the dither alignment so that we can be sure that the ITMs are well-aligned. Then start at OM1 and steer the beam out of the chambers, centering the beam as best as possible given other constraints on all the optics sequentially. All shutters are closed for the weekend, though I left the SOS iris in the chamber...
Here is the link to the Picasa album with a bunch of photos from the OMC chamber prior to us making any changes inside it - there are also some photos in there of the AS beam path inside the OMC chamber...
Oct. 15, 2016
Another attempt (following elog 8755) to extract the oven transfer function from time series data using Matlab’s system identification functionalities.
The same time series data from elog 8755 was used in Matlab’s system identification toolbox to try to find a transfer function model of the system.
From elog 8755: H(s) is known from current PID gains: H(s) = 250 + 60/s +25s, and from the approximation G(s)=K/(1+Ts), we can expect the transfer function of the system to have 3 poles and 2 zeros.
I tried fitting a continuous-time and a discrete time transfer function with 3 poles and 2 zeros, as well as using the "quick start" option. Trying to fit a discrete time transfer function model with 3 poles and 2 zeros gave the least inaccurate results, but it’s still really far off (13.4% fit to the data).
1. Obtain more time domain data with some modulation of the input signal (also gives a way to characterize nonlinearities like passive cooling). This can be done with some minor modifications to the existing code on the raspberry pi. This should hopefully lead to a better system ID.
2. Try iterative tuning approach (sample gains above and below current gains?) so that a tune can be obtained without having to characterize the exact behavior of the heater.
Oct. 16, 2016
-Found the raspberry pi but it didn’t have an SD card
-Modified code to run directly on a computer connected to the TC 200. Communication seems to be happening, but a UnicodeDecodeError is thrown saying that the received data can’t be decoded.
-Some troubleshooting: tried utf-8 and utf-16 but neither worked. The raw data coming in is just strings of K’s, [‘s, and ?’s
-Will investigate possible reasons (update to Mac OS or a difference in Python version?), but it might be easier to just find an SD card for the raspberry pi which is known to work. In the meantime, modify code to obtain more time series data with variable input signals.
Ashley Fowler "high shool" student received basic 40m safety training and Lydia is her guarding angle.
[ericq, lydia, gautam]
IMC realignment, Arm dither alignment
I connected to the serial port using screen (through Terminal) and using Arduino's serial monitor and basically received the same strings that were received through python, so it's not a python issue. Checked the other TC 200 module and was also receiving nonsense, but it was all question marks instead of mostly K's and ['s.
This rules out a few possible reasons for the weird data. Next steps are to set up and configure the Raspberry Pi (which has been interfaced before) and see if the problem continues.
Lydia and I investigated the extra green beam situation. Here are our findings.
I can't think of an easy fix for this - the layout on the OMC chamber is pretty crowded, and potential places to install a beam dump are close to the AS and IMC REFL beam paths (see Attachment #1). Perhaps Steve can suggest the best, least invasive way to do this. I will also try and nail down more accurately the origin of these spots tomorrow.
Light doors are back on for the night. I re-ran the dithers, and centered the oplevs for all the test-masses + BS. I am leaving the PSL shutter closed for the night
Everybody is happy, except ITMY_UL or satalite box.
Gautam shows perfect form in the OMC chamber.
Tilted viewports installed in horizontal position. Atm2
[ericq, lydia, steve, gautam]
AS beam on OM1
Link to IMG_2337.JPG
AS beam on OM2
AS beam on OM3
AS beam on OM4
I didn't manage to get a picture of the beam on OM5 because it is difficult to hold a card in front of it and simultaneously take a photo, but I did verify the centering...
It remains to update the CAD diagram to reflect the new AS beam path - there are also a number of optics/other in-vacuum pieces I noticed in the BS/PRM and OMC chambers which are not in the drawings, but I should have enough photos handy to fix this.
Here is the link to the Picasa album with a bunch of photos from the OMC, BS/PRM and ITMY chambers prior to putting the heavy doors back on...
SRM satellite box has been removed for diagnostics by Rana. I centered the SRM Oplev prior to removing this, and I also turned off the watchdog and set the OSEM bias voltages to 0 before pulling the box out (the PIT and YAW bias values in the save files were accurate). Other Oplevs were centered after dither-aligning the arms (see Attachment #8, ignore SRM). Green was aligned to the arms in order to maximize green transmission (GTRX ~0.45, GTRY ~0.5, but transmission isn't centered on cameras).
I don't think I have missed out on any further checks, so unless anyone thinks otherwise, I think we are ready for Steve to start the pumpdown tomorrow morning.
These old specs are not so bad. But we now want to get replacements for the TRX and TRY and PSL viewports that are R <0.1% at 532 and 1064 nm.
I don't know of any issues with keeping BK-7 as the substrate.
Unfortunately, it seems that the large power supply which is used for the heater is dead. Or maybe I don't remember how to use it?
The AC power cord was plugged in to a power strip which seems to work for IO chassis. We also tried swapping power strip ports.
We checked the front panel fuses. The power one was 3 Ohms and the 'bias' one was 55 Ohms. We also checked that the EPICS slider did, in fact, make voltage changes at the bias control input.
Non of the front panel lights come on, but I also don't remember if that is normal.
Have those lights been dead a long time? We also reconnected the heater cable at the reference cavity side.
Pumping again after 7 days at atmosphere.
BS, ITMY and OMC chambers were open only.
Checked: jam nuts, viewport covers and beam shutters.
Oplev servo turned off and medm screens shots taken.
New item in vacuum: green shade 14 glass beam block at IR-input [ from the PSL ] viewport to block green reflection-scatter.
Reminder: viewport is not AR coated for green!
IFO pressure 1.7E-4 Torr on new not logged cold cathode gauge. P1 <7E-4 Torr
Valve configuration: vac.normal with anunulossess closed off.
TP3 was turned off with a failing drypump. It will be replaced tomorrow.
The pressure on the newly installed gauge on the X arm was 6E-5 torr when I came in today evening, so I decided to start the recovery process.
Dry pump of TP3 replaced after 9.5 months of operation.[ 45 mTorr d3 ]
The annulosses are pumped.
Valve configuration: vac normal, IFO pressure 4.5E-5 Torr [1.6E-5 Torr d3 ] on new ITcc gauge, RGA is not installed yet.
Note how fast the pressure is dropping when the vent is short.
All time stamps are blank on the MEDM screens.
I worked on recovering ALS today. Alignments had drifted sufficiently that I had to to the alignment on the PSL table onto the green beat PDs for both arms. As things stand, both green (and IR) beats have been acquired, and the noise performance looks satisfactory (see Attachment #1), except that the X beat noise above 100Hz looks slightly high. I measured the OLTF of the X end green PDH loop (after having maximized the arm transmission, dither alignment etc, measurement done at error point with an excitation amplitude of 25mV), and adjusted the gain such that the UGF is ~10kHz (see Attachment #2).
Given that most of the post vent recovery tasks were done, and that the ALS noise performance looked good enough to try locking, we decided to try PRFPMI locking again last night. Here are the details:
PRM alignment, PRMI locking
Post the most recent vent, where we bypass the OMC altogether, we have a lot more light now at the AS port. It has not yet been quantified how much more, but from the changes that had to be made to the loop gain for a stable loop, we estimate we have 2-3 times more power at the AS port now.
Great to hear that we have the PRG of ~16 now!
Is this 150ppm an avg loss per mirror, or per arm?
The autolocker was acting up today, Gautam traced it to EPICS channels ( namely C1:IOO-MC_LOCK_ENABLE and C1:IOO-MC_AUTOLOCK_BEAT ) served by c1iool0 not being responsive and keyed the crate. This restored it nominal operation.
We may have a mouse in the lab. Do not leave any food scrap in trash ! Traps will be set.
I realized that I did not have a Finesse model to reflect the current situation of flipped folding mirrors (I've been looking at 'ideal' RC cavity lengths with folding mirrors oriented with HR side inside the cavity so we didn't have to worry about the substrate/AR surface losses), and it took me a while to put together a model for the current configuration. Of course this calculation does not need a Finesse model but I thought it would be useful nevertheless.
In summary - the model with which the attached plot was generated assumes the following:
This calculation agrees well with the analytic results Yutaro computed here - the slight difference is possibly due to assuming different losses in the RC folding mirrors.
The conclusion from this study seems to be that the arm loss is now in the 100-150ppm range (so each mirror has 50-75ppm loss). But these numbers are only so reliable, we need an independent loss measurement to verify. In fact, during last night's locking efforts, the arm transmission sometimes touched 400 (=> PRG ~22), which according to these plots suggest total arm losses of ~50ppm, which would mean each mirror has only 25ppm loss, which seems a bit hard to believe.
It is also difficult to have a high arm transmission without having high PRG.
What about to plot the arm trans and the REFL DC power in a timeseries?
Or even in a correlation plot (X: Arm Trans or PRG vs Y: REFL Reflectivity)
This tells you an approximate location of the critical coupling, and allows you to calibrate the PRG, hopefully.
As Gautam mentioned, we had some success locking the PRFPMI last night. (SRM satellite box is still in surgery...)
Unsurprisingly, changing the loss/PRG/CARM finesse means we had to fiddle with the common mode servo parameters a little bit to get things to work. However, before too long, we achieved a first lock on the order of a few minutes. Not long afterwards, we had a nice half hour lock stretch where we could tune up the AO crossover and loop UGFs. The working locking script was committed to SVN. Really, no fundamentally new tactics were used, which is encouraging. (One thing I wondered about was whether a narrower CARM linewidth would still let our direct ALS->REFL11 handoff with no offset reduction work. Turns out it does)
However, the step where we increase the analog CARM gain isn't as bulletproof as it once had been. The light levels "sputter" in and out sometimes if the gain increases are too agressive, and can cause a lockloss. Maybe this is an effect of the narrower linewidth and injecting more ALS noise at high frequencies with the higher CARM bandwidth.
The spatial profiles of the light on the cameras is totally bananas. Here's AS and REFL.
As Koji suggested, here is a 2D histogram of TRY vs REFLDC. It appears that the visibility would max out at 75% or so at arm powers around 400. Indeed, we briefly saw powers that high, but as can be seen on the plot, we were usually a little under 300. Exploring the transmon QPD offset space didn't seem to have much effect here.
One thing that I hadn't looked at in previous locks is coherence with our ground seismometers. It would be cool to have more seismic feedforward, and looking at the frequency domain multiple coherence, it looks like we can win a lot between 1 and 20 Hz. I expected more of a win at 1Hz, though.
Following Koji's suggestion, I decided to investigate the relation between my Finesse model and the measured data.
For easy reference, here is the loss plot again:
Sticking with the model, I used the freedom Finesse offers me to stick in photodiodes wherever I desire, to monitor the circulating power in the PRC directly, and also REFLDC. Note that REFLDC goes to 0 because I am using Finesse's amplitude detector at the carrier frequency for the 00 mode only.
Both the above plots essentially show the same information, except the X axis is different. So my model tells me that I should expect the point of critical coupling to be when the average arm loss is ~100ppm, corresponding to a PRG of ~17 as suggested by my model.
Eric has already put up a scatter plot, but I reproduce another from a fresh lock tonight. The data shown here corresponds to the IFO initially being in the 'buzzing' state where the arms are still under ALS control and we are turning up the REFL gain - then engaging the QPD ASC really takes us to high powers. The three regimes are visible in the data. I show here data sampled at 16 Hz, but the qualitative shape of the scatter does not change even with the full data. As an aside, today I saw the transmission hit ~425!
I have plotted the scatter between TRX and REFL DC, but if I were to plot the scatter between POP DC and REFL DC, the shape looks similar - specifically, there is an 'upturn' in the REFL DC values in an area similar to that seen in the above scatter plot. POP DC is a proxy for the PRG, and I confirmed that for the above dataset, there is a monotonic, linear relationship between TRX and POPDC, so I think it is legitimate to compare the plot on the RHS in the row directly above, to the plot from the Finesse model one row further up. In the data, REFL DC seems to hit a minimum around TRX=320. Assuming a PRM transmission of 5.5%, TRX of 320 corresponds to a PRG of 17.5, which is in the ballpark of the region the model tells us to expect it to be. Based on this, I conclude the following:
In other news, I wanted to try and do the sensing matrix measurements which we neglected to do yesterday. I turned on the notches in CARM, DARM, PRCL and MICH, and then tuned the LO amplitudes until I saw a peak in the error signal for that particular DOF with peak height a factor of >10 above the noise floor. The LO amplitudes I used are
There should be about 15 minutes of good data. More impressively, the lock tonight lasted 1 hour (see Attachment #6, unfortunately FB crashed in between). Last night we lost lock while trying to transition control to 1f signals and tonight, I believe a P.C. drive excursion of the kind we are used to seeing was responsible for the lockloss, so the PRFPMI seems pretty stable.
With regards to the step in the lock acquisition sequence where the REFL gain is turned up, I found in my (4) attempts tonight that I had most success when I adjusted the CARM A slider while turning up the REFL gain to offload the load on the CARM B servo. Of course, this may mean nothing...
I don't think the loss of 25 ppm is outrageous. Its just surprisingly good. The SIS model predicted numbers more like 1 ppm / mirror taking into account just the phase map and not the coating defects.
However, we should take into account the lossed in the DRMI to be more accurate: AR coating reflectivities, scatter loss on those surfaces, as well as possible clipping around BS or some other optics.
Quad rods and ionizer kit: consisting of repeller cage, anode grid, focus plate and filament were replaced....... under repair # RGA200/12 ECA 100416-12967
The electronic ECU is not connected. It is beeing pumped at IFO ITcc 9.7E-6 Torr vacNormal
The RGA is removed for repaire. It's volume at atmophere and sealed.. P4 reading of 38 Torr is not correct.
Salton See is shaking again.
I poked around a bit thinking about what we need for a single AS WFS.
New things that we would need:
Things we have:
We'd have 12 new signals to acquire: 4 quadrants x DC, I, Q. In principle the DC part could go into a slow channel, but we have the ADC space to do it fast, and it'll be easier than mucking around with c1iscaux or whatever.
Open question: What to do about AA? A quick search didn't turn up any eurocard AA chassis like the ones we use for the LSC PDs. However, given the digital AA that happens from 64kHz->16kHz in the IOP, we've talked about disabling/bypassing the analog AA for the LSC signals. Maybe we can do the same for the QPD signals? Or, modify the post-demod audioband amplifer in the demod chassis to have some simple, not too agressive lowpass.
installing the BLRMS 2k blocks turned out to be quite non-trivial due to a whole host of CDS issues that had to be debugged, but i've restored everything to a good state now, and the channels are being logged. detailed entry with all the changes to follow.
Building: Campus Wide
Date: Thursday 11/03/16 at Approx. 6:20 a.m.
Notification: Unplanned City Wide Power Glitch Affecting Campus
*This is to notify you that the Caltech Campus experienced a campus wide power glitch at approx. 6:20 a.m. this morning.
The city was contacted and they do not expect any further interruptions related to this event.
The vacuum was not effected. ITM sus damping restored. IFO room air conditions on.
PSL Innolight and ETMY Lightwave lasers turned on
I did the following:
There was a regular beat coming from the speakers. After muting all the channels on the mixer and pulling the 3.5mm cable out, the sound persisted. It now looks like the mixer is broken
A number of changes were made to C1PEM and some library parts. Recall that the motivation was to add BLRMS channels for all our suspension coils and shadow sensor PDs, which we are first testing out on the IMC mirrors.
Here is the summary:
BLRMS_2k library block
C1PEM model + filter channels
All the channels seem to exist, and FB seems to not be overloaded judging by the performance overnight up till the power outage. I will continue to monitor this...
GV Edit 3 Nov 2016 7pm:
I had meant to check the suitability of the filters used - there is a detailed account of the filters implemented in BLRMSFILTER.c here, and I quickly looked at the file on hand to make sure the BP filters made sense (see Attachment #1). These the BP filters are 8th order elliptical filters and the lowpass filters are16th order elliptical filters scaled for the appropriate frequency band, which are somewhat different from what we use on the seismometer BLRMS channels, where the filters are order 4, but I don't think we are significantly overloaded on the computational aspect, and the lowpass filters have sufficiently steep roll-off, these should be okay...
The projector failed just now with a pretty loud 'pop' sound - I've never been present when the lamp goes out, so I don't know if this is usual. I have left the power cable unplugged for now...
Replacement is ordered Nov 4
It seems that the EX and EY BLRMS banks were missing the BP and LP filters for the 0.03-0.1 and 0.1-0.3 bands. I've copied over the filters from the BS seismometer.
However, if it looks like the integrated C code BLRMS block works out well, we could replace the seismometers' filter module heavy BLRMS blocks and cut down on the PEM model bloat.
Here are the channels we are planning to switch over from c1auxex to Acromag, and their current pin numbers on the existing VME boards.
C1:SUS-ETMX_UL_AIOut #C0 S0
C1:SUS-ETMX_LL_AIOut #C0 S1
C1:SUS-ETMX_UR_AIOut #C0 S2
C1:SUS-ETMX_LR_AIOut #C0 S3
C1:SUS-ETMX_Side_AIOut #C0 S4
C1:SUS-ETMX_OL_SEG1 #C0 S5
C1:SUS-ETMX_OL_SEG2 #C0 S6
C1:SUS-ETMX_OL_SEG3 #C0 S7
C1:SUS-ETMX_OL_SEG4 #C0 S8
C1:SUS-ETMX_OL_X #C0 S9
C1:SUS-ETMX_OL_Y #C0 S10
C1:SUS-ETMX_OL_S #C0 S11
C1:SUS-ETMX_ULPD #C0 S12
C1:SUS-ETMX_LLPD #C0 S13
C1:SUS-ETMX_URPD #C0 S14
C1:SUS-ETMX_LRPD #C0 S15
C1:SUS-ETMX_SPD #C0 S16
C1:SUS-ETMX_ULV #C0 S17
C1:SUS-ETMX_LLV #C0 S18
C1:SUS-ETMX_URV #C0 S19
C1:SUS-ETMX_LRV #C0 S20
C1:SUS-ETMX_SideV #C0 S21
C1:SUS-ETMX_ULPD_MEAN #C0 S12
C1:SUS-ETMX_LLPD_MEAN #C0 S13
C1:SUS-ETMX_SDPD_MEAN #C0 S16
C1:ASC-QPDX_S1WhiteGain #C0 S0
C1:ASC-QPDX_S2WhiteGain #C0 S1
C1:ASC-QPDX_S3WhiteGain #C0 S2
C1:ASC-QPDX_S4WhiteGain #C0 S3
C1:SUS-ETMX_ULBiasAdj #C0 S4
C1:SUS-ETMX_LLBiasAdj #C0 S5
C1:SUS-ETMX_URBiasAdj #C0 S6
C1:SUS-ETMX_LRBiasAdj #C0 S7
C1:LSC-EX_GREENLASER_TEMP #C0 S0 This appears to have the same pin as another channel-- is it not being used?
C1:SUS-ETMX_UL_ENABLE #C0 S0
C1:SUS-ETMX_LL_ENABLE #C0 S1
C1:SUS-ETMX_UR_ENABLE #C0 S2
C1:SUS-ETMX_LR_ENABLE #C0 S3
C1:SUS-ETMX_SD_ENABLE #C0 S4
C1:ASC-QPDX_GainSwitch1 #C0 S7
C1:ASC-QPDX_GainSwitch2 #C0 S8
C1:ASC-QPDX_GainSwitch3 #C0 S9
C1:ASC-QPDX_GainSwitch4 #C0 S10
C1:AUX-GREEN_X_Shutter2 #C0 S15
We don't need to record any of the AIOut channels, the OL channels (since we record them fast), or the _MEAN channels (I think they must be CALC records or just bogus).
I just realized that Gautam set this test up and turned damping off......He will explane the details
Short summary of my Sat. Box. debugging activities over the last few days. Recall that the SRM Sat. Box has been plugged into the PRM suspension for a while now, while the SRM has just been hanging out with no electrical connections to its OSEMs.
As Steve mentioned, I had plugged in Ben's extremely useful tester box (I have added these to the 40m Electronics document sub-tree on the DCC) into the PRM Sat. Box and connected it to the CDS system over the weekend for observation. The problematic channel is LR. Judging by Steve's 2 day summary plots, LR looks fine. There is some unexplained behavior in the UR channel - but this is different from the glitchy behaviour we have seen in the LR channel in the past. Moreover, subsequent debugging activities did not suggest anything obviously wrong with this channel. So no changes were made to UR. I then pulled out the PRM sat.box for further diagnostics, and also, for comparison, the SRM sat. box which has been hooked up to the PRM suspension as we know this has been working without any issues.
Tracing out the voltages through the LED current driver circuit for the individual channels, and comparing the performance between PRM and SRM sat. boxes, I narrowed the problem down to a fault in either the LT1125CSW Quad Op-Amp IC or the LM6321M current driver IC in the LR channel. Specifically, I suspected the output of U3A (see Attachment #1) to be saturated, while all the other channels were fine. Looking at the spectrum at various points in the circuit with an SR785, I could not find significant difference between channels, or indeed, between the PRM/SRM boxes (up to 100kHz). So I decided to swap out both these ICs. Just replacing the OpAmp IC did not have any effect on the performance. But after swapping out the current buffer as well, the outputs of U3A and U11 matched those of the other channels. It is not clear to me what the mode of failure was, or if the problem is really fixed. I also checked to make sure that it was indeed the ICs that had failed, and not the various resistors/capacitors in the signal path. I have plugged in the PRM sat. box + tester box setup back into our CDS data acquisition for observation over a couple of days, but hopefully this does the job... I will update further details over the coming days.
I have restored control to PRM suspensions via the working SRM sat. box. The PRM Sat. Box and tester box are sitting near the BS/PRM chamber in the same configuration as Steve posted in his earlier elog for further diagnostics...
GV Edit 2230 hrs 7Nov2016: The signs from the last 6 hours has been good - see the attached minute trend plot. Usually, the glitches tend to show up in this sort of time frame. I am not quite ready to call the problem solved just yet, but I have restored the connections to the SRM suspension (the PRM and SRM Sat. Boxes are still switched). I've also briefly checked the SRM alignment, and am able to lock the DRMI, but the lock doesn't hold for more than a few seconds. I am leaving further investigations for tomorrow, let's see how the Sat. Box does overnight.
I've been trying to understand the green beat setup on the PSL table to see if I can explain the abysmal mode-matching of the arm and PSL green beams on the broadband beat PDs. My investigations suggest that the mode-matching is very sensitive to the position of one of the lenses in the arm green path. I will upload a sktech of the PSL beat setup along with some photos, but here is the quick summary.
Attachments #1 and 2: Simulated and measured beam profiles for the PSL and arm green beams. The origin is chosen such that both beams have travelled to the same coordinate when they arrive at the BBPD. The agreement between simulation and measurement is pretty good, suggesting that I have modelled the system reasonably well. The solid black line indicates the (approximate) location of the BBPD
Attachment #3: Mode matching efficiency as a function of shift of the above-mentioned fast lens. Currently, after my best efforts to align the arm and PSL green beams in the near and far fields before sending them to the BBPD results in a mode matching efficiency of ~30% - the corresponding coordinate in the simulation is not 0 because my length measurements are evidently not precise to the mm level. But clearly the mode matching efficiency is strongly sensitive to the position of this lens. Nevertheless, I believe that the conclusion that shifting the position of this lens by just 2.5mm from its optimal position degrades the theoretical maximum mode matching efficiency from >95% to 50% remains valid. I propose that we align the beams onto the BBPD in the near and far fields, and then shift this lens which is conveniently mounted on a translational stage, by a few mm to maximize the beat amplitude from the BBPDs.
Unrelated to this work: I also wish to shift the position of the PSL green shutter. Currently, it is located before the doubling oven. But the IR pickoff for the IR beat setup currently is located after the doubling oven, so when the PSL green shutter is closed, we don't have an IR beat. I wish to relocate the shutter to a position such that it being open or closed does not affect the IR beat setup. Eventually, we want to implement some kind of PID control to make the end laser frequencies track the PSL frequency continuously using the frequency counter setup, for which we need this change...
We're waiting on the last couple electrical components to arrive that are needed to complete the acromag chassis, but it is essentially operational. Right now it is connected to the PSL Mephisto's diagnostics port, for which only a single XT1221 A/D unit is needed. We assigned the IP address 192.168.113.121 to it. For the time being I'm running a tmux session on megatron (named "acromag") that grabs and broadcasts the epics channels, with Lydia's original channel definitions. Since the chassis is 4U tall, there's not really any place in the rack for it, so we might want to move it to the X-end before we start shuffling rack components around. Once we finalize its location we can proceed with adding the channels to the frames.
For the eventual gradual replacement of the slow machines, we need to put some thought into the connectors we want in the chassis. If we want to replicate the VME crate connectors we probably need to make our own PCB boards for them, as there don't seem to be panel-mount screw terminal blocks readily available for DIN 41612 connectors. Furthermore, if we want to add whitening/AA filters, the chassis may actually be large enough to accomodate them, and arranging things on the inside is quite flexible. There are a few things to be considered when moving forward, for example how many XT units we can practically fit in the chassis (space availability, heat generation, and power requirements) and thus how many channels/connectors we can support with each.
Steve: 1X3 has plenty of room
This is where the mammal came though. It is reach able from room 108 CES
Looks like the PRM Sat. Box is now okay, no evidence of the kind of glitchy behaviour we are used to seeing in any of the 5 channels.
We set up the chassis in 1X7 today. Steve is ordering a longer 25 pin cable to reach. Until then the PSL diagnostic channels will not be usable.
This is long overdue, but our burt files for SDF now live in the LIGO userapps SVN, as they should.
The canonical files live in places like /opt/rtcds/userapps/release/cds/c1/burtfiles/c1x01_safe.snap and are symlinked to files like /opt/rtcds/caltech/c1/target/c1x01/c1x01epics/burt/safe.snap
I tried to realize an improvement in the mode matching onto the BBPDs by moving the lens mentioned in the previous elog in this thread. My best efforts today yielded X and Y beats at amplitudes -15.9dBm (@37MHz) and -25.9dBm (@25MHz) respectively. The procedure I followed was roughly:
As per my earlier power budget, these numbers translate to a mode matching efficiency of ~53% for the X arm beat and ~58% for the Y arm beat, which is a far cry from the numbers promised by the a la mode simulation (~90% at the optimal point, I could not achieve this for either arm scanning the lens through a maximum of the beat amplitude). Looks like this is the best we can do without putting in any extra lenses. Still a marginal improvement from the previous state though...
I've been noticing over the last couple of days that the EPICS freezes are occurring more frequently again. Attached is an instance of StripTool traces flatlining. Not sure what has changed recently in terms of the network to cause the return of this problem... Also, they don't occur coincidentally on multiple workstations, but they do pop up in both pianosa and rossa.
Not sure if it is related, but we have had multiple slow machine crashes today as well. Specifically, I had to power cycle C1PSL, C1SUSAUX, C1AUX, C1AUXEX, C1IOOL0 at some point today
Now that we have all Satellite boxes working again, I've been working on trying to recover the DRMI 1f locking over the last couple of days, in preparation for getting back to DRFPMI locking. Given that the AS light levels have changed, I had to change the whitening gains on the AS55 and AS110 channels to take this into account. I found that I also had to tune a number of demod phases to get the lock going. I had some success with the locks tonight, but noticed that the lock would be lost when the MICH/SRCL boosts were triggered ON - when I turned off the triggering for these, the lock would hold for ~1min, but I couldn't get a loop shape measurement in tonight.
As an aside, we have noticed in the last couple of months glitchy behaviour in the ITMY UL shadow sensor PD output - qualitatively, these were similar to what was seen in the PRM sat. box, and since I was able to get that working again, I did a similar analysis on the ITMY sat. box today with the help of Ben's tester box. However, I found nothing obviously wrong, as I did for the PRM sat. box. Looking back at the trend, the glitchy behaviour seems to have stopped some days ago, the UL channel has been well behaved over the last week. Not sure what has changed, but we should keep an eye on this...
I took data of the ETMX SUSPOS, SUSPIT and SUSYAW channels while driving each of the 4 face coils. I manually turned off all the damping except the side.
Excitation: I used white noise bandpassed from 0.4 to 5 Hz in order to examine the responses around the resonance frequencies. To avoid ringing things up too much, I started with a very weak drive signal and gradually increased it until it seemed to have an effect on the mirror motion by looking at the oplev signals/sensor RMS values on the SUS screen; it's possible I'll need to do it again with a stronger signal if there's not enough coherence in the data.
Finding the matrix: The plan is to estimate the transfer function of the coil drive signal with the sensed degrees of freedom (specified by the already diagonalized input matrix). This transfer function can be averaged around the resonance peak for each dof to find the elements of the matrix that converts signals to dof responses, (the "response matrix", which is the inverse of the output matrix). Each column of the response matrix gets normalized so that the degrees of freedom influence the drive signals in the right ratio.