[Eric, Riju, Annalisa]
Today we have cleared up the fiber spool near AP table. We have put the 1x16 fiber splitter and a box (we made two openings on it) for fiber spool on a different part of the rack. Also put a plastic tubing or the fibers coming out of AP table. Now the fibers coming out from AP table and also from POX table first enter the box through one opening and the end of the fibers come out of the other opening to get connected to to splitter. Photographs of the work are attached. I don't think enough fiber is there to make a similar loop for fiber coming from POY table.
I have figured out all the issues, and successfully installed the new versions of the LAL software. I am now going to get the summary pages set up using the new code.
I'm planning to remove the ETMY optical table enclosure and move it over to CES Shop 8am Thursday morning.
We'll install spring loaded lathes, hooks and quick release pins.
The bridge will be reinforced with steel plate to support release pins on posts.
There will be an other cut out for cable feedtrough as it is shown on elog #8472
Let me know if this timing does not fit your work.
Note that I'm supposed to return one of the two green beat PDs and the power supply.
They are on the REFL path. I'll work on the restoration of the beat configuration.
I locked the Xarm on green. At the PSL table, I adjusted the steering mirror to get the beam centered on the GTRX DC PD. We need a lens for this, and presumably for the GTRY as well.
I then went down to the Xend, and adjusted the steering mirrors to maximize the transmitted green power. I got as high as 2150 counts.
Either the alignment is particularly delicate, or something isn't quite right, but when I put the lid back on the optical table's box, the arm will no longer lock on the 00 mode. It's pretty typical that the cavity will unlock while you put on the lid, but usually if you bang on the underside of the table, or toggle the green shutter, you'll get back to the 00 mode. Tonight however, I can't get the 00 mode if the lid is on. If I slide the lid off just enough to get my hand inside, then block the green beam with my hand, I immediately lock on the 00 mode. Even if I gently slide the lid back on, I unlock the cavity, and with the lid on can't get better than a 01 mode in yaw. I repeated this a few times, with the same result.
A goal for the next few days: Re-find the Xgreen beatnote. Once we have the PRMI locking stably and reliably, we want to move on to PRFPMI.
Koji noticed that earlier this afternoon the Yarm ASS was working, but then after dinner it was no longer working. I saw that the ETMY trans camera beam was clipped. These things precipitated a visit to the Yend station.
I saw that the beam on the optic that steers the camera beam to the camera was very, very low, almost falling off the optic. The only mirror which steers to this optic is the harmonic separator which reflects the IR, and transmits the green. I turned the pitch knobs on the harmonic separator until the beam was roughly centered on all 3 optics between the separator and the camera (BS to QPD, BS to TRYDC and Y1 for camera). The yaw was fine, so I didn't touch it.
I then adjusted the steering mirror to the camera, and the BS pointing to the DC PD. I have not touched the BS pointing to the QPD. Once the beam was on the TRY PD, Koji ran the ASS script, and I recentered the beam on the DC PD. During this time, Koji had the Yarm triggering using -1 in the POYDC element of the matrix.
The harmonic separator is not mounted in a nice way (I'm assuming that Annalisa is in the middle of things, and she'll get back to it after the green work), so the TRY PD and camera will need to be aligned again, so I didn't do any ASS-recentering-ASS iteration tonight.
The Yarm ASS works nicely again, getting TRY to ~0.89 .
Evan brought the Guralp handheld readout paddle and cables back from the ATF (Zach is using GUR2 and one of the T240s for gyro stuff this week), and we recentered the GUR1 masses. N/S and Vert were okay (within 0.1 V), but E/W was at -0.5 V, so we set it at zero. We then plugged the Guralp back in, and turned on the readout box.
There isn't much of a change on the BLRMS on the wall, so it's possible that we weren't actually having any trouble anyway.
- Disabled MCL path in mcdown/mcupscript.
Nominal gain in mcdown/mcup was -50 and -100 respectively.
- Confirmed the stable lock was just because of the quiet seismic of the Friday night.
- Improvement of the PRM ASC servo
RG3.2 (3.2Hz Q=2 Height 30dB)
RG3.2 (3.2Hz Q=10 Height 30dB) + zero[f, 1, .5] pole[f, 2, 3] zero[f, 4.5, .5] pole[f, 3.5, 3]
Filter shape comparison is found in the second plot attached.
The resulting spectra (freerun vs controlled) is found in the first plot.
Nominal PRM ASC gain is +70
- Openloop TF measurement
OLTF PRCL 250Hz 30deg / MICH 200Hz 45deg
- REFL55/REFL33 phase adjustment (in lock)
REFL55 phase fine tune (95.25deg) (x1,x0.3)
REFL33 phase (-13.0deg) (x1, x2)
Yend table - Current status
Today the 2m focal length lens along the oplev path (just after the laser) has been added. In Manasa's layout it allows to have a beam waist of 3.8mm on the OPLEV QPD, even if it seems to be smaller.
The laser is closer to the box wall than the layout shows (it's on the line n.1 instead of line n.9), so maybe it has to be moved in the position shown in the layout, as Steve suggests, to leave empty space just before the window.
Rana suggests a 2mm diameter beam on the QPD, so a new calculation has to be done to add a second lens.
The beam has been aligned until the doubler, but after the crystal it it has a small tilt, so a better alignment has to be done.
Moreover, the beam waist has to be measured after the Faraday for the green, in way to choose the focal length of the lenses necessary for the mode matching.
Then the three steering mirrors to send the beam into the arm have to be put.
A lens which has to be put on the Transmon path (already ordered) has to be added, and the beam alignment on the QPD-y and on the PDA520 has to be done.
I want to redo this estimate of where RIN comes from, since Den did this measurement before I put the lens in front of the POP PD.
While thinking about his method of estimating the PR3 effect, I realized that we have measured numbers for the pendulum frequencies of the recycling cavity tip tilt suspensions.
I have been secreting this data away for years. My bad. The relevant numbers for Tip Tilts #2 and #3 were posted in elog 3425, and for #4 in elog 3303. However, the data for #s 1 and 5 were apparently never posted. In elog 3447, I didn't put in numbers, but rather said that the data was taken.
Anyhow, attached is the data that was taken back in 2010. Look to elog 7601 for which TT is installed where.
Conclusion for the estimate of TT motion to RIN - the POS pendulum frequency is ~1.75Hz for the tip tilts, with a Q of ~2.
I have done a quicky offline Wiener filter to check how much PRM yaw motion we can subtract using a seismometer in the corner station. This work may be redundant since Koji got the POP beam shadow sensor feedback loop working on Friday night.
Anyhow, for now, I used the GUR2 channels, since GUR2 was underneath the ITMX chamber (at the north edge of the POX table). Note that Zach is currently borrowing this seismometer for the week.
I used GUR2_X, GUR2_Y and GUR2_Z to subtract from the PRM_SUSYAW_IN1 channel (the filename of the figure says "GUR1", but that's not true - GUR1 is at the Yend). All 4 of these channels had been saved at 2kHz, but I downsampled to 256 (I probably should downsample to something lower, like 64, but haven't yet). There is no pre-filtering or pre-weighting of the data, and no lowpass filters applied at the end, so I haven't done anything to remove the injected noise at higher freqs, which we obviously need to do if we are going to implement this online.
If I compare this to Koji's work (elog 8562), at 3.2Hz, he gets a reduction of 2.5x, while this gets 10x. At all other frequencies, Koji's work beats this, and Koji's method gets reduction from ~0.03Hz - 10Hz, while this is only getting reduction between 0.4Hz and 5Hz. Also, this does not include actuator noise, so the actual online subtraction may not be quite as perfect as this figure.
Ah, AWESOME. Indefinite PRMI lock was finally achieved.
- Looked at the POP setup. Checked the spot on POP110 PD. Found some misalignment of the beam.
The beam spot was aligned to the PD with PRMI locked. The value of POP110I almost doubled by the alignment
and recovered previous value of 400. Therefore previous normalization values of MICH 0.01 / PRCL 100 were restored.
- Placed PDA36A (Si 3.6mmx3.6mm) on the POP path that Jenne prepared. The gain knob was set to 40dB.
Since the original spot had been too small, a lens with f=50mm was inserted in order to expand the beam.
Connected the PD output to the SMA feedthrough on the ITMX table enclosure.
I found the BNC cable labeled "PO DC" hanging. Connected this cable to the enclosure SMA.
- Went to the LSC rack. Found the corresponding PO DC cable. Stole the POPDC channel from POP110I Bias T to this PO DC cable.
- Razor blade setup: Machined a junk Al bracket in order to fix a razor blade on it. Attached the Al bracket to a sliding stage.
- Locked the PRMI with REFL33I&AS55Q. Cut the beam into half by the razor blade.
- Made a temporary PRM_ASC_YAW filter.
Zero: 0Hz Pole: 2kHz
Resonant Gain 3.2Hz Q:2 Height 30dB
Butterworth 2nd-order 60Hz
=> Expected UGF 0.1Hz&10Hz
- CDS: By the work described in this entry, the POPDC signal was connected to the "MC" bank of the LSC.
BTW, the 11th row of the LSC output matrix is connected to the PRM_ASC_YAW.
- The "MC" servo input (i.e. the POPDC signal) was normalized by POP110I (without SQRTing).
- Engaged the PRM ASC path. Gradually increased the gain of PRM_ASC_YAW. G=+100 seemed to be the best so far.
It was visible that the spot on the POP CCD was stablized in yaw.
- The lock lasted for ~40min. Took several measurements, alignment adjustment, etc.
- Tweaking the PRM ASC unlocked the PRMI.
- Locked again. Switched from REFL33I/AS55Q (x1/x1) combination to REFL55I/REFL55Q (x1/x0.3) combination.
This also kept the lock more than 20min.
I rotated some mounts along the green beam path, and I started aligning the beam again.
The beam is aligned up to the waveplate just before the doubler crystal, even if I couldn't reach more than 88% transmission for the Faraday. Next week I will finish the alignment and I'll put the lenses that Manasa already ordered.
More optics have been put on the table. Direction of the rejected beam from the 532nm faraday estimated to be ~1.7 deg along -y axis.
Transmon QPD, TRY and camera have beams on them for locking Y arm. Oplev configuration is waiting for it's lens to arrive.
Since I keep asking Manasa to "measure" distances off of the CAD drawing for me, I thought I might just write them all down, and quit asking.
So, these are only valid until our next vent, but they're what we have right now. All distances are in meters, angles in degrees.
Something that I want to look at is the coherence between seismic motion and PRM motion. Since Den has been working on the fancy new seismometer installations, I got caught up for the day with getting the new corner seismometer station set up with a T240. Later, Rana pointed out that we already have a Guralp sitting underneath the POX table, and that will give us a good first look at the coherence. However, I'm still going to write down all the cable thoughts that I had today:
The cables that came with the electronics that we have (from Vladimir and tilt meter -land) are not long enough to go from the seismometer to 1X7, which is where I'd like to put the readout box (since the acquisition electronics are in that rack). I want to make a long cable that is 19pin MilSpec on one end, and 25pin Dsub on the other. This will eliminate the creative connector type changes that happen in the existing setup. However, before making the cable, I had to figure out what pins go to what. So.
25pin Dsub 19pin MilSpec
4 No conn
6 R and V
9 No connection
13 No conn
16 R and V
17 No conn
23 No conn
I am not sure why R and V are shorted to each other, but this connection is happening on the little PCB MilSpec->ribbon changer, right at the MilSpec side. I need to glance at the manual to see if these are both ground (or something similar), or if these pins should be separate. Also, I'm not sure why 19 and 20 are shorted together. I can't find (yet) where the short is happening. This is also something that I want to check before making the cable.
Den had one Female 19 pin MilSpec connector, meant for connecting to a T240, but the cable strain relief pieces of the connector have 'walked off'. I can't find them, and after a solid search of the control room, the electronics bench, and the place inside where all of Den's connectors were stored, I gave up and ordered 2 more. If we do find the missing bits for this connector, we can use it for the 2nd T240 setup, since we'll need 2 of these per seismometer. If anyone sees mysterious camo-green metal pieces that could go with a MilSpec connector, please let me know.
Koji had the good idea of trying to measure the motion of the POP beam, and feeding that signal to PRM yaw to stabilize the motion. To facilitate this, I have installed a 50% beam splitter before the POP 110/22 PD (so also before the camera).
Before touching anything, I locked the PRM-ITMY half-cavity so that I had a constant beam at POP. I measured the POP DC OUT to be 58.16 counts. I then installed a 1" 50% BS, making sure (using the 'move card in front of optic while watching camera' technique) that I was not close to clipping on the new BS. I then remeasured POP DC OUT, and found it to be 30.63. I closed the PSL shutter to get the dark value, which was -0.30 . This means that I now have a factor of 0.53 less light on the POP110/22 PD. To compensate for this, I changed the values of the power normalization matrix from 0.01 (MICH) to 0.0189, and 100 (PRCL) to 189.
After doing this, I restored the ITMX and am able to get several tens of seconds of PRMI lock (using AS55Q and REFL33I).
I found several QPDs in the PD cabinet down the Y arm, but no readout electronics. The QPD I found is D990272. I don't really want to spend any significant amount of time hacking something for this together, if Valera can provide a QPD with BNC outputs. For now, I have not installed any DC PD or razor blade (which can be a temporary proxy for a QPD, enough to get us yaw information).
Progress with end table:
Parts in green show assembled optics that will not require any changes. Parts in yellow are in place but will need either change of lenses in their optical path or change in position.
We would like to increase the UGF of the PRC loop so as to allow more suppression of the PRC signal and less pollution of the MICH signal (remember that the PRC/MICH optical gain ratio is huge).
We were already losing phase because of delay in the LSC - SUS digital link. In addition to that, a major source of delay is the analog anti-aliasing (on the LSC error signals before they enter the ADC) and the analog anti-imaging (between the SUS DAC and the coil driver).
IN addition to these, the other major sources of phase lag in the system are the FM5 filter in the LSC-PRC filter bank, the digital upsampling and downsampling filters, and the DAC sample and hold.
In the near term, we want to modify these analog filters to be more appropriate for our 64 kHz ADC/DAC sample rate. Otherwise, we are getting the double phase lag whammy.
Staring at the schematics for the AA (D000076-01) and the AI (D000186-A), we determined a plan of action.
For the AA, we want to remove the multi-pin AA chip filter from Frequency Devices, Inc. and replace it with a passive LC low pass. Hopefully, these chips are socketed. Rana will design an appropriate LC combo and elog; we should make the change on a Wednesday afternoon so that we have enough soldering help.
For the AI, the filter is a dual bi-quad using discrete components and LT1125 opamps. Not so clear what to do with these. The resistors are all the noisy thick film kind and maybe should be replaced. Koji will find some online design tool for these or do it in LISO. Changing the TF is easy; we can just scale the capacitors. But we also want to make sure that the noise of the AI does not destroy the noise reduction action of the dewhitening board which precedes it.
Jenne should figure out how low the noise needs to be at the input to the coil driver.
P.S. the matlab code which defines these filters
>> [z,p,k] = ellip(4,4,60,2*pi*7570,'s');
>> misc.ai = zpk(z,p,k*10^(4/20)) * zpk(,-2*pi*13e3,2*pi*13e3);
>> % Fudged Anti-Imaging Filter
>> [z,p,k] = ellip(8,0.001,80,2*pi*7570,'s');
>> misc.aa = zpk(z,p,k*10^(0.001/20)) * zpk(,-2*pi*32768,2*pi*32768);
Same ASS setup for the X arm has been done.
Now Arm ASS can run simultaneously.
I reverted the number of the lockin banks from 6 to 8 for future implementation of A2L for the ITMX by coil balancing.
Since A2L for the ITMX is just barely visible for now, I am going to leave the coil balance untouched.
This removes the old sqrt'ing from the inputs to the POW_NORM matrix (was only on the POP110 I/Q) and moves it to the DOF outputs. Koji wanted this so that he could use the DC signals for normalization both sqrt'd and not sqrt'd.
The POW_NORM medm screen was updated accordingly.
Precise arm alignment is more demanded. as the PRMI locking requires good and reliable alignment of the ITMs.
I previously added the output matrix to ASS.
Now the input and output matrix as well as the gains and filters have been updated.
The current concept is
Fast loop: align the arms by the arm mirrors with regard to the given beam.
Slow loop: move the incident beam position and angle to make the spot at the center of the mirrors
This is actually opposite to Den's implementation.
In order to realize the faster alignment of the arm, I increased the corner frequency of the lockins for the arm signals from 0.5Hz to 1Hz.
With the new configuration the arm alignment converges in 10sec and the input pointing does in ~15sec.
The actuation to the input pointing TTs are done together with the feedforward actuation to the arms.
This way we can avoid too much coupling from the input pointing servos to the arm alignment servos.
The corresponding script /opt/rtcds/caltech/c1/scripts/ASS/YARM/DITHER_Arm_ON.py was also modified.
As with the last two posts, I eliminated more unnecessary passing through c1rfm for IPC connections between c1mcs and c1ioo.
All models were rebuilt/installed/restarted and svn committed. Everything is working and we have eliminated almost all IPC errors and significantly simplified things.
As with the previous post, I eliminated and unnecessary hop through c1rfm for the c1als --> c1mcs connection for the ALS output to MC2 POS.
As a side note, we might considering piping the ALS signals into the LSC input matrix, elevating them to actual LSC error signals, which in some since they are. It's just that right now we're routing them directly to the actuators without going through the full LSC control.
Previously, for some reason, many IPC connections were routed through the c1rfm model, even if a direct IPC connection was possible. It's unclear why this was done. I spoke to Joe B. about it and he couldn't remember either. Best guess is that it was just for book keeping purposes. Or maybe some old timing issue that has been fixed by DMA fixes in the RTS. So the point is that it's no longer needed, and we can reduce delays by making direct connections.
I made direct IPC connections from c1lsc to both c1sus and c1mcs, bypassing the c1rfm, through which they had previously been routed. All models were rebuilt/installed/restarted and everything seems to be working fine.
Someone for some reason added full-rate DAQ specification to some ADC3 channels in the c1sus IOP model (c1x02):
These appear to be associated with c1pem, so I'm guessing it was Den (particularly since he's the worst about making modifications to models and not telling anyone or logging or svn committing).
I'm removing them.
c1rfm / c1lsc / c1ass / c1sus were modified. They were recomplied and installed. They are running fine
and confirmed PRMI locking (attempt), arm locking, and Yarm ass with the new codes.
1a. SQRTing switching for POP110 was wrong. 0 enabled sqrting, 1 disabled sqrting. I wanted to fix this.
1b. Sqrting for POP22 was not implemented.
2. Preparation for the shadow sensor control with POPDC.
3. ASS had only an input. I want to run two ASS for the X and Y arms.
SQRTing for POP110/22:
- Flipped the input of the bypass switch. Correspoding MEDM indicators are fixed on the power normalization screen.
- Copied the sqrting structure from POP110 to POP22. Correspoding MEDM buttom was made on the power normalization screen.
- The function of the sqrting buttons were confirmed.
Additional ASS output:
- The output path "NPRO" was removed. Corresponding RFM channels have also removed.
- The previous NPRO path was turned to the "ASS1" path. The previous "ASS" path was turned to "ASS2".
- Corresponding shared memory channel are created/renamed.
- c1ass was modified to receive the new ASS shared memory channels. ASS1 is assigned to the X arm. ASS2 is assigned to the Y arm
- The output matrix screen and the lockin screen were modified accordingly.
- Only script/ASS/Arm_ASS_Setup.py was affected. The corespoding lines (matrix assignment) was fixed.
- The function of Den's version of ASS was confirmed.
LSC->PRM ASC path
- We want to connect POPDC to PRM ASC. POPDC is acquired on c1lsc.
- So, for now we use the LSC input matrix to assign POPDC to one of the servo bank.
- The last row of the LSC output matrix was assigned to the PCIE connection to c1sus.
- This PCIE connection was connected to the PRM ASC YAW input.
- The connection between LSC and SUS was confirmed.
- During this process I found that there are bunch of channels transferred from LSC to SUS via RFM.
These channels are transferred via PCIE(dolphin) and then via RFM. But LSC and SUS are connected
with dolphin. So this just adds additional sampling delay while there is no benefit. I think we should remove the RFM part.
Note that we need to use RFM for the end mirrors but this also should use only the RFM connection.
Rebuilding the codes
- Prior to the tests of the new functionalities, the codes were rebuild/installed as usual.
- The suspension were shutdown with the watch dogs before the restart of the realtime codes.
- Once the realtime codes were restarted successfully, the watch dogs were reloaded.
- As we removed/added the channels, fb was restarted.
- c1rfm / c1lsc / c1ass / c1sus codes were checked-in to svn
All of these changes were committed to the SVN.
Rana showed up and diagnosed the problem as a railed FSS SLOW output. The SLOW Monitor about was showing ~6V, which is apparently a bad mode-hoppy place for the NPRO. Reducing the SLOW output brought things back into a good range which allowed the PMC to lock again.
In attempting to diagnose the problem I noticed that there is -100 mV DC coming out of the PMC RFPD RF output. This is not good, probably indicating a problem, and was what I thought was the PMC lock issue for a while. Need to look at the PMC RFPD RF output.
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master 0$ ls
C1IOO_LKIN_OUT_MTRX.adl C1IOO_MC_ASS_LOCKIN5.adl C1IOO_WFS1_I.adl C1IOO_WFS_LKIN.adl
C1IOO_LOCKMC.adl C1IOO_MC_ASS_LOCKIN6.adl C1IOO_WFS1_Q.adl C1IOO_WFS_MASTER.adl
C1IOO_LOCKMC_BAK.adl C1IOO_MC_ASS_PIT_LOCKIN.adl C1IOO_WFS1_SETTINGS.adl C1IOO_WFS_MASTER.adl~
C1IOO_MC_ALIGN.adl C1IOO_MC_ASS_YAW_LOCKIN.adl C1IOO_WFS1_SETTINGS.adl.old C1IOO_WFS_MASTER_BAK.adl
C1IOO_MC_ALIGN.adl~ C1IOO_MC_LOCKINS.adl C1IOO_WFS2_I.adl C1IOO_WFS_OUTMATRIX.adl
C1IOO_MC_ALIGN_BAK.adl C1IOO_MC_SERVO.adl C1IOO_WFS2_Q.adl C1IOO_WFS_QPD.adl
C1IOO_MC_ASS.adl C1IOO_MC_TRANS_QPD.adl C1IOO_WFS2_SETTINGS.adl C1IOO_WFS_QPD.adl.old
C1IOO_MC_ASS_LOCKIN1.adl C1IOO_Mech_Shutters.adl C1IOO_WFS2_SETTINGS.adl.old fmX
C1IOO_MC_ASS_LOCKIN2.adl C1IOO_MODECLEANER.adl C1IOO_WFS_HEADS.adl junk
C1IOO_MC_ASS_LOCKIN3.adl C1IOO_QPDS.adl C1IOO_WFS_HEADS.adl.old master
C1IOO_MC_ASS_LOCKIN4.adl C1IOO_QPDS_BAK.adl C1IOO_WFS_INMATRIX.adl svn-commit.tmp~
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master/master 0$ helppp
helppp: command not found
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master/master 127$ help me
bash: help: no help topics match `me'. Try `help help' or `man -k me' or `info me'.
I have updated the waists (W) and beam diameters (D) at 1064nm optics on the endtable.
I am not able to locate the characteristics of QPD-Y and oplev PD and hence took the beam diameter to be half of the detector surface area to determine their positions.
Beam diameter on PDA520 used for TRY was calculated using the transimpedance and responsivity of the PD from an old elog in 2004.
I'm just now realizing that the PMC has also not been locked since noon today, and doesn't seem to be responding to anything right now.
wtf is going on here?
Here's an example of the total horribleness of what's happening right now:
controls@rossa:~ 0$ ping 192.168.113.222
PING 192.168.113.222 (192.168.113.222) 56(84) bytes of data.
From 192.168.113.215 icmp_seq=2 Destination Host Unreachable
From 192.168.113.215 icmp_seq=3 Destination Host Unreachable
From 192.168.113.215 icmp_seq=4 Destination Host Unreachable
From 192.168.113.215 icmp_seq=5 Destination Host Unreachable
From 192.168.113.215 icmp_seq=6 Destination Host Unreachable
From 192.168.113.215 icmp_seq=7 Destination Host Unreachable
From 192.168.113.215 icmp_seq=9 Destination Host Unreachable
From 192.168.113.215 icmp_seq=10 Destination Host Unreachable
From 192.168.113.215 icmp_seq=11 Destination Host Unreachable
64 bytes from 192.168.113.222: icmp_seq=12 ttl=64 time=10341 ms
64 bytes from 192.168.113.222: icmp_seq=13 ttl=64 time=10335 ms
--- 192.168.113.222 ping statistics ---
35 packets transmitted, 2 received, +9 errors, 94% packet loss, time 34021ms
rtt min/avg/max/mdev = 10335.309/10338.322/10341.336/4.406 ms, pipe 11
Note that 10 SECOND round trip time and 94% packet loss. That's just beyond stupid. I have no idea what's going on.
I'm not sure what's going on today but we're seeing ~80% packet loss on the 40MARS wireless network. This is obviously causing big problems for all of our wirelessly connected machines. The wired network seems to be fine.
I've tried power cycling the wireless router but it didn't seem to help. Not sure what's going on, or how it got this way. Investigating...
To change the MC length is not the point.
If we can improve the length sensing by the intentional shift of the modulation frequency from the MC FSR, that's worth to try, I thought.
But that is tough as the freq difference is 18kHz that is ~x4 of the line width of the MC.
Not only the 55MHz sidebands, but also the 11MHz sidebands will just be rejected.
Nevertheless: Is there any possibility that we can improve anything by shifting the modulation frequency by ~1kHz?
Koji asked me to look at what the ideal RF modulation frequency is, for just the PRMI case (no arms). If we had a perfect interferometer, with the sidebands exactly antiresonant in the arms when the arms resonate with the carrier, this wouldn't be an issue. However, due to vacuum envelope constraints, we do not have perfect antiresonance of the sidebands in the arm cavities. Rather, the sideband frequencies (and arm lengths) were chosen such that they pick up a minimum amount of extra phase on reflection from the arms. But, when the arms are off resonance (ex, the ETMs are misaligned), the sideband frequencies see a different amount of phase.
We want to know what a rough guess (since we don't have a precise number for the length of the PRC since our last vent) is for the ideal RF modulation frequency in just the PRMI.
If I take (from Manasa's kind measurements from the CAD drawing yesterday) the relevant distances to be:
L_P[meters] = 1.9045 + 2.1155 + 0.4067
L_X[meters] = 2.3070 + 0.0254*n
L_Y[meters] = 2.2372 + 0.0359*n + 0.0254*n
L_PRCL = L_P + (L_X + L_Y)/2 = 6.7616 meters.
The *n factors (n=1.44963) are due to travel through glass of the BS, and the substrate of the ITMs.
I find the FSR of the PRC to be 22.1686 MHz. For the sidebands to be antiresonant, we want them to be 11.0843 MHz. This would correspond to a mode cleaner length of 27.0466 meters. Our current modulation frequency of 11.066134 MHz corresponds to a MC length of 27.091 meters. So, if we want to use this 'ideal' modulation frequency for the PRC, we need to shorten the mode cleaner by 4.4cm! That's kind of a lot.
I asked Gabriele why it looked like for the PRCL sweep REFL 55 I&Q were zero at zero, but for the MICH sweep only REFL55 I was zero. He took a look at his code, and found that he was not at the correct locking point. Here is his email back to me:
I found the reason for the not zero value. Indeed, if you could zoom into the PRCL sweep, you would see that the error signals does not cross zero exactly at PRCL=0, but instead some 50 pm away from zero. This is enough to change a lot the PRCL signal when sweeping MICH. If I put PRCL to the correct zero point, and I sweep MICH, I now get everything at zero. I'm sending again the plots.
The fact that such a small detuning is enough to change PRCL signal when sweeping MICH is due, I believe, to the fact that MICH optical gain is much smaller than PRCL one.
Here are the redone plots:
Phase not tuned:
POP22 resonance for MICH and PRCL:
POP110 resonance for MICH and PRCL:
I am now working on megatron, installing in /home/controls/lal. I am having some unmet dependency issues that I have asked Duncan about.
BS is contributing a little bit, but PRM is clearly contributing.
While the peak in the PRM OPLEV was more than 10 times higher than the spectrum level without the excitation,
we only saw small peaks in the RIN spectra. This suggests that the PRM angular motion did not contribute to the RIN spectra.
You should divide the POP110I and POPDC spectra by 400 and 450, which was the DC values of these channels, in order to convert them into RIN (1/rtHz)
The OPLEV spectra is calibrated to be urad/rtHz (is this true?) so you can obtain the conversion factor from OPLEV to RIN (1/urad)
by matching the peaks. This way you make a angular noise projection.
I think that I need to install one of the T240's on the new granite slab, and see what kind of coherence we have between seismic and PRM yaw motion, and if FF can get rid of it.
Yes we should do that. BTW what should be pushed?
I'm not sure why, but starting ~3.5 hours ago, the WFS seem to not be holding the MC in optimal alignment.
The WFS are definitely engaged and the loops are closed, but every time the MC locks, the WFS pitch and yaw values start drifting off. In particular, the WFS loop actuation pushing on MC2 is in the many hundreds of counts after ~90 minutes of drift time. I tried offloading those values by moving the MC2 slider, but then I unlocked the MC to check what that did to the alignment, and it was decidedly bad. So, I'm not sure what's up with the WFS, but I need to look at it tomorrow.
While looking over Koji's shoulder earlier, I noticed the big peak in the PRM yaw spectrum (and I was starting to get annoyed by the hum....the fibox is so useful in motivating tasks that otherwise get looked over!)
I used DTT's peak find feature (cursor tab, enable both cursors, select Peak X/Y as your 'statistic', set the 2 cursors to be on either side of the desired peak) to find the frequency of the PRM's violin mode. It is 627.75 Hz. I adjusted FM5 of the C1:SUS-PRM_LSC filter bank (the "violin" filter) to be centered around this frequency, with the start and stop freqs +\- 4Hz. I plotted the filter linearly in frequency to ensure that my target freq was not too close to either side of the bandstop. After loading and engaging the new filter, the hum slowly started to go away.
Note, for posterity: The bandstop used to be centered around ~645 Hz or so. I assume this is a copy-and-paste situation, where we hadn't gone through to check the exact frequency for each optic.
Koji spent some time earlier this evening exploring where the excess RIN that we see in the PRC is coming from.
He did this by locking the PRMI (MICH on AS55Q, PRCL on REFL33I, Pnorm for MICH = sqrt(POP110) with 0.1, Pnorm for PRCL = sqrt(POP110) with 10, MICH gain = -30, PRCL gain = 8), and then exciting each relevant optic, one at a time, in yaw. The excitation was always using the ASCYAW excitation point on each of the optics (BS, PRM, ITMX, ITMY), with a frequency of 4.56 Hz, and an amplitude of 30 counts.
He also took reference traces with no optics excited.
Here, I plot (for each excited optic separately) the reference traces and traces during excitation for POP110_I_ERR, POPDC, and the OPLEV_YERROR for the optic that is being excited.
What we are looking for (only in yaw, since we see on the cameras that the dominant motion is in yaw) is an increase in POPDC and POP110 at the same frequency as an optic's excitation.
We see that neither ITM is contributing a noticeable amount to either POPDC or POP110. BS is contributing a little bit, but PRM is clearly contributing. No this entry should be read. (KA)
A week or two ago, I calculated in elog 8489 that the angular motion that we see does not explain the RIN that we're seeing, unless our cavity is much more unstable than Jamie calculated in elog 8316.
As it turned out, the setting of +26dB for the FSS Fast gain was making the NPRO PZT / Pockels cell crossover too unstable. This was the cause of the large ~30 kHz peak that Jamie was seeing in his spectra (more to follow in the morning).
After recovering the locking, etc. by fiddling with the gains, we went about systematically setting all of the gains/offsets. Jamie's elog will show all of the various spectra with different FSS gains.
For offset setting, this was the procedure:
Let the MC lock and go through the UP script. When the MCL comes on with the integrator, the FAST voltage will shift from +5.5 V to something else. Use the following line: ezcaservo -r C1:PSL-FSS_FAST -g -1 -s 5.5 C1:SUS-MC2_MCL_OFFSET, to automatically tune the MCL offset.
About 30 minutes ago the mode cleaner fell out of lock and has since not been able to hold lock for more than a couple seconds.
I'm not sure what happened. I was in the middle of taking measurements of the MC error point spectrum, which included adjusting the FAST gain. I've put all the gains back to their nominal levels but no luck. I'm not sure what else could have gone wrong. Seismic noise looks relatively quiet.
Koji and I went into "Update Manager" on several of the Ubuntu workstations and unselected the "check for updates" button. This is to prevent the machines from asking to be upgraded so frequently - I am concerned that someone might be tempted to upgrade the workstations to Ubuntu 12.
We didn't catch them all, so please take a moment to check that this is the case on all the laptops you are using and make it so. We can then apply the updates in a controlled manner once every few months.
I have looked at / analyzed the Schnupp data that Annalisa and I took last week, as well as some more Yarm data that I took this week.
I only have one set of Xarm data, but 3 sets of Yarm data. I had intended to do careful error analysis of the data, but from the 3 sets of Yarm data, the variance in the answer I get using any one of the Yarm sets is much larger than the error in a single measurement.
Using the central Yarm zero crossing, I get a Schnupp asymmetry of 3.9cm. The other 2 Yarm data points give Schnupp asymmetries of 3.7cm and 4.1cm, so I'm claiming a value of 3.9 +\- 0.2cm . This is within error of Jamie's measurement of 3.64 ± 0.32 cm (elog 4821).
Output matrices are added to ASS. Currently ASS is based on the mirror bases.
I prefer to have the actuator bases as the coils are more stable than the sensors.
At this point, the output matrices are identity. So Den's scripts are still working.
Striptool settings were also fixed.
To aid in lock-loss studies, I made a new program called 'lookback', similar to 'getdata', to look at past data.
When called with channel name arguments, it runs continuously, storing all channel data in a ring buffer. When the user hits Ctrl-C, all the data in the ring buffer is displayed. There is an option to store the data in the ring buffer to disk as well.
controls@rosalba:/opt/rtcds/caltech/c1/scripts/general 0$ ./lookback -h
usage: lookback [-h] [-l LENGTH] [-o OUTDIR] channel [channel ...]
Lookback on testpoint data. The specified amount of data is stored in a ring
buffer. When Ctrl-C is hit, all data in the ring buffer is plotted. Both 'DQ'
and 'online' test point data is available. Use NDSSERVER environment variable
to specify host:port.
channel Acquisition channel. Multiple channels may be
specified and acquired at once.
-h, --help show this help message and exit
-l LENGTH, --lookback LENGTH
Lookback time in seconds. This amount of data will be
stored in a ring buffer, and plotted on Ctrl-C.
Default is 10 seconds
-o OUTDIR, --outdir OUTDIR
Output directory to write data (will be created if it
doesn't exist). Data from each channel stored as
'<channel>.txt'. Any existing data files will be