I've upgraded our cdsutils installation to v382; there have been some changes to pydv which will allow me to implement the auto y-scaling on our lockloss plots.
After some brief testing, things seem to still work...
For several MICH offsets, I measured the response of REFL33Q, ASDC and the ratio ASDC/POPDC to a MICH EXC. It appears that there is no frequency-dependent effect. The plots for MICH_OFFSET = 0.0 and 2.0 are slightly lower in magnitude: the reason is they were the first measurements done, and after that a little realignment of BS was necessary, so probably that is the reason.
In order to know where we should try to make the transition from REFL##Q to ASDC for MICH, I did a quick Optickle simulation to see what the error signals will look like.
The idea is to try to lock the PRMI on a single REFL diode (ex. REFL33 I&Q) with some MICH offset, and then transition over to ASDC. As soon as we have completed the transition, we can engage the normalization matrix to normalize ASDC by POPDC, and also increase the MICH offset if we want. Unfortunately, we do not as yet have the ability in our model to independently normalize different error signals, and then blend them, so we have to turn on the normalization after we've transitioned.
Here is the situation for PRMI-only:
You can see that REFL33Q has a slightly wider range than REFL165Q. It seems like we can perhaps try to make the transition around -15nm or so. Note that the error signals are not quite symmetric about 0nm, so we can use that to help determine what + and - mean. We expect that we need to add about 1nm offset to REFL33Q to get a true minimum in ASDC, so the sign of the digital offset that we need will tell us if there is a sign flip or not between the digital offset and this x-axis.
After we get this to work (hopefully in the next hour or so....), we will want to try the same thing with the arms held off resonance.
Usually we lock the PRMI at an offset of about 3nm:
However we could do it lower, perhaps around 1nm (which is where we currently are doing our CARM/DARM ALS->IR signals transitions):
At some point, we will arrive at 0nm CARM offset, when we'll want to transition back to RF signals (although probably we could jump straight to a 1f signal, not plotted):
The moral of the story here is that I'm not sure how we were ever successfully locking MICH on REFL165Q, unless my phase-setting in Optickle is way off. Certainly it looks like we should be sticking with REFL33 for PRFPMI. Also, since we have an offset in REFL33Q anyway (which we have seen and have commented on before), at 3nm CARM offset it looks like we could try to just do the jump without any extra digital offset. Here's a zoom of the 3nm situation:
We want to have some angular control of the arms during lock acquistion.
In single arm lock, Diego and I shook the TMs and measured how the QPDs responded. (I would've liked to do a swept sine in DTT, but the user envelope function still isnt' working!)
For now, we can close simple loops with QPD sensor and ITM actuator, but, as Rana pointed out to Diego and me today, this will drive some amount of the angular cavity degree of freedom that the QPD doesn't sense. So, ideally, we want to come up with the right combination of ITM and ETM motion that lies entirely within the DoF that the QPD senses.
I created a rudimentary loop for Yarm yaw, was able to get ~20Hz for the upper UGF, a few mHz for the lower, but it was starting to leak into the length error signal. Further tweaking will be neccesary...
A few hours ago I tweaked up the alignment to the PMC. It was really bad in pitch, and the transmission was down to about 0.711.
Before starting to move things around the PSL table, I measured the ALS out of loop noise for reference. The noise spectrum showed excess noise around 30Hz. The traces in blue were taken before I went in and those in red were taken after my work.
I also looked at the power spectrum of LSC-TRY_OUT to see if the noise is from the IR lock itself and there was nothing suspicious with it.
Since the green transmission was 50% lower than the usual, I touched the steering mirrors for green at the Y end table to get a better transmission and beat signal. The noise still hasn't disappeared.
I am not sure if this could be from our neigbors who have been running rock experiments since morning. We should check back to see if this noise disappears once they shut down.
DTT xml files are available in directory /users/manasa/data/150109/
I worked around the PSL table today.
The Y+PSL output from the optical fiber module for FOL was fed to the input of the Thorlabs FPD310.
200uW of incident light on the RFPD gave an RF signal of -70dBm as measured on a spectrum analyzer.
I swapped the beam splitter along the PSL path so that the incident power on the RFPD is ~1.5mW (Maximum incident power that the PD can tolerate is ~2mW).
This RF signal generated was - 43dBm which is still small for the input to the frequency counter module.
I checked this with a function generator and found that the frequency counter requires around -25 to -30 dBm at the input.
I plan to use the Minicircuits ZFL-1000ln that is on the IOO rack but not being used (This was used for green beatnote amplification but is not required/used anymore) to amplify the RF signal to the frequency counter.
If anyone has any objections to using this amplifier for the frequency counter, let me know.
100 and 10 days trends of ETMX and ETMY_SUSPIT. One can see clearly the earthquaks of Dec.30 and 31 on the 10 day plot. You can not see the two shakes M3.0 & M4.3 of Jan. 3
The long term plot looks OK , but the 10 day plot show the problem of ETMX as it was shaken 4 times.
The MEDM screen has been updated: the new buttons, one for each optic, call the scripts/general/SUS_DRIFTMON_update_reference.py script, which measures (and averages) for 30s the current values of the POS/PIT/YAW drifts, and then sets the average as the new reference value.
The restored offset script used old tdsavg calls that our workstations can't do, and didn't include things like the transmon QPDs. I've written yet another offset script that uses cdsutils averaging to do the thing, and committed to the svn.
Here's a summary of the changes made to the D990511 serial 115 (formerly known as REFL 33), as well as a short procedure. It needed tuning to 29.5MHz and also had some other issues that we found along the way.
So here's a picture of it as built:
The changes made are:
1. U11 and U12 changed from 5MHz LP to 10 MHz LP filters.
2. Resistors R8 and R9 moved from their PCB locations to between pins 1 (signal) and 3 (ground) of U11 and U12, respectively. These were put in the wrong place for proper termination so it made sense to shift them while I was already replacing the filters.
Also, please note- whoever labeled the voltages on this board needed an extra cup of coffee that day. There are two separate 15V power supplies, one converted from 24V, one directly supplied. The directly supplied one is labeled 15A. This does NOT mean 15 AMPS.
Equipment: 4395A, Signal generator (29.5 MHz), two splitters, one mixer
You can't take the TF from PD in to I/Q out directly. Since this is a demod board, there's a demodulating (downconverting) mixer in the I and Q PD in paths. Negligible signal will get through without some signal applied to the L input of the mixer. In theory, this signal could be at DC, but there are blocking capacitors in the LO in paths. Therefore, you have to upconvert the signal you're using to probe the board's behavior before it hits the board. Using the 4395A as a network analyzer, split the RF out. RFout1 goes to input R, RFout2 goes to the IF port of the mixer. Split the signal generator (SG). SG1 goes to LO in, SG2 goes to the L port of the mixer. The RF port of the mixer (your upconverted RFout2) goes to PD in, and the I/Q out goes back to the A/B port of the 4395A - at the same frequency as the input, thanks to the board's internal downconversion.
Equipment: Signal generator (29.5 MHz), signal generator (29.501 MHz), oscilloscope
Much simpler: 29.5 MHz to the LO input (0 dBm), 29.501 MHz to the PD input (0 dBm), compare the phases of the I/Q outputs on the oscilloscope. There are four variable capacitors in the circuit that are not on the DCC revision of the board - C28-31. On the LO path, C28 tunes the I phase, C30 tunes the Q phase. On the PD path, C29 and 31 appear to be purely decorative - both are in parallel with each other on the PD in Q path, I'm guessing C29 was supposed to be on the PD in I path. Fortunately, C28 and C30 had enough dynamic range to tune the I/Q phase difference to 90 degrees.
I've installed the very fresh ELOG 3.0, for nothing else than the new built in text editor which has a LATEX capable equation editor built right in.
Check out this sweet limerick:
[Jenne, EricQ, Rana]
Tonight we started prepping for an attempt at variable finesse locking.
The idea is to put in a MICH offset and hold the lock with ASDC/POPDC (so that the offset can be larger than if we were just using RF signals). This reduces the PRC buildup, which reduces / removes the double cavity resonance problems while reducing the CARM offset.
MICH locked on ASDC normalized by POPDC, PRM and ETMs (and SRM) all misaligned.
MICH offset of -20
MICH input = -0.04*ASDC normalized by 0.1*POPDC.
MICH gain = +5
MICH always triggered on (no triggering for DoF), but FM8 (CLP400) triggered to come on after lock (didn't write down the values).
PRMI locked with MICH on ASDC normalized by POPDC, PRCL on REFL33I, ETMs and SRM misaligned.
MICH offset of -10
PRCL input = 1*REFL33I
PRCL gain = -0.4 (factor ten times the regular value)
MICH always on, PRCL triggered on POP22. MICH FM8 and PRCL FM1,2,6,9 triggered on.
Gives POPDC of about 20 counts, POP22 of about 12 counts, ASDC of about 500 counts.
Arms held at 3nm, MICH locked on ASDC/POPDC, PRM and SRM misaligned.
Arms held at 3nm, attempt at PRMI lock with MICH on ASDC/POPDC.
Failed. Tried mostly same MICH gains as arms+mich, and PRCL at 10* normal gain.
Arms held at 3nm, PRMI locked with REFL 33 I&Q, attempt at transition to MICH on ASDC/POPDC.
Failed. At first, I was putting in the TF line at ~375Hz, but we looked at the full transfer function between 100Hz and 1kHz, and there was a weird dip near 300Hz from PRCL-MICH loop coupling. Here we were seeing that the phase between REFL33Q and ASDC was ~90 degrees. What?
Tried putting the TF line at ~100 Hz (since MICH UGF is in the few tens of Hz anyway, so 100 is still above that), but still get weird relative phase. Here it seems to be about 45 degrees when I inject a single line, although it didn't seem like a weird phase when we did the full swept sine earlier. Maybe I was just not doing something right at that point??
Anyhow, no matter what values I tried to put into the input matrix (starting with REFL33I&Q, trying to get MICH to ASDC/POPDC), I kept losing lock. This included trying to ramp up the MICH offset simultaneously with the matrix changing, which was meant to help with the PRCL gain change. Q has since given us MICH and PRCL UGF servos.
I added UGF servos for the DRMI DoFs, after creating a library block for the servos. I also deleted the FMs before the phase rotation, since we can just do it afterwards in other existing FMs. I've only added the MICH and PRCL buttons to the LSC screen because in the end, I feel like a dropdown is better, but I just wanted to get it running quickly tonight. The LSC model and the UGF block have been committed to the svn.
We were able to use the PRCL UGF servo successfully, as Jenne was exploring MICH offset space.
A few things that I have neglected to ELOG yet:
scripts/offsets/LSCoffsets is a new script that uses ezcaservo to set FM offsets of our LSC PDs. It still warns about large changes, and lets you revert. It reads the FM gain to pick the right gain for the ezcaservo call.
We never, ever want to use ezcaservo to do this. IN fact, we twice have already deleted scripts where people have implemented these (sometimes) unstable servos. Also, since this change had never been committed to the SVN, I just deleted it and updated from the SVN to get back the script that doesn't use any servos.
I'm going to periodically delete locking scripts that are not committed to the SVN since anyone who is too lazy to use the SVN probably can't write code worth using.
I have attached a photo of the ETMX table. The path of the 1064nm light rejected after the doubler and the green light are indicated for reference.
The fiber mount can only be mounted in the green space shown in the picture.
Calculating lens solutions for coupling the 1064nm light rejected after the doubler into the fiber, a lens of f=12.5cm should be placed at z=15.31cm (measured from the waist in the doubler crystal) gives the best ~80% coupling. This falls in the blue region where there is not enough space to mount a lens.
The region marked in orange has enough room for a lens; but the lens solutions give a coupling <10% which means there will be light scattering everywhere.
I am open to any suggestions on how to go about this.
I have added another block to the LSC screen (and made the corresponding sub-screen) to expose the analog settings for the DC photodiodes.
Note that we have 2 open channels there, which are still called something like "PD2" and "PD3" from olden times.
If we ever chose to use those, we will probably want to change their names, in /cvs/cds/caltech/target/c1iscaux2/LSC_aux2.db and /cvs/cds/caltech/target/c1iscaux/LSC_aux.db
Ophir power meter gets new filter with calibration. This is not cheap. It was the second time we lost it.
Filter leash is attached.
Some one already took off the filter and did not care to put it back on. This is carelessness!
Missing filter found. Labeled drawer OPHIR in control room - behind soldering station- with spare battery and filter
The SUS Drift Monitor screen has been updated:
Now that both end transmission QPDs have the line filters, I aligned them.
I locked and aligned the IR using the ASS, then went to each end table and put the beam in the center of the QPD.
I think the dolphin and RFM transit times are double-counted in this budget. As I understand it, all IPC transit times are already built in to the cycle time of the sending model. That is, the sending model is required to finish its computational work a little bit early, so there's time left to transmit data to the receivers before the start of the next cycle. Otherwise you get IPC errors. (This is why the LSC models at the sites can't use the last ~20 usec of their cycle without triggering IPC errors. They have to allow that much time for the RFM to get their control signals down the arms to the end stations.)
For instance, the delay measurement in elog 9881 (c1als to c1lsc via dolphin) shows only the c1lsc model's own 61 usec delay. If the dolphin transfer really took an additional cycle, you would expect 122 usec.
And in elog 10811 (c1scx to c1rfm to c1ass), the delay is 122 usec, not because the RFM itself adds delay, but because an extra model is traversed.
Bottom line: there may still be some DARM phase unaccounted for. And it would definitely help to bypass the c1rfm model, as suggested in 9881.
I was working around the PSL table this morning.
1. I have fibers running from the Y end and the PSL table to the Optical Fiber Module for Frequency Offset Locking.
Y+PSL out power is ~200uW. From the transimpedance and responsivity specs of the RFPD (ThorLabs FPD310), we expect ~100uW or -10dBm RF power. I have not hooked up the RF output to a spectrum analyser to confirm this as yet.
2. Also, Steve and I ran RF cables (LMR-195A) from the PSL table to the FC module on the IOO rack.
C1:SUS-ETMX_QPD is removed and internal SM1 thread adapter epoxied into position as it is at the Y end
This adapter will take FL1064-10 line filter holder
Line filter is attached and qpd needs alignment.
As Jenne mentioned, I created a model of the DARM OLG to see why we have so little phase margin. However, it turns out I can explain the phase after all.
Chris sent me his work for the aLIGO DARM phase budget, which I adapted for our situation. Here's a stacked-area plot that shows the contributions of various filters and delays on our phase margin, and a real measurement from a few days ago .
This isn't so great! Informed by Chris's model, the digital delays look like: (Here I'm only listing pure delays, not phase lags from filters)
This adds up to about 570usec, 20.5 degrees at 100Hz, largely due to the sheer number of computer hops the transmission loops involve.
As a check, I divided the measured OLG by my model OLG, to see if there is any shape to the residual, that my model doesn't explain. It looks like it fits pretty well. Plot:
So, unless we undertake a bunch of computer work, we can only improve our transmission loops through our control filter design.
Everything I used to generate these plots is attached.
As a warm-up after the holidays, before the real locking began, I installed 1064nm bandpass filters in front of the transmission QPDs to eliminate the stray green light that is there.
The Yend had threads epoxied to it, so that end should be good. Steve is going to repeat that for the Xend QPD at some point. Right now, the filter is just on a lens mount about 2cm away from the PD box aperture, since that's as close as I could get it.
Also, while I was at the Xend, I noticed that the transmission camera is gone. I assume that it was in the way of Manasa's fiber work, and that it'll get put back somehow, sometime. She elogged that she had removed it, but I mistakenly thought that it was already replaced. We don't use that camera much, so I'm not worried.
[Jenne, Diego, Rana]
This is a note about work done last night.
We were starting to lock, and saw glitches in the Thorlabs TRY PD about once every 1/60th of a second. It is not a sine wave, so it is not 60Hz line noise directly. It looks like this:
Rana pointed out that this looks like it could be from a power supply that is converting AC to DC.
We went down to the Yend, and noticed some weird symptoms. So far, we do not know where the noise is coming from. Rather, we are just using the QPD for locking.
* The noise comes and goes, particularly if someone is moving around at the end station.
* Moving the Thorlabs power supply farther from the HeNe power supply didn't do much. Turning off and disconnecting the HeNe supply didn't make the noise go away, so we conclude that it is not the HeNe's fault.
* We suspected the loops of excess cable that were sitting on top of iscey, but moving the coils away from the computer did not make the noise go away.
* We removed a few disconnected BNC cables that were near or touching the end table, but that didn't fix things.
* We disconnected the PD's signal cable and pulled it out of the table enclosure, and then put it back. Noise was gone when cable was disconnected (good), but it was back after plugging the cable back in.
* The noise still comes and goes, but we don't have to use the Thorlabs PD for locking, so we leave it for another day.
RXA: also moved the Thorlabs power supply to a different power strip and tried putting it closer/farther to the Uniblitz shutter controller. Another suspect is that its some PWM type noise from the doubler crystal temperature driver. Need to try turning off the heater and the Raspberry PI to if it effects the noise.
Today we began implementing the UGF Servos. Things we did:
One of the things that we had talked about last night was the totally tiny amount of phase margin that we have in the CARM and DARM loops. DARM seemed to be the most obnoxious loop last night, so I focused on that today, although the CARM and DARM loops are pretty much identical.
(Q tells me via email that the phase budget has the same ~14 degree discrepancy between what we expect and what we measure as his estimate last night. However, the Caltech network issues prevented his posting an elog.)
So, we definitely need to figure out where this 14 deg is going, but for now, I wanted to see if I could recover a couple of extra degrees just by modifying the filters.
The original filters do seem to eat a lot of phase:
The short version of the story is that I didn't leave the filters changed at all. I reverted back to the last version of the filter file from Monday night, so currently everything is as it was.
I tried increasing the Q of the zeros on the cyan and brown filters, which would sacrifice some gain at ~20 Hz, but hopefully win us 10+ degrees of phase. This gave me a dip of about a factor of 2 between the new and old filters (all servo filters combined added up to this factor of 2 in magnitude) between ~20Hz - 70Hz.
When we were locked using DARM for just the Yarm (for the UGF servo commissioning), I took a spectra of the error signal (which was POY) as a reference, then loaded in my new filters. For the most part, the spectra didn't change (which is good, since the magnitude of the filter didn't change much.). The spectra was bigger though between 50-70Hz, in kind of a sharp bandpass-looking shape that I wasn't expecting. I don't know exactly why that's happening.
Anyhow, we tried the new filters once or twice with the full IFO, but kept losing lock. Since I clearly haven't put in enough thought yet for these (particularly, how much suppression do we really need? what are our requirements???), I reverted back to the filter file from last night. We continued locking, and checking out the new UGF servo that Diego is elogging about.
We are working on trying out the UGF servos, and wanted to take loop measurements with and without the servo to prove that it is working as expected. However, it seems like new DTT is not following the envelopes that we are giving it.
If we uncheck the "user" box, then it uses the amplitude that is given on the excitation tab. But, if we check user and select envelope, the amplitude will always be whatever number is the first amplitude requested in the envelope. If we change the first amplitude in the envelope, DTT will use that number for the new amplitude, so it is reading that file, but not doing the whole envelope thing correctly.
Thoughts? Is this a bug in new DTT, or a pebkac issue?
Two plots from tonight:
Lock loss. Based on the fact that it looked like the DARM servo was running away, Rana posited an effective sign flip in the DARM loop, perhaps due to a parasitic angular feedback mechanism.
While Jenne was probing the IFO at lower powers, we noticed a sudden jump in ASDC. Found the GPS time and fed it to the lockloss plotter. Seems fairly evident that some sudden ETMX motion was to blame. (~2urad kick in yaw)
[Jenne, Rana, EricQ, Diego]
Tonight we worked on getting the IFO back in a working status after the break, and then tried some locking.
We left the IFO uncontrolled and in a "flashy" state so that tomorrow we can look into the "back-flashing to the MC" hypothesis.
I lost the connecting cable from the CM to the AO input (unlabeled).
This afternoon, I labelled both ends of this cable, and reconnected it to the MC servo board.
I upgraded the GDS and ROOT installations in /ligo/apps/ubuntu12 the control room workstations:
My cursory tests indicate that they seem to be working:
Now that the control room environment has become somewhat uniform at Ubuntu 12, I modified the /ligo/cdscfg/workstationrc.sh file to source the ubuntu12 configuration:
controls@nodus|apps > cat /ligo/cdscfg/workstationrc.sh
# CDS WORKSTATION ENVIRONMENT
This should make all the newer versions available everywhere on login.
Rana noted last week that TRX's value was stuck, not getting to the lsc from iscex. I tried restarting the individual models scx, lsc and even scy (since scy had an extra red rfm light), to no avail. I then did sudo shutdown -r now on iscex, and when it came back, the problem was gone. Also, I then did a diag reset which cleared all of the unusual red rfm lights.
Things seem fine now, ready to lock all the things.
The BS was showing some excess motion. I think I've fixed it. Order of operations:
I'm not sure how this might have gotten switched on...
* PMC + MC were unlocked when I came in.
* I fiddled around some more with the mcup/down scripts to make locking snappier. The locking was breaking the PMC lock often, so I re-enabled the MC servo board output limiter during acquisition. It is disabled in the MC UP script.
* Re-measured the MC OLG. Still OK.
* Measured the PZT / EOM crossover (aka the FAST / PC crossover) using the connectors on Koji's summing box. With the FAST gain at 18 dB, the crossover is ~10 kHz. Looks way to shallow. Plots to follow.
* I finally discovered today that the PMC PZT stroke is what's causing the main mis-alignment of the beam going to the IMC. By relocking at a few positions, I could see that the IOO QPDs have steps when the PMC relocks. So the IO beam wander is NOT due to temperature effects on the optics mounts of the PSL table. I wonder if we have a large amount of length to angle coupling or if this is the same as the OMC PZTs ?
P.S. I found that someone is using a temporary bench power supply to power the summing box between the TTFSS and the Thorlabs HV driver...whoever did this has ~48 hours to hook up the power in the right way or else Koji is going to find out and lose it and then you have to wear the Mickey Mouse hat.
The first attachment shows the OLG measurements with 2 different values of the fast gain (our nominal FG is 18 dB). You can see that the higher gains produce some crossover instability; when tuning the gain we notice this as an increase in the PCDRIVE rms channel.
The second attachment shows the measurement of the 'crossover'. Its really just the direct measurement of the IN1 / IN2 from the FAST summing box, so its the crossover measurement where the OLG is high.
All suspensions were tripped. Damping were restored. No obvious sign of damage. BS OSEM-UR may be sticking ?
For tuning the phase and amplitude of the mod. drive:
- since we don't have access to both RF phases, I just maximized the gain using the RF phase slider. First, I flipped the sign using the 'phase flip' button so that we would be near the linear range of the slider. Then I put the servo close to oscillation and adjusted the phase to maximize the height of the ~13 kHz body mode. For the amplitude, I just cranked the modulation depth until it started to show up as a reduction in the transmission by ~0.2%, then reduced it by a factor of ~3. That makes it ~5x larger than before.
I wonder if the variable bump around 100 kHz can be something about the NPRO and if the bump we see is the closed loop response due to the Noise Eater.
This plot (from the Mephisto manual) shows the effect of the NE on the RIN, but not the frequency noise. I assume its similar since the laser frequency noise above 10 kHz probably just comes from the pump diode noise.
I went out to the PSL and turned off the NE at ~4:53 PM local time today to see what happened. Although the overall PCDRIVE signal looks more ratty, there is no difference in the spectra of ON/OFF when the PCDRIVE is low. When its noisy, I see a tiny peak around 1 MHz with NE OFF. Turned it back on after a few hours.
Koji and I noticed that there was a comb* of peaks in the MC and FSS at harmonics of ~37 kHz. Today I saw that this shows up (at a much reduced level) even when the input to the MC board is disconnected.
It also shows up in the PMC. At nominal gains, there is just the 37 kHz peak. After tweaking up the phase shifter settings, I was able to get PMC servo to oscillate; it then makes a comb, but the actual oscillation fundamental is 1/3 of 37 kHz (some info on Jenne from elog 978 back in 2008).
Not sure what, if anything, we do about this. It is curious that the peak shows up in the MC with a different harmonic ratio than in the PMC. Any theories?
Anyway, after some screwing around with phase and amplitude of the RF modulation for the PMC from the phase shifter screen**, I think the gain is higher in the loop and it looks like the comb is gone from the MC spectrum.
Another clue I notice is that the PCDRIVE mad times often are coincident with DC shifts in the SLOWDC. Does this mean that its a flakiness with the laser? While watching the PCDRIVE output from the TTFSS interface board on a scope, I also looked at MIXER mon. It looks like many of the high noise events are associated with a broadband noise increase from ~50-140 kHz, rather than some specific lines. Don't know if this is characteristic of all of the noisy times though.
* this 'comb' had several peaks, but seem not be precise harmonics of each other: (f3 - 3*f1)/f3 ~ 0.1%
** I think we never optimized this after changing the ERA-5 this summer, so we'd better do it next.
We run out of N2 for the vacuum system. The pressure peaked at 1.3 mTorr with MC locked. V1 did not closed because the N2 pressure sensor failed.
We are back to vac normal. I will be here tomorrow to check on things.
ITMX damping restored.
In the plot it is shown the behaviour of the PSL-FSS_SLOWDC signal during the last week; the blue rectangle marks an approximate estimate of the time when the scripts were moved to megatron. Apart from the bad things that happened on Friday during the big crash, and the work ongoing since yesterday, it seems that something is not working well. The scripts on megatron are actually running, but I'll try and have a look at it.
I reset the threshold to +6666 counts (the aligned MC transmission is ~16000 for the TEM00 mode) so that it only turns on when we're in a good locked state.
I've updated the scripts for the MC auto locking. Due to some permissions issues or general SVN messiness, most of the scripts in there were not saved anywhere and so I've overwritten what we had before.
After all of the electronics changes from Monday/Tuesday, the lock acquisition had to be changed a lot. The MC seems to catch on the HOM more often. So I lowered a bunch of the gains so that its less likely to hold the HOM locks.
A very nice feature of the Autolocker running on megatron is that the whole 'mcup' sequence now runs very fast and as soon as it catches the TEM00, it gets to the final state in less than 2 seconds.
I've also increased the amplitude of the MC2 tickle from 100 to 300 counts to move it through more fringes and to break the HOM locks more often. Using the 2009 MC2 Calibration of 6 nm/count, this is 1.8 microns-peak @ 0.03 Hz, which seems like a reasonable excitation.
Using this the MC has relocked several times, so its a good start. We'll have to work on tuning the settings to make things a little spicier as we move ahead.
That directory is still in a conflicted state and I leave it to Eric/Diego to figure out what's going on in there. Seems like more fallout from the nodus upgrade:
controls@chiara|MC > svn up
svn: REPORT of '/svn/!svn/vcc/default': Could not read chunk size: Secure connection truncated (https://nodus.ligo.caltech.edu:30889)
Today we decided to continue to modify the TTFSS board.
The modified schematic can be found here: https://dcc.ligo.org/D1400426-v1 as part of the 40m electronics DCC Tree.
What we did
1) Modify input elliptic filter (L1, C3, C4, C5) to give zero and pole at 30 kHz and 300 kHz, respectively. L1 was replaced with a 1 kOhm resistor. C3 was replaced with 5600 pF. C4 and C5 were removed. So the expected locations of the zero and pole were at 28.4 kHz and 256 kHz, respectively. This lead filter replaces the Pomona box, and does so without causing the terrible resonance around 1 MHz.
2) Removed the notch filters for the PC and fast path. This was done by removing L2, L3, and C52.
At this point we tested the MC locking and measured the transfer function. We successfully turned up the UGF to 170kHz and two super-boosts on.
3) Now a peak at 1.7MHz was visible and probably causing noise. We decided to revert L2 and adjusted C50 to tune the notch filter in the PC path to suppress this possible PC resonance. Again the TF was measured. We confirmed that the peak at 1.7MHz is at -7dB and not causing an oscillation. The suppression of the peak is limited by the Q of the notch. Since its in a weird feedback loop, we're not sure how to make it deeper at the moment.
4) The connection from the MC board output now goes in through the switchable Test1 input, rather than the fixed 'IN1'. The high frequency gain of this input is now ~4x higher than it was. I'm not sure that the AD829 in the MC board can drive such a small load (125 Ohms + the ~20 Ohms ON resistance of the MAX333A) very well, so perhaps we ought to up the output resistor to ~100-200 Ohms?
Also, we modified the MC Servo board: mainly changed the corner frequencies of the Super Boost stages and some random cleanup and photo taking. I lost the connecting cable from the CM to the AO input (unlabeled).
I ssh'd in, and was able to run each script manually successfully. I ran the initctl commands, and they started up fine too.
We've seen this kind of behavior before, generally after reboots; see ELOGS 10247 and 10572.
So, despite having registered users, it turns out that the "Author" field is still open for editing when making posts. I.e. we don't really need to make new accounts for everyone.
Thus, I've made a user named "elog" with the old write password that can write to all ELOGs.
(Also, I've added a user called "jamie")