I started by checking if shaking an optic in pitch really moves it in pitch - i.e. how much PIT to YAW coupling is there. The motivation being if we aren't really dithering the optics in orthogonal DoFs, the demodulated error signals carry mixed information which the dither alignment servos get confused by. First, I checked with a low frequency dither (~4Hz) and looked at the green transmission on the video monitors. The spot seemed to respond reasonably orthogonally to both pitch and yaw excitations on either ITMY or ETMY. But looking at the Oplev control signal spectra, there seems to be a significant amount of cross coupling. ITMY YAW, ETMY PIT, and ETMY YAW have the peak in the orthogonal degree of freedom at the excitation frequency roughly 20% of the height of the DoF being driven. But for ITMY PIT, the peaks in the orthogonal DoFs are almost of equal height. This remains true even when I changed the excitation frequencies to the nominal dither alignment servo frequencies.
I then tried to see if I could get parts of the ASS working. I tried to manually align the ITM, ETM and TTs as best as I could. There are many "alignment references" - prior to the coil driver board removal, I had centered all Oplevs and also checked that both X and Y green beams had nominal transmission levels (~0.4 for GTRY, ~0.5 for GTRX). Then there are the Transmon QPDs. After trying various combinations, I was able to get good IR transmission, and reasonable GTRY.
Next, I tried running the ASS loops that use error signals demodulated at the ETM dither frequencies (so actuation is on the ITM and TT1 as per the current output matrix which I did not touch for tonight). This worked reasonably well - Attachment #1 shows that the servos were able to recover good IR transmission when various optics in the Y arm were disturbed. I used the same oscillator frequencies as in the existing burt snapshot. But the amplitudes were tweaked.
Unfortunately I had no luck enabling the servos that demodulate the ITM dithers.
The plan for daytime work tomorrow is to check the linearity of the error signals in response to static misalignment of some optics, and then optimize the elements of the output matrix.
I am uploading a .zip file with Sensoray screen-grabs of all the test-masses in their best aligned state from tonight (except ITMX face, which for some reason I can't grab).
And for good measure, the Oplev spot positions - Attachment #3.
While Gautam is working the restoration of Yarm ASS, I worked on Xarm.
[From yesterday] ASS for X arm was behaving slightly funny over the last couple of days. ASS could not correct the BS misalignment. Jenne pointed out that the LSC output matrix on the ASS medm screen set itself to zeroes whenever we ran the ASS_dither_ON script. I checked the burt request file: ASS_DITHER_ON.req in /opt/rtcds/caltech/c1/scripts/ASS and found that the LSC output matrix channels were not added to it. I added these channels for both the X and Y arm. Following this, I also edited the corresponding snap file as well. This should now set the LSC matrix to the right values everytime we run the script.
There are a lot of changes to the ASS stuff that have not been committed to the SVN:
controls@rossa:/opt/rtcds/userapps/release/isc/c1 0$ svn status | grep -v '?'
I noticed that the TRY button in the ASS main screen was linking to LSC_TRX instead of LSC_TRY. Gautam fixed it.
Koji pointed out that I was being silly, and rather than actually misaligning the optics (by, say, changing their IFO Align sliders) I was changing the location of the actuation node by changing the coil output gains. Now I see nice signals at the I_OUT of each of the demodulators (so far I've only looked at the YARM).
I've measured and inverted the matrix by taking the nominal values of the demodulator outputs when the optics are all by-hand optimally aligned, then one-by-one misaligning an optic's angle (pitch or yaw), and looking at the demod outputs that result. Repeat with each misalignment DoF for each of the 4 rows of the matrix. Then I set the pit/yaw coupling elements of the matrix to zero. Then invert the matrix, put it in, and see what happens. So far, the yaw DoFs converged to zero, but the pitch ones didn't. I'll play with it more and think some more tomorrow.
What we want from the light source for the AS port light injection:
We have four possible laser sources that we can use for the injection of 1064 nm from the back:
I think for maximum flexibility it's best to fiber-couple whichever source we choose on the PSL table and then just collimate it out of a fiber on the AS table. This way if we want to add fiber-coupled modulators of any kind it's a plug-and-play modification.
Different frequency control schemes are:
Either way we'll need a few things:
I'm working on how to best set this up at the AS port and interfere with normal operation as little as possible. Ideally we use a Faraday just like for squeezed light injection, but this requires some modification of the layout, although nothing that involves mode-matching.
We noticed last night that the yarm couldn't handle the old nominal gain for the ASS servos. We were able to run the ASS using about 0.3 in the overall gain. So, I have reduced the gain in each of the individual servos by a factor of 3, so that the scripts work, and can set the overall gain to 1.
I was looking a little at ASS, while Yuta was doing some Green transmitted DC PD work, and I find that the output of some filters is totally insane with no deliberate input or excitation signals.
Note in the figure that the filter (which is a 2nd order butter bandpass in the C1:ASS-LOCKIN29_SIG filter bank) is ringing a lot - this needs fixing. But, more disconcertingly, sometimes (not every time) the arm flashes, the input to the filter bank gets a ~1 sample long spike that is ~9,000,000 counts. 9 million is a lot of counts. This is then making the filter go crazy.
Any ideas on how this can happen, and how we can stop / fix it? It's certainly a CDS issue, but I'm not sure where or how.
[Sanjit, Jenne, Rob, Joe]
We added and tested the following channels from "/cvs/cds/gds/param/tpchn_C3.par" to "/cvs/cds/caltech/chans/daq/C1ASS.ini" appending a "_2048" extension to the channel name (as the name of a channel in .ini and .par files must be different):
These five-line entries for each channels in the .par file were manually copy pasted from the .ini file, should think about a smarter way...
The old .par file is kept as: /cvs/cds/caltech/chans/daq/C1ASS.ini.20Nov2009
The current one is also saved as: /cvs/cds/caltech/chans/daq/C1ASS.ini.24Nov2009
And, the current one is committed to the svn.
NOTE: In the first attempt, the channel names were mistakenly kept the same in both the .ini and .par files and this caused DAQ daemon to crash badly. It could only be recovered by hard reboot of the frame builder. Important info here: Jenne's elog 2316
ran the ON script several times and it kept pulling it away from good alignment, even when TRX was > 0.9.
Also, for what reason was this model run at 16 kHz?? Makes no sense to me to have a low frequency servo system run so high. Only makes for more digital precision noise, more CPU time, etc. Of course, running it at 2k would mean having to think about all of the AA filtering needed to go up/down from 2k to 16k.
I updated the medm C1ASS page for the Arm scripts:
ON : same as before
FREEZE OUTPUTS: calls new FREEZE_DITHER.py script, which sets Common Gain and LO Amplitudes to 0, therefore freezing the current output values
START FROM FROZEN OUTPUTS: calls new UNFREEZE_DITHER.py script, which sets Commong Gain and LO Amplitudes as in the DITHER_ASS_ON.py script, but no burt restore is performed
OFFLOAD OFFSETS: it's the old "SAVE OFFSETS", calls the WRITE_ASS_OFFSET.py script
OFF: same as before
StripTool: same as before
AS55Q and AS55I signals. AS55Q is around zero while AS55I has a large offset which is about the signal amplitude. It is likely because of the RAM?
At the lunch meeting, we were thinking about the exess high frequency content of the MICH control signal, which leads to railing against the FM output limiter and lock loss. I propsed that POPDC sensor/ADC noise was the culprit.
In short, I was wrong. Just now, I locked the PRMI with a MICH offset as we normally do, and then froze the POPDC output. The MICH spectrum did not change in any noticible way.
However, increasing the analog ASDC whitening gain showed a direct improvement of the error signal noise floor, and thus a reduction in the control signal spectrum. I.e. we have been suffereing from ASDC ADC noise.
We had previously set the ASDC whitening gain so that half fringe of the PRMI would be well within the ADC range, but since we're actually only ever going to 25%, I feel fine upping this gain. Interestingly, when increasing the whitening gain by 12dB, the control signal spectrum has fallen by more like 20 dB in the 400Hz-1kHz region, which is great.
The only potential hurdle I can think of is that when we start reducing the MICH offset at zero CARM offset, we may approach ADC saturation in ASDC before we can hand off to RF signals, in which case we would have to dynamically lower the whitening gain, which introduces offsets, which could get hairy. But, since MICH railing has been directly seen to lead to lock-loss, I'd rather solve that problem first.
The signal path for the ASDC signal is AS55 PD --> D990543 (interface board) --> D990694 (whitening board) --> D000076 (AA board) --> ADC Ch 31. Everything in this signal chain should be able to handle signals in the range +/- 10V, which should correspond to the full range of our +/-10V, 16bit ADCs. But the ASDC signal seems to saturate at ~2000 counts (i.e. turning up the analog whitening gain doesn't make the signal get any bigger than this). I investigated this a little more today.
So the problem lies somewhere downstream of the D990694. There are other anomalous behaviours of this channel - e.g. engaging the analog whitening filters changes the DC offset of the signal. I am going to pull out this board to check it out.
Why does this matter? I want to calibrate the ASDC level (and eventually the other PD DC signals as well) into Watts. This is useful for IFO diagnostics, noise budgeting the shot noise level etc.
According to the AS55 schematic, the DC transimpedance is 66.7 ohms. I claim that the DC power on the AS55 photodiode during a DRMI (no arms) lock is ~1mW. The C30642 photodiode (InGaAs) responsivity is ~0.8 A/W. So I'd expect ~50mV to be the signal level into the ADC (assuming gain of all the other electronics in the signal chain at the start of this elog is unity). This corresponds to ~163 counts (since the ADC conversion factor is 2^16 counts over 20volts). The DC signal level I observed is ~200 counts. So things seem roughly consistent.
*Note: Despite my above statement, I don't think it is true that the AS110 PD has more light on it - the BS splitting the light between
AS55 and AS110 PDs is a 50-50 BS, and using the crude method of putting an Ophir power meter in front of both PDs and
monitoring the power while the Michelson was swinging around freely showed roughly the same maximum value.
We played around tonight with different possible ways of transitioning DARM to normalized AS55Q. Before each try, we would use ezcaservo (or just eyeball it) to make sure that the normalized RF signals had a mean of zero, so that we knew we were pretty close to zero offset in both CARM and DARM.
We tried something that is similar in flavor to Kiwamu's self-locking technique - we summed in some normalized AS55Q to the DARM error point (using the DoF selector matrix that I created a few weeks ago), and then tried to engage a little low frequency boost. We tried several times, but we never successfully made the transition.
In the end, we just did a direct transition over to normalized AS55Q, and lost lock after several seconds. The buzzing that we hear didn't change noticeably after the transition, which indicates that most of the noise is due to CARM (which makes since, since it has a much smaller linewidth). The problem with holding DARM is that occassionally we will have a CARM fluctuation that lets the arm power dip too low, and DARM's error signal isn't valid at low arm powers. So, we need to work on getting CARM stabilized before we will have a hope of holding on to DARM.
Here's the lockloss plot from that last lock:
Also this evening, I scanned back and forth over the CARM zero crossing while locked on ALS, to see what the RF error signals looked like. Normalized REFL55 seems to have much more high frequency noise near the edges of the linear range than does REFL11. Also, the REFL 11 signal is much larger. So, what I think I want to try to do is use ALS fool to lower the CARM noise by a bit, then make the DARM transition. Then, we can come back to CARM and ramp up the gain.
With these CARM sweeps, I think that I know the relative gain and sign between ALScomm and the normalized REFL signals, and the REFL signals versus the normalized versions. I think that 100*REFL11I/(TRX+TRY) gives the same slope at the zero crossing as just plain REFL11I. Same factor of 100 is true for REFL55I. The REFL11 slope is 20,000 times larger than the ALS slope, while the REFL55 slope is -500 times the ALS slope (note that REFL55 has a minus sign). We can probably trigger the Fool on when the arm powers are above 50, and trigger off when they're below 20. For the zero crossings, the REFL55 threshold should be about 20, and the REFL11 threshold should be about 500.
I also need to re-think the triggering logic for ALSfool. We probably don't want the zero crossing logic to be able to un-trigger the lock, just in case we get an extra noise blip. So, we want to trigger on with an AND, but only trigger off if the arm powers go too low. Also, the zero crossing logic should look at the normalized error signals, not the plain signals.
We need to modify the ALSwatch logic so that it doesn't look at EPICS values for the thresholding. There may be an updated filter module that includes a saturation monitor, but otherwise we can use the saturation monitor part that is in the OSC section of CDS_PARTS. We'll set the threshold on this to match the limiter in the filter bank. Then, if the filterbank output is constantly hitting the limiter, we should run the down scripts.
I think we've seen this in simulations, but it's a little disheartening to see in real life. AS55Q looks like it flattens out pretty significantly right around the DARM=0 point.
Right now I have the arms held on ALS (CARM=-1*MC2, DARM=2*ETMY, as Q used last night), and the PRFPMI is on REFL165I&Q. I have set CARM to be as close to zero offset as I can (so I get all the usual buzzing), and then I'm sweeping the DARM offset between +3 and -3 counts (roughly +/-3nm) with a 3 second ramp and looking at normalized AS55Q. The channel called "DARM_B_ERR" is 0.006*AS55Q/(TRX + TRY). The arm transmissions, as well as the ASDC are plotted as well - ASDC is scaled to fit on the same axes as the transmissions.
Anyhow, here's the time series of the DARM sweeps. AS55 demod phase of -55 degrees seems to give the cleanest signal (within 5deg steps); this is the same phase that we've been using all week.
I measured the output voltage noise of the Q output of the AS55 Demod Board with the PSL shutter closed, using the SR785 (see Attachment #1). The measured noise is consistent with the expected number of ~120nV/rtHz around 100Hz. I had measured the gain of this board from RFPD input to Q output to be ~5.1: so if the PD dark noise is 16nV/rtHz, this would be amplified to ~80nV/rtHz. Still a discrepancy of ~50%. I didn't measure the noise with the PD input terminated. Added the noise of the demod board output with the RFPD input terminated. The level of ~100nV/rtHz seems consistent with the actual PD dark noise being ~80nV/rtHz, as their quadrature sum is around 130nV/rtHz. Need to dig up the schematics for the demod board + daughter board, and check against LISO, to see if this is consistent with what is expected.
Also - I think I was using the wrong value of the DC power on the AS55 photodiode for shot noise calculations - 13mW was for REFL55, not AS55. I did a crude measurement of the power by sticking the Ophir power meter (filter removed) in front of the AS55 PD with the Michelson flashing around, and noticed the maximum value registered was ~1.2mW. So in the DRMI lock, there would be ~2.4mW, which is 10x lower than the value I was assuming. I've made the correction in the NB code, for the next time the plot is generated. A more rigorous measurement would involve sticking the Ophir in front of the AS110 PD during a DRMI lock. The light from the AS port is split by a 50-50 BS to the AS55 and AS110 PDs (so measuring at AS110 is a reasonable proxy for power at AS55), and the AS110 signals are not used for triggering in the DRMI lock, so this is feasible.
how about calibrate the DC channels so that you can just get the acutal power levels from the trend data?
I keep adding traces to this plot, here is the most complete one I have now. Looks like the input noise to the D040179 (measured at "Q out" SMA jack of D990511 with RFPD input terminated) is ~10nV/rtHz. This supports the hypothesis that something is wonky on the daughter board, because the purple trace should only be the quad sum of the orange and green traces. I will pull it out and have a look.
Some other follow-ups on the questions raised at the meeting:
I tried replacing the AD797s on the daughter board with OP27s, and saw no significant improvement in the electronics noise of the demod board. Note that according to LISO, in this configuration, the voltage noise of the Op27 is expected to dominate the total noise of the daughter board. Measurement condition was that the RFPD input was terminated, but the LO input was still being driven (SR785 input range is -50dBVpk for all traces, and the input ranging was set to "UpOnly"). Need to do a more systematic investigation to figure out where this excess noise is coming from. I will upload photos of the board later.
This supports the hypothesis that something is wonky on the daughter board, because the purple trace should only be the quad sum of the orange and green traces. I will pull it out and have a look.
I worked on the daughter board a little more in the evening. I have somehow managed to make the dark noise ~25% worse [Attachment #1].
After making all these changes, I re-installed the card in the eurocrate and repeated the measurement. The Q channel noise was close to the expected value (~50nV/rtHz), but the I channel is twice as noisy. I will continue this investigation tomorrow.
Here is the marked up schematic with the board as it is stuffed. Annoyingly, there is a capacitor (C1) which according to the schematic is supposed to be open, but is stuffed in our board. I can't find any elog about this, and its a pain to measure the value of this capacitance. I will upload all of this + LISO + noise model/measurements to a 40m AS55 daughter board DCC page.
Attachment #1 - Measured / modelled noises for AS55 demod board. I've plotted quadrature sum of the LISO trace with the SR785 noise floor with input terminated to ground via 50ohm. Note that these measurements were made after all the changes in the marked up schematic in the previous elog were implemented.
Both channels should be identical - I don't understand why the I channels are noisier than their Q counterparts. This is almost certainly a problem on the daughter board, as the orange traces are pretty much identical for both channels.
The dark red curves were measured by shorting the inputs to D040179 to ground via 50ohms using some Pomona minigrabbers - I wanted to avoid ripping the daughter board out, but this probably explains the excess noise compared to the green trace at low frequencies. All other measurements were made with the board installed in the LSC rack eurocrate, with the LO input driven at the nominal level (I didn't measure this yesterday but a measurement from ~6months ago says that this level is 1.5dBm).
Koji suggested looking at the output of the AS55 demod board on a fast oscilloscope to look for differences in the two channel outputs (if there is some high-frequency oscillations, for example, we could miss this information in the SR785 spectra). Besides, I was only looking at spectra out to a few kHz on the SR785. I grabbed this data with a 300MHz BW Tektronix oscilloscope (battery mode) today. Input impedance of both channels were set to 1Mohm, and the measurement was made with the RFPD input terminated, output of the daughter board is what is measured. The vertical scaling of the channels was set to the minimum allowed, 1mV/div.
Attachment #1 shows that there is indeed a visible difference between the two channels - the (noisier) I channel has a much larger DC offset of ~5mV compared to the Q channel (I tried switching channels on the O'scope and the larger DC offset remained on the I channel, so seems real). There is also some kind of oscillation going on in the I channel, although the frequency is pretty low, with the peaks spaced ~50us apart. Indeed, in the ASD of the acquired data, the excess power in the I channel at 20kHz and higher harmonics are evident (see Attachment #2). Anyway all of this points to something being anomalous on the daughter board I channel signal path - I will pull it out and monitor the outputs at various points along the signal path with the fast scope to see if I can narrow down what's going on where.
We took a closer look at the AS55 demod board today. The procedure was to just be as thorough as possible, and check the behaviour of the circuit (both Transfer Function and Noise) stage by stage. Checking the transfer function was the key.
During this process, we found that the reason why the Q channels had lower noise than the I channels was because of the gain of the AD829 stage of the circuit was 0dB rather than 4dB (which is what it should be according to the component values used). Specifically, resistor R12, which is supposed to be 1.30kohm, was measured to be 1.03kohm. Replacing this resistor, the transfer functions (see Attachment #1) and noise levels (see Attachment #2) match the expectations from LISO. Some notes:
Assming the whitened ADC noise level is much below this (should only be ~10nV/rtHz), and given the measured sensing element of 6.2e8 V/m, this means that the dark noise sets a maximum achievable sensitivity of 2e-16m/rtHz.
To figure out what (if anything) is to be done next, we need to first figure out what is the goal. In the end, we care about DARM and not MICH. The optical gain for the former is ~300x the latter, so the dark noise contribution gets scaled by this factor (giving us a number of 7e-19 m/rtHz). There are certainly many noises above that level which have to be handled first. Indeed, looking at the DARM spectrum from DRFPMI lock back in March 2016, it looks like the current 1f DRMI (with coils de-whitened) Michelson sensitivity is within a factor of 2 of DARM in the full lock (albeit with vertex DoFs on 3f signals, and no coil de-whitening). Koji pointed out that we need to consider the photodiode resonant circuit itself too.
TODO: Upload all this onto the DCC
The gain of whitening filters on AS55 was decreased from 21 dB to 0 dB for the Y arm locking.
- - (Background)- -
Since the modulation depths became bigger from the past (#5462), the PDH signal from Y arm was saturated in the path of AS55.
Due to the saturation the lock of the Y arm became quite difficult so I decreased the gain of of the whitening filter from 21 dB to 0 dB.
In this condition, a required gain in C1:LSC-YARM_GAIN is about -0.3, which is 10 times bigger from the default number.
For the MICH locking tonight, it may need to be back to a big gain.
I temporarily replaced AS55 PD with PD labeled "POP55(POY55)".
I think POP55 is working because I could lock MI with this PD using AS55_Q_ERR as an error signal. I rotated I/Q phase (C1:LSC-AS55_PHASE_R) to 70 deg by minimizing ASDC during MI lock.
POP55 PD was freely sitting on the ITMX table.
I will leave AS55 PD at free space of the AP table. Someone, please look into it.
A new 90 deg splitter, PSCQ-2-51W, has been installed on another demod board called AS55.
It shows a reasonably close 90 degree separation between the I and Q signals at 55 MHz with various LO and RF power.
So far we have ordered only three PSCQ-2-51Ws for test. Now we will order some more for the other demodulators.
Some plots will be posted later.
I measured the transfer function, shot noise, and dark spectrum of AS55.
From the shot noise measurement, the RF transimpedance is (556.3 +- 0.8) Ohms and the dark current is (2.39 +- 0.01) mA. The dark noise agrees with the approximate value calculated from the circuit components.
There are no anomalous oscillations when there is no light on the photodiode. I am working on fitting the transfer function in LISO but the other plots are on the wiki at http://blue.ligo-wa.caltech.edu:8000/40m/Electronics/AS55
I finally did carry out a measurement on the network analyzer. This proves that the previous system will work properly. Just the optical splitter problem is to be taken care of.
For this, after Elog 10102, I did not touch any of the tables or photodiodes. Only turned on the laser at 1Y1 and took readings from the NA located nearby. I switched off the laser after measurements. The power to REF PD remains on.
I plotted transimpedence plots in the usual way and got ridiculous values of 15 ohms at 55MHz. Obviously there is the problem of varying amount of power illuminating the REF PD and AS55.
So, I just plotted the bode plots of transfer function got from the NA to check if the characteristics of AS55 looks as it was supposed to be and Yes! I got a nice peak at 55MHz.
1) Frequency sweep range: 1MHz to 100 MHz.
1) Frequency sweep range: 1MHz to 100 MHz.
2) Number of Points sampled in the range: 801
3) Type of sweep: Linear
The experimental values obtained were:
The experimental values obtained were:
DC output voltage of REF PD: 7.48V
DC output voltage of AS55: 53.7mV
Power incident on REF PD and AS55 respectively: 2.4mW and 1.6mW
Taking the DC transimpedence of AS55 as 66.2 ohms (from schematic given at D1300586-v1) and for REF PD as 1E04 ohms
Hence, Responsivity for REF PD and AS55 respectively are: 0.312 A/W and 0.51 A/W
The data and code used are in the zip file.
AS4 is set to go through a free swinging test at 10 pm tonight. We have used this script (Git/40m/scripts/SUS/InMatCalc/freeSwing.py) reliably in the past so we expect no issues, it has a error catching block to restore all changes at the end of the test or if something goes wrong.
To access the test, on allegra, type:
Then you can kill the script if required by Ctrl-C, it will restore all changes while exiting.
Came this morning, the gluing of the magnets was 100% successful. Side blocks, counterweights were assembled. We suspend AS4 and adjust the roll balance and the magnet height (attachments 1,2). OpLev was slightly realigned.
The pitch was balanced. We had to compensate for the pitch shift due to the locking of the counterweights. Once we got good pitch balance, the motion spectrum was taken (attachment 3). Major peaks are at 755mHz, 953mHz, 1040mHz.
Previous peaks were 755mHz, 964mHz, and 1.062Hz so not much has changed. We pushed back the OSEMs, adjusted OSEM plate and locked it tightly. We lock the EQ stops and transfer AS4 to the vacuum chamber in foil. We open the foil inside the chamber. No magnets were broken. Everything seems to be intact. We connect the OSEMs to CDS.
AS4 was succesfully suspended and trasported to ITMY chamber (40m/16589). We placed it near the door to make it easy to tune the OSEMs. We connected the OSEMs and found that the LL OSEM is not responding. Even though the the OSEMs are completely out right now, there was no signal on this OSEM. This could be an issue in either at the LED driver circuit or the PD circuit in AS4 Sat Amp box, or it could be the OSEM that is bad. We'll investigate further next day. For now, we recorded the full brightness reading for the OSEMs:
Another thing to note is that UL value above is not changing at all. I checked the CDS screen and the the ADC input is overflowing in complete bright position of the OSEM.
AS4 satellite amplifier D1002818 / D080276 troubleshoot
I dug into the circuit to see what/where things were wrong.
- UL saturation issue: The open light voltage at the TIA output (I-V out) was 10.4V. It seemed that the photocurrent of 86uA was simply a little too much for the transimpedance gain of 121kOhm. So the R18 was replaced to 100kOhm. This made the I-V out to be 8.6V and the ADC input count to be 28200 (Attachment 1). This modification was done on the unit S2100742 CH1 (LEFT CH1)
- Non responding LL issue: Now moved on to LL (LEFT CH2). The basic circuit test didn't reveal any problem. So the DSUB25 cables were swapped at the vacuum feedthru flange. The result is shown in Attachment 2. LL OSEM issue was moved to the 2nd ch of the right channel of the sat amp (CH6). This is means that the problem is somewhere in the vacuum chamber (including the vacuum feedthru). We need to check the in-vacuum cable and the OSEM. We can test the OSEM by swapping the position of the OSEM connector between LL and UL (for example).
Turns out, the shifting was likely due to the table level. Because I didn't take care the first time to "zero" the level of the table as I tuned the OSEMs, the installation was b o g u s. So today I took time to,
a) Shift AS4 close to the center of the table.
b) Use the clean level tool to pick a plane of reference. To do this, I iteratively placed two counterweights (from the ETMX flow bench) in two locations in the breadboard such that I nominally balanced the table under this configuration to zome reference plane z0. The counterweight placement is of course temporary, and as soon as we make further changes such as final placement of AS4 SOS, or installation of AS1, their positions will need to change to recover z=z0.
c) Install OSEMs until I was happy with the damping. ** Here, I noticed the new suspension screens had been misconfigured (probably c1sus2 rebooted and we don't have any BURT), so quickly restored the input and output matrices.
SUSPENSION STATUS UPDATED HERE
[Paco, Tega, Anchal]
Today, we started work on AS4 SOS by checking the OSEM and cable. Swapping the connection preserved the failure (no counts) so we swapped the long OSEM for a short one that we knew was working instead, and this solved the issue. We proceeded to swap in a "yellow label", long OSEM in place and then noticed the top plate had issues with the OSEM threads. We took out the bolt and inspected its thread, and even borrowed the screw from PR2 plate but saw the same effect. Even using a silver plated setscrew such as the SD OSEM one resulted in trouble... Then, we decided to not keep trying weird things, and took our sweet time to remove the UL, UR OSEMs, top earthquake stops, and top plate carefully in-situ. Then, we continued the surgery by installing a new top plate which we borrowed from the clean room (the only difference is the OSEM aperture barrels are teflon (?) rather than stainless. The operation was a success, and we moved on to OSEM installation.
After reaching a good place with the OSEM installation, where most sensors were at 50% brightness level and we were happy with the damping action (!!), we fixed all EQ stops and proceeded to push the SOS to its nominal placement. Then upong releasing the EQ stops, we found out that the sensor readings were shifted.
After the debacle with AS1 (40m/16580), we decided the put the PEEK earthquake stop by first removing the lower OSEM plate and then doing it. So I unfastened AS4 from its position with the earthquake stops in place and moved the suspension to the center of the table. Then I carefully removed the bottom OSEM plate. But I found out that the LR magnet is broken and lying on the floor of the suspension . Given my past on the same day, it could be me breaking it again during the moving of the suspension of taking off the OSEM plate or there is a small chance that this break happened before. Regardless of fault, this meant we have to resuspend AS4 again as well. So we transported AS4 back to the clean room and the work on it's re-suspension has begun.
The free swinging test was successful. I ran the input matrix diagonalization code (/opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/sus_diagonalization.py) on the AS4 free-swinging data collected last night. The logfile and results are stored in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/AS4 directory. Attachment 1 shows the power spectral density of the DOF basis data (POS, PIT, YAW, SIDE) before and after the diagonalization. Attachment 2 shows the fitted peaks.
The new matrix was loaded on AS4 input matrix and this resulted in no control loop oscillations at least. I'll compare the performance of the loops in future soon.
I think our suspension input matrix diagonalization is not so robust usually because we only choose a inverting matrix which gives the best separation for a single suspension alignment.
i.e. we have seen in the past that adjusting the bias for the alignment makes the matrix inversion not work well. Sometime people turn OFF the alignment bias before making the ringdown and that makes the whole measurement invalid.
This is because the sensitivity of the OSEMs to longitudinal and/or transverse motion is significantly different for different alignment.
I wonder if there's a way we can choose a better matrix by putting in random gain errors on the shadow sensor signals and then finding the matrix which gives the best diag under an ensemble of gain errors.
I agree. That's an interesting idea. But does that mean that there is an always working inverse matrix solution or that any solution will be vulnerable to the alignment biases.
I think we can also calculate the matrix rotation required as a function of dc biases and do that rotation in the simulimk model.
[Jenne / Kiwamu]
We have installed a broad band PD in the AS path in order to monitor the 110 MHz signal associated with the SRC.
The PD is currently connected to the POP110 demodulation board and it seems working fine.
I know this is confusing but right now the signal appears as "POP110" in the LSC front end model.
I worked on AS_11 today. Its ready for its noise / optical gain calibrations. I have left it on Suresh's desk.
This was one of the 24.5 MHz Black Box (Ben Abbott) style RFPDs rescued from LLO. The tunable inductor that was installed was too small to get the frequency down to 11 MHz and so I swapped in one of the shielded, ferrite core ones from our '7mm' CoilCraft kit. It had a range of 1.2 - 1.8 uH according to the datasheet.
I wasn't able to simulataneously get the peak at 11.06 MHz and the notch at 59.3 MHz and so I took Koji's advice and tuned the peak best. The plot above shows how the notch is slightly off. I think its not a problem; to get it better we would have to change out the inductor for the "2-omega" notch, but I was too lazy. The thinking is that its more important to have the gain be symmetric around the signal readout frequency so as to not imbalance the audio sidebands.
Since this one is going to be AS_11, we think that the 22 MHz signal will be tiny: the transmission of the 11 MHz sidebands to the dark port is small. If we later want to put in a 22 MHz notch anyway, there is space to do this via the 'active notch' pads around the MAX4107.
For the above plot, I used the Jenne laser. The DC output of the PD was ~30 mV (~0.6 mA). The RF drive to the laser was -10 dBm: no saturations. I have calibrated out the cable responses, but not using the 1811 setup, so the absolute calibration has yet to be done.
Also, it needs some new stickers. It would be handy if someone can figure out how to get some sheets of stickers that we can put into the printer. Then we can laser printer all of the data onto the stickers and stick them to the RFPD box.
AS1, PR2 and PR3 are set to o go through a free swinging test at 3 am. We have used this script (Git/40m/scripts/SUS/InMatCalc/freeSwing.py) reliably in the past so we expect no issues, it has a error catching block to restore all changes at the end of the test or if something goes wrong.
Today I suspended AS1. Anchal helped me with the initial hanging of the optics. Attachments 1,2 show the roll balance and side magnet height. Attachment 3 shows the motion spectra.
The major peaks are at 668mHz, 821mHz, 985mHz.
For some reason, I was not able to balance the pitch with 2 counterweights as I did with the rest of the thin optics (and AS1 before). Inserting the weights all the way was not enough to bring the reflection up to the iris aperture that was used for preliminary balancing. I was able to do so with a single counterweight (attachment 4). I'm afraid something is wrong here but couldn't find anything obvious. It is also worth noting that the yaw resonance 668mHz is different from the 755mHz we got in all the other optics. Maybe one or more of the wires are not clamped correctly on the side blocks?
The OSEMs were pushed into the OSEM plate and the plates were adjusted such that the magnets are at the center of the face OSEMs. The wires were clamped and cut from the winches. The SOS is ready for installation.
Also, I added a link to the OSEM assignments spreadsheet to the suspension wiki.
I uploaded some pictures of the PEEK EQ stops, both on the thick and thin optics, to the Google Photos account.
I was wondering whether I should take AS1 down to redo the wire clamping on the side blocks. I decided to take the OpLev spectrum again to be more certain. Attachments 1,2,3 show 3 spectra taken at different times.
They all show the same peaks 744mHz, 810mHz, 1Hz. So I think something went wrong with yesterday's measurement. I will not take AS1 down for now. We still need to apply some glue to the counterweight.