I opened up the spaghetti pot over the vertex seismometer, and taped the cable to the slab. The way the cable is coiled, it was touching the underside of the seismometer. Now the only connection is at the cable connector. There is a ~few inch bit of cable, then it's taped down.
We had persistent frustration by occasional unlock during ASSing.
Today, I added triggers to the servo gains in order to elliminate this annoyance.
Each ASS servo gain slider is multiplied with the corresponding LSC Trigger EPICS channel (i.e. C1:LSC-iARM_TRIG_MON, where i=X or Y).
This has been done by ezcaread modules in RCG.
The model and screen have been commited to svn.
Please remember that Xarm ASS needs FM6 (Bounce filters) to be ON in order to work properly.
c1lsc had 60 full-rate (16kS/s) channels to record. This yielded the LSC to FB connection to handle 4MB/s (mega-byte) data rate.
This was almost at the data rate limit of the CDS and we had frequent halt of the diagnostic systems (i.e. DTT and/or dataviewer)
Jenne and I reviewed DAQ channel list and decided to remove some channels. We also reviewed the recording rate of them
and reduced the rate of some channels. c1lsc model was rebuilt, re-installed, and restarted. FB was also restarted. These are running as they were.
The data rate is now reduyced to ~3MB nominal.
The following is the list of the channels removed from the DQ channels:
The following is the list of the channels with the new recording rate:
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.
[Diego, Jenne, Eric]
Tonight we kept on following our current strategy for locking the PRFPMI:
both of the last two locks, the most stable ones (one transition to usual REFL11 and one transition to "CM_SLOW" REFL11) were acquired actuating on MC2;
EDITs by JCD: At least one of the times that we lost PRMI lock (although kept CARM and DARM lock on ALS), was due to MICH hitting the rail, even after we increased the limiter to 15,000 counts.
Here is the transfer function between CARM ALS (CARM_IN1) and REFL11 coming through the CM board (CARM_B), just before we transitioned over. Coherence was taken simultaneously as usual, I just printed it to another sheet.
Here is the lockloss plot for the very last lockloss. This is the time that we were sitting on REFL11 coming through the CM_SLOW path. A DTT transfer function measurement was in progress (you can see the sine wave in the CARM input and output data), but I think we actually lost lock due to whatever this glitch was near the right side of the plots. This isn't something that I've seen in our lockloss plots before. I'm not sure if it's coming from REFL11, or the CM board, or something else. We know that the CM board gives glitches when we are changing gain settings, but that was not happening at this time.
Q: Here's the SR785 TF of CARM locked through CM board, but still only digital control; nothing exciting. Excitation amplitude was only 1mV, which explains the noisy profile.
I pulled out the RF amplifier box from the IOO rack again and added the new RF amplifiers for FOL.
I replaced one of the decoupling capacitors of the ALS beat note RF amplifier ; the poloproylene capacitor with a ceramic capacitor (0.1uF) .
After putting back the box, I confirmed that we had a beat note. I did not get a chance to measure the ALS noise after putting back the box because the IFO was already occupied.
I will post a detailed elog of the components in the RF amplifier box once I am done with it (hopefully tomorrow)!
I have removed REFLDC and the SR560 offsetter from the CM board IN2. Now, analog AS55 I lives there, for our single arm testing. (Analog I has more of the single arm Y PDH signal in it). REFL11 has been reconnected to IN1.
With ITMX super misaligned, Diego and I locked the Y-arm with the AO path on AS55, ultimately at 4kHz bandwidth, but with plenty of gain margin. We didn't allocate the gains too intelligently, and had the CM board input gain slider maxed out, but plenty of headroom in the digital and AO sliders, making it inconvenient to up the UGF even more, to engage the super boosts. However, since this is just a test case to make sure we still can AO lock, I'm not too worried about this.
Since LSC FMs and such had changed around, old recipies didn't neccesarily work 1:1. Diego is writing a script for the current recipe, and will post an elog with the steps.
Gains and signs are able to be tracked by loop TFs, the real sticking point is a stable crossover. We used the 1.6k:80 hardware filter in the CM board to give the AO Path a 1/f shape in the crossover region, and undid it digitally in the CM_SLOW input FM. However, we do use a 300:80 in the MC2 sus FM to make the digital loop like 1/f^2 around the crossover, once a little bit of AO has come in to pull up the digital loop's phase. We used the CARM filter bank to do this, so I think we should be able to use a similar technique to do it in the PRFPMI case, as long as the coupled cavity pole is around ~100Hz.
Attached are a few OLTFs from the progression.
The N2 pressure reading (C1:VAC-N2PRES) is now up-to-date after rebooting c1vac1.
The vaccum system is "Vacuum normal". We now have a space pressure transducer.
Our vacuum valves are manipulated with 60~75 PSI of nitrogen. All the valves are configured to be closed in the case of low N2 supply pressure.
In order to avoid this safety shutdown accidentally triggered, we have two N2 cylinders to sustain the vacuum valves. When one cylinder goes to low
the mechanical valve switches over to the other cylinder.
We have the monitor channel for this (combined) cylinder pressure. One shoulbe be able to see periodical pressure variation when the auto cylinder
switch is operating. However, the nirogen pressure reading got stuck at 66 PSI on Dec.16, 2014 (See attached 60-day plot of N2 supply pressure).
What we did
This morning we tracked down the cause of the trouble. We first closed the valves on EPICS and started to vary the N2 pressure.
Our first guess was the pressure transducer (Omega #236PC100GW) that was already 15 yrs old. We even has a sensor spare for replacement.
But it turned out that the direct voltage reading (to be 1mV/PSI) is changing correctly. The second guess was Omega Controller-Monitor
#DPiS32-C24 that is reading the voltage from the tranceducer. The display on this small black unit was changing corresponding to the
So our thought was
1) RS232C of the monitor unit is not working correctly
2) c1vac1 is not communicating with the monitor unit.
We wondered what could cause c1vac1 not communicating with the monitor unit, but we were afraid that some function got stuck
during either the nodus upgrade or chiara rebooting (or something else). So we decided to reboot c1vac1
In order to avoid any glitch in the main vacuum pressure, Steve disconnected some of the controller connectors for the closed valves.
We did this treatment before and it was successful.
Then c1vac1 was rebooted just by telnet and type reboot in the terminal.
Once the target is back in action, we noticed that the monitor value started to move.
Steve reverted the cables to the valves and operated the valves to recover "Vacuum Normal" state. Everything is now nicely settled.
Today (after centering the POP QPD), I measured the PRM to POP QPD transfer functions. I am suspicious that this was part of my problem last week. Since most of the angular noise is coming from the folding mirrors, but I can't actuate on them, I need to know (rather, the Wiener calculator needs to know) how actuating on the PRM will affect the spot at the POP QPD.
For the plots below, I have cut out any data points that have coherence less than 0.95. I may want to go back and fill in a little bit some of the areas (particularly around 3Hz) that I had trouble getting coherence in.
Using these to prefilter my witness data, I am failing to calculate a Wiener filter. I have tried the Levinson algorithm, as well as brute-forcing it, but I'm too close to singular for either to work. I am able to calculate a set of Wiener filters without the prefiltering, or with a dummy very simple prefilter, so it's not inherently in the calculators. Separately, I can plot my vectfit-ed actuator TFs, and I can convert them to a discrete fiilter with the bilinear transform, and then use sosfilt to filter some white noise data, which comes out with the shape I expect. So. It's not inherently the filters either. More work to do, when it's not 4am.
Here are the measured actuator transfer functions. They were measured as usual with DTT, but since the measurement kept getting interrupted (MC unlock, or I wanted to add more integrations or more cycles), these are several different DTT files stitched together. In both cases I am acuating PRM's ASC[pit, yaw] EXC point, and looking at the POP QPD.
Tonight we worked on the CM board and AO path:
The BLUE plot is at MC Gain = 0.10 and REFL1 Gain = 4dB; the GREEN plot is for MC Gain = 0.10 and REFL1 Gain = 3dB, which seemed a more stable configuration; after this last configuration, we increased the MC Gain to 0.15 and the AO Gain from 8dB to 9dB and took another measurement, the RED plot; this is as far as we got as of now. We also couldn't increase the REFL11 Gain because it made things unstable and more prone to unlock.
So, some little progress on the AO path procedure, but we are very low on our UGF and we have to find a way to increase our gains without breaking the lock and avoiding the gain peaking we have witnessed tonight.
We just changed the input to the CM board from REFL11 to AS55.
Today I was around the IOO rack.
I shutdown the power to the beat PDs on the PSL table and disconnected the D sub 3w3 connector that was powering the RF amplifier panel on the IOO rack.
I moved the RF amplifier from the panel to a box that can go on the rack. The box will also hold the RF amplifiers that will be used for FOL. I have not completed putting in all the amplifiers. But the RF amplifier for ALS is in place and the box has been installed on the IOO rack for locking tonight. The power supply to the green beat PDs has been switched ON.
I took the out of loop noise measurements for ALS X and Y and the attachment is the screenshot of it (X and Y have rms of ~300Hz and ~400Hz).
I had to touch the Y end steering mirrors for green to get maximum GTRY before making thes measurments.
After aligning the PRC, I centered the POP QPD.
Nothing earth-shattering today.
A few things of note:
See first plot below for the PRCL->CARM coupling just before lockloss. The second plot is the corresponding lockloss, where the PRCL loop is starting to see that oscillation again, and it's just barely starting to get into CARM.
SP table has been a mess because Q and I had let our SURF leave without cleaning up.
I cleaned up the SP table, put things back where they belong and did some sorting. I will put back the optomechanics where they belong sometime later.
For now, check out the SP table next time you are looking for a Y1 or lens or BS.
Tonight we continued following the plan of last night: perform the transition of CARM to REFL11_I while on MICH offset at -25%:
[Aside - How do you rotate plots in the new elog? It's showing them correctly in the attachments list below the entry, but not in the body of the log :( ]
I tried a round of PRCL ASC Wiener filtering today, but something wasn't right. I was able to either make the cavity motion worse, or completely throw the cavity out of lock. Making it less noisy didn't happen.
I took only 9 minutes of data the other day, since the PRMI didn't want to stay locked while it was daytime. So, this wasn't a whole lot to train on. But, even so, I designed some Wiener filters. The plots with the designs show the calculated Wiener filter ("Wiener") and the result from vectfit ("Fit"). Below the bode plot is the coherence between that witness (seismometer direction) and the degree of freedom (QPD channel). The fits were weighted by the choherence, so you can see that in the areas where the coherence was good, the fit was good. Elsewhere, it's not so great.
Using these filters, and assuming a Cheby1 2nd order lowpass filter at 30Hz, I predicted the following residuals:
After discovering that these filters didn't work, I went rogue and also put in a high pass filter at 0.1 Hz, but that didn't really change anything.
Here is a plot of what happened in Yaw. The Wiener filters' gains were all 0.3 here, which made the cavity motion larger, but not so large that it lost lock. The filters ought to have gains of 1 - the Wiener calculation should figure out the gains appropriately, if I've given it enough information. Here, as in the prediction plots above, red is the reference with the Wiener off, and black is with the Wiener filters on. Black is supposed to be below red, if the filters are working. Blue is the estimate of the angular motion that is being fed forward to the PRM, and you can see that at least the general shape is correct. I do need to figure out what the resonance in the blue trace is from - it's at the same frequency as a peak in the T-240's spectrum (that I didn't save). I suspect the cable might be touching the spaghetti pot on the inside, and making a mechanical short to pot vibrations.
Anyhow, more work to be done. I left the PRMI locked for a while this afternoon, starting at 5:15ish, so I'll see tomorrow how long of a lock stretch I was able to capture for training.
We cleared up some optics and optomechanics at the X end table that are not being used and moved them to the SP table. [Ed by KA: They seemed to be leftover of the other projects. I blame them]
Since there will be some work that supposedly will involve moving stuff on the table and racks; here is the updated to-do list for FOL.
Below is the set of plots comparing measurements for the green and IR beat notes frequencies. The measurements were made on the spectrum analyzer at the same time. So I have not taken measurement error into account.
From the plots, the discrepancy is not very large.
Shows the two sets of measurements scaterred along y=x.
Since plot 1 shows the points tightly scattered to y=x, I plotted the difference between the two measurements against their mean to blow out the deviations.
I will do the same comparison using the frequency counter readout once we have RF amplifiers installed.
It is certain that we have space issues at the X end that has been preventing us from sticking in a lens to couple light into the fiber.
The only way out is to install a platform on the table where we can mount the lens. I have attached the a photo of how things look like at the X end (attachment 1) and also a drawing of the platform that which can hold the lens (attachment 2). Additional support to the raised platform will be added depending on how much space we can clear up on the table by moving the clamping forks of the doubler.
Steve and I have been able to gather parts that can be put together into something similar to what is shown in the drawing.
Proposed modifications to the X end table:
1. The side panels of the table enclosure will come out while putting in the new platform.
2. The clamping forks for the doubling crystal will be moved.
Let me know of any concerns about the proposed solution.
The RF amplifier panel on the IOO rack (Attachment 1) will be used to also hold the RF amplfiers for the frequency counters. The amplifiers mounted on it right now are getting +15 (orange wire) and GND (black wire) from the rack power supply (Attachment 2).
Proposed plan to install RF amplifiers:
1. Disconnect the D sub connector that powers the amplifiers and pull out the panel. The rack power supplies will NOT be shut down for this.
2. Mount the RF amplifiers with bypass capacitors. There will be 4 amplifiers ZFL-500LN mounted on the same panel (2 for each frequency counter).
3. While putting back the panel on the IOO rack, we will need to shut down the +15V and -15V sources to connect the amplifiers to the rack power supply.
I will do this over this weekend so that we dont lose any locking time. If anybody has any concerns, let me know
Tonight, we transitioned CARM from ALS directly to REFL11 I at 25% Mich Offset.
We attempted the transition twice, the first time worked, but we lost lock ~5 seconds after full transition due to a sudden ~400Hz ringup (see attached lockloss plot). The second barfed halfway, I think because I forgot to remove the CARM B offset from the first time
The key to getting to zero CARM offset with CARM and DARM on ALS is ekeing out every bit of PRMI phase margin that you can. Neither MICH nor PRCL had their RG filters on and I tweaked the MICH LP to attenuate less and give back more phase (the HF still isn't the dominant RMS source.) PRCL had ~60 degrees phase margin at 100Hz UGF, MICH had ~50 deg at 47Hz UGF. The error signals were comparitively very noisy, but we only cared that they held on. Also important was approaching zero slooooooooowly, and having the CARM and DARM UGF servo excitations off, because they made everything go nuts. Diego stewarded the MICH and PRCL excitation amplitudes admirably.
Oddly, and worringly, the arm powers at zero CARM offset were only around 10-12. Our previous estimations already include the high Xarm loss, so I'm not sure what's going on with this. Maybe we need to measure our recycling gain?
I hooked up the SR785 by the LSC rack to the CM board after the first success. For the second trial, I also took TFs with respect to CM slow, but they looked nowhere near as clean as the normal REFL11 I channel; I didn't really check all the connections. I will be revisiting the whole AO situation soon.
In any case, I think we're getting close...
X-Arm ASS was fixed.
ASS_DITHER_ON.snap was updated so that the new setting can be loaded from the ASS screen.
The input and output matrices and the servo gains were adjusted as found in the attached image.
The output matrix was adjusted by looking at the static response of the error signals when a DC offset
was applied to each actuator.
The servo was tested with misalignment of the ITM, ETM, and BS. In fact, the servo restored transmission
from 0.15 to 1.
The resulting contrast after ASSing was ~99% level. (I forgot to record the measurement but the dark fringe level of ASDC was 4~5count.)
The X-end IR Trans path was cleaned up.
I have been investigating the Xarm ASS issue. The Xarm ASS sensors behaved not so straight forward.
I went to the X-end table and found some suspect of clipping and large misalignmnet in the IR trans path.
Facing with the usual chaos of the end table, I decided to clean-up the IR trans path.
The optical layout is now slightly better. But the table is, in general, still dirty with bunch of stray optics,
loose cables and fibers. We need more effort to make the table maintained in a professional manner.
- Removed unnecessary snaking optical path. Now the beam from the 1064/532 separator is divided by a 50-50 BS before the QPD without
any other steering mirrors. This means the spot size on the QPD was changed as well as the alignment. The spot on the QPD was aligned
with the arm aligned with the current (=not modified) ASS. This should be the right procedure as the spot must be centered on the end mirror
with the current ASS.
- After the 50-50 BS there is an HR steering mirror for the Thorlab PD.
- A VIS rejection filter was placed before the 50-50 BS. The reflection from the filter is blocked with a razor blade dump.
Important note to everyone including Steve:
The transmission of the VIS rejection filter at 1064nm is SUPER angular sensitive.
A slight tilt causes significant reduction of 1064nm light. Be careful.
- As we don't need double VIS filter, I removed the filter on the QPD.
- X-End QPD was inspected. There seemed large (+/-10%) gain difference between the segments.
They were corrected so that the values are matched when the beam is only on one segment.
The corrections were applied at C1:SUS-ETMX_QPDx_GAIN (x=1, 2, 3, or 4).
I decided to put "-20dB" filters on C1:SUS-ETMi_QPD_SUM and C1:SUS-ETMi_TRY (i = X or Y)
in order to make their gain to be reasonable (like 0.123 instead 0.000123 which is unreadable).
Jenne's normalization script reads relative values and the current gains instead of the absolute values.
Therefore the script is not affected.
PMC Trans increased from 0.740 to 0.782
IMC Trans increased from 16200 to 17100
Why AS55/(TRX + TRY) instead of just TRX? Isn't (TRX+TRY) controlled by CARM?
(question is secretly from Kiwamu)
I have just put the seismometers back into their nominal positions, on the concreted slabs. The T-240 is in the vertex, and the 2 Guralps are at the end stations.
The vertex location doesn't have a spaghetti pot right now. There is an aluminum support for cable trays that is welded to the supports under the beam tube that is in the way. The pot looks like it will fit barely, if it were slid totally horizontally into place. However we can't do that with the seismometer in place. I'll chat with Steve this afternoon about our options.
Since I don't know that we are planning on ever putting a cable tray on the inside of the beamtube, perhaps we can cut ~6 inches of this piece away.
Aluminum support beam removed and seismometer is covered.
Tonight we were able to transition DARM from DC transmission signals to AS55Q/(TRX+TRY). That's about as far as we've gotten though.
Here are the details:
The carm_cm_up script now should get all the way to this point by itself, although occasionally the PRMI part will lose lock (but not the arms), so you have to go back to the 3nm CARM offset and relock the central part. I have written a little "relockPRMI.sh" script that lives in ..../scripts/PRFPMI/ that will take care of this for you.
We were able to transition DARM to AS55Q a total of 3 or so times tonight. The first time was with the + MICH gain, and the rest of the times were with - MICH gain. The carm_up script now asks for a sign for the MICH gain just after asking for a CARM offset sign.
I think that we understand all of our locklosses from these states. Twice (including the time described above) the UGF lines got lost in the noise, and the UGF servos went crazy. Once the PRCL loop rang up, because a filter that wasn't supposed to be on was on. This was a terrible filter that I had made a long time ago, and was never supposed to be part of the locking sequence, but it was getting turned on by a restore script, and kept eating our phase. Anyhow, I have deleted this terrible boost filter so it won't happen again (it was called "boost test", which may give you an idea of how non-confident I was in its readiness for prime-time). The last time of the night I must not have been quite close enough in CARM offset, so we should probably check with a TF before making this last jump.
Diego wrote a nifty burt restoring script that will clear out all the elements of the input matrix and the normalization matrix for a row that you tell it (i.e. DARM_A will clear out all the elements in the first row of those 2 matrices). This is useful for the switches back and forth between the _A and _B signals, to make sure that everything is in order. So, I now run those clear scripts, then put in the elements that I want for the next step. For example, DARM initially locks with ALS using the A row. Then, DARM transitions to the B row for DC transmission. Then, I prepare the A row for AS55Q locking, and I don't want any elements accidentally left from the ALS signal. It lives in ..../scripts/LSC/InputMatrix/
Thoughts for tomorrow:
Daytime re-commission the Xarm ASS.
Nighttime try to get back to DARM on AS55Q and push farther forward.
I checked the situation of ASS. I wanted to know how much we are away from the maximum transmittion.
ASS makes the X arm shifted from the maximum transmission. This causes the contrast degraded by ~3%.
We need to fix the Xarm ASS so that it can maximize the transmission and ignor the spot centering at ITMX.
Conditioning before the measurement:
- ASDC offset was removed
- X&Y arm was aligned by ASS
Average transmission: 0.86
Pmax = 1045 +/- 9 cnts
Pmin = 22 +/- 4 cnts
==> Contrast = (Pmax - Pmin)/(Pmax+Pmin) = 0.960+/-0.007
After manual alignment of the X arm (ignoring spot centering):
Average transmission: 0.88
Pmax = 1103 +/- 11 cnts
Pmin = 5 +/- 1 cnts
==> Contrast = (Pmax - Pmin)/(Pmax+Pmin) = 0.991+/-0.002
Welcome to your new abode, Donatella!
The UGF Servo medm page has been updated to reflect the last changes, namely the return of the sum of squares and the disappearance of Test3.
PRMI is locked on sideband, starting ~4 minutes ago, to collect ASC/seismic data for feedforward.
[Jenne, Diego, EricQ]
We did a series of small things that may have helped with the locking, although we didn't actually get anywhere closer in CARM offset.
I had a look at the OAF model today.
Somehow, the screens that we had weren't matching up with the model. It was as if the screens were a few versions old. Anyhow, I found the correct screens in /userapps/oaf/common/medm, and copied them into the proper place for us, /userapps/isc/c1/medm/c1oaf. Now the screens seem all good.
I also added 2 PCIE links between the OAF and the SUS models. I want to be able to send signals to the PRM's pitch and yaw. I compiled and restarted both the oaf model and the sus model.
The OAF model isn't running right now (it's got the NO SYNC error), but since it's not something that we need for tonight, I'll fix it in the morning.
My thought for trying out the OAF is to look at the coherence between seismic motion and the POP DC QPD when the PRMI is locked (no arms). I assume that the PRM is already handled in terms of angular damping (local and oplev), so the motion will be primarily from the folding mirrors. Then, if I can feedforward the seismometer signal to the PRM to compensate for the folding mirrors' motion, I can use the DC QPD as a monitor to make sure it's working when we're PRMI-only locked, or at low recycling gain with the arms. But, since I'm not actually using the QPD signal, this will be independent of the arm power increase, so should just keep working.
Anyhow, that's what my game plan is tomorrow for FF. Right now the T-240 is settling out from its move today, and the auto-zero after the move.
The MC autolocker hasn't been so snappy recently, and has been especially fussy today. Previously, the mcup script was triggered immediately once the transmission was above a certain threshold. However, this could waste time if it was just an errant flash. Hence, I've added a 0.5 second delay and a second threshold check before mcup is triggered.
After breaking the lock 5ish times, it does seem to come back quicker.
A small change, but now the carm_up script supports both sides of the CARM offset. After the arms are locked with ALS it asks for a "+" or a "-", which indicates which sign of digital CARM offset will be added. In the past, we have been primarily using the "+" sign.
So, I neglected to elog this yesterday, but yesterday we had one of those EPICS freezes that only affects slow channels that come from the fast computers. It lasted for about 5 minutes.
Right now, we're in the middle of another - it's been about 7 minutes so far.
Why are these happening again? I thought we had fixed whatever was the issue.
EDIT: And, it's over after a total of about 8 minutes.
Does netgpibdata/TFSR785 work at the 40m currently?
It does appear to work here. However, I've since supplanted TFSR785 and SPSR785 with SRmeasure, which has some simpler command line options for directly downloading a manually configured measurement. I've also set up a git repository for the gpib scripts I've done at https://github.com/e-q/netgpibdata, which could be easier than grabbing the whole 40m directory.
Does netgpibdata/TFSR785 work at the 40m currently? I rsynced the netgpibdata directory to LHO this morning to do some measurements, but I had to modify a few lines in order to get it to call the SR785 functions properly. My version is attached.
ETMX YAW stopped drifting Jan 8, 2015
I made little scripts to go with the sus driftmon buttons, that will servo the alignment sliders until the susyaw and suspit values match the references on the driftmon screen.
One of tonight's goals was to tweak the CARM filters, so that we could engage the lowpass filter, to avoid the detuned double cavity pole resonance disturbing the CARM loop.
I increased the Q of the zeros in the FM3 boost so that it eats fewer than the original 18 degrees of phase at 100 Hz. We kept losing lock though, so for each lock I backed off on the Q a little bit. In the end, the filter eats 9 degrees of phase at 100 Hz. I also moved the lowpass from 700 Hz to 1kHz, although that doesn't change the phase at 100 Hz very much.
We modified the carm_up script re: PRMI locking a little bit. The PRMI is not so enthusiastic about locking immediately at 25% MICH fringe, so I backed that off. It now acquires lock at a few percent, and then ramps up the offset. Also, the MICH FM6 bounce roll filter is now turned on after lock is acquired, effectively giving it an extra second or two of delay beyond the rest of the filters.
We were able several times to get to some MICH offset and turn on the lowpass filter, but starting to reduce the CARM offset makes us lose lock. I think the problem is that the UGF servo demod phase is changing as we are changing offsets, filters and error signals. We see that the I-phase is servoed successfully to 0dB, but that the Q-phase is starting to move around by 30 degrees or more. We either need to monitor this much more closely, and add the changing demod phases to the carm_up script, or we need to go back to the sum-of-squares situation that we had last week. Note that we saw failures with that method for a completely separate reason: we were getting too close to the limiters, which cause the UGF servos to glitch and the outputs jump by a significant amount. So, the issues that we were seeing last week when we had the sum-of-squares were a different thing, that we noticed and understood later.
Anyhow, nothing too exciting and glorious tonight, but progress has been made.
Also, from some Mist simulations that Q did, Diego made a sweet plot that is now posted in the control room, so we can translate arm power to CARM offset, at various MICH offsets.
We also took some CARM loop measurements with the new filters. We have a little more phase than we used to, which is nice. These traces don't have the lowpass engaged, since I was trying to see how far we could get without it. We lost lock right after the second measurement, but I think that was to do with the UGF servos.
We centered the OpLevs for ITMX and ITMY.
I've been looking into the data of Jan 06 and Jan 15 taken during daytime, as the night before we left the PRC aligned in order to allow the IFO to flash; the purpose is to find out if some flashes from the IFO could propagate back to the IMC and cause it to lose lock; I will show here a sample plot, all of the others are in the archive attached.
My impression is that these locklosses of the IMC are not caused by these flashes: the signals MC_[F/L] seem quite stable until the lock loss, and I don't see any correlation with what happens to REFLDC that could cause the lockloss (apart from its drop as a consequence of the lockloss itself); in addition, in most occasions I noticed that the FSS started to go crazy just before the lock loss, and that suggests me that the lockloss source is internal to the IMC.
I can't see anything strange happen to MC_TRANS either as long as the IMC is locked, no fluctuations or weird behaviour. I also plotted the MC_REFL_SUM channel. but it is too slow to be useful for this kind of "hunt".
I measured the bounce/roll frequencies for all the optics, and updated the Mechanical Resonances wiki page accordingly.
I put the DTT templates I used in the /users/Templates/DTT_BounceRoll folder; I wrote a python script which takes the exported ASCII data from such templates and does all the rest; the only tricky part is to remember to export the channel data in the order "UL UR LL" for each optic; the ordering of the optics in a single template export is not important, as long as you remember it...
Anyhow, the script is documented and the only things that may need to be modified are:
The script is in scripts/SUS/BR_freq_finder.py and in the SVN. I attach the plots I made with this method.
Tonight we worked on the acquisition sequence (including re-re-re-commissioning the UGF servos, hopefully for the last time...) for the PRFPMI with large MICH offsets.
The procedure is all in the carm_up script, as far as things work.
We had some locklosses, but they were mostly due to non-carefulness on my part during the transitions between error signals, or the UGF servos getting upset because the oscillator peaks had gotten lost in the noise. The one that I show here is our very last one of the night, where we are hitting the rails for the MICH signal, which is then causing the other loops to have to do weird things to try to compensate, and they lose lock.
Here also is a StripTool shot during that lock stretch. I was in the middle of increasing the MICH offset to 75% of the fringe. The yellow trace (called MICH_B_MON) is ASDC/POPDC normalized so that it always goes 0-1. I was pleased to see that perhaps REFL11I and AS55Q are turning over, although as Q will tell us in a more detailed elog tomorrow, having a large MICH offset does weird things and moves the DARM zero-point. So, maybe we aren't actually anywhere awesome yet.
After some MICH offset, the maximum arm power is always going to be about 50, so arm powers of 8 or 10 equates to 100 pm. We didn't get there tonight while on IR signals.
The locking sequence is now something like this:
After this, we tried a few times to lower the CARM offset, but kept losing lock, I think because the UGF servos went crazy. The final lock, shown above, we lost because the MICH output was hitting the rails.
The problem with the MICH servo right now is the low SNR of the POPDC being used to normalize ASDC. The control output is enormous, even if we have the 400Hz lowpass on. We need to rethink our MICH servo, starting with a lower UGF, so that we're not injecting all this sensing noise all over the place.
Since Rana's overhaul of the IMC, the FSS input offset had been sitting at zero.
Over the last day or so, I had noticed the MC refl wall striptool trace looking noisier, and earlier this evening, we were suffering from a fair amount of downtime due to IMC unlocks, and failure to autolock for times on the order of ten minutes.
While we had used ezcaservo for this in the past, I set the FSS offset manually tonight. Namely, I popped open a dataviewer trace of MC_F, and scanned the FSS offset to make MC_F go to zero. It required a good amount of offset, 4.66 V according to the FSS screen. I did this while the FSS slow servo was on, which held the FSS Fast output at zero.
That was four hours ago; MC_F is still centered on zero, and we have not had a single IMC unlock since then. The MC refl trace is thinner too, though this may be from nighttime seismic.
This problem with the CARM loop last night was the fault of a bug that I had put into the LSC model last week. When I gave the input matrix and normalization matrix double rows, I had put the goto tags for the CARM normalization matrix rows backwards. So, even though I thought I was not normalizing CARM, in fact I was normalizing by POPDC, which was near zero since the PRM was misaligned.
Anyhow, found, fixed, currently locking, and all seems well.