The in-vacuum installation team has reported that the side OSEMs of ITMX and LO1 are going to be interfering if place LO1 at the planned location.
I confirmed that ITMX has the side magnet on the other side (Attachment 1 ITMX photo taken on 2016/7/21). So we can do this swap.
The ITMX side OSEM is sticking out most. By doing this operation, we will recover most of the space between the ITMX and LO1. (Attachment 2)
The c1ass computer, which is now used for the OAF system, has many remnants from the days when it was actually used as an ASS. These PIT and YAW filter banks and other things were taking up a lot of unnecessary space, so I deleted them in the ass.mdl file. These files are all backed up, so we can always revert back to an older version when we want some Alignment Stabilization again someday. I then did a make ass, following the instructions on the 40m Wiki -> Computers and Scripts -> Simulink to Front-End Code page. Rana moved some things around, most notably all of the things (like the ASS screens) which were only in ...../users/alex/.... are now in ....../caltech/cds/advLigo/..... . This required a few restarts of the c1ass machine (after a couple different versions of the simulink diagram....one to make sure we knew how to do it, and then again actually deleting the unused portions).
The big lesson of the night was that there are 2 signal paths for the PEM channels. As is shown in Figure 3 in the mevans document, the PEM channels get the matching filters when they go to the adaptation algorithm, but when they go to the FIR filter, they do not get the matching filters. This is implemented by taking the output of the giant PEM matrix, and having a duplicate of each of the channels "selected for adaptation", one which gets filtered through the PEM_N_ADPT banks, and one which goes straight (in code-land) to the FIR filter. So, it seems like all the filters which we had been including in the input side of the matrix for matching purposes need to be put in the output side. One of the AA32 filters needs to stay in the input side, for actual anti imaging of the PEM channels, then we put the AA32 and AI32 which are for matching the ERR_EMPH and CORR filter banks up in the PEM_N_ADAPT banks. Rana and I made these filters, and they are now turned on appropriately with the OAF down script (so that all the filters are ready and waiting for the OAF to be turned on).
A little success with getting the 3Hz peak reduced, but not a lot beyond that. Tomorrow I'll put the accelerometers back where they used to be to see if they help out at all.
Today, I remeasured the transfer function for MC2 to MCL in order to improve the subtraction performance for MCL and to quantify just how precisely it needs to be.
Here is the fit, and the measured coherence. Data is also attached here: TF.zip
OMG, I forgot to post the data and any residuals. LOL!
The transfer function was fitted using vectfit with a weighting based on coherence being greater than 0.95.
I then used the following filters to do FF on MCL online:
Here are the results:
Performance has definelty increased when compared to previous filters. The reason why I think we still have poor performance at 3 Hz, is 1) When I remeasured the transfer function, Eric and I were expecting to see a difference on its shape due to the whitening filters that were loaded a couple days ago. 2) Assuming the transfer function is correct, there is poor coherence at 3 Hz 3) The predicted IIR subtraction is worst at this frequency.
[Jenne, Annalisa, with guidance from Koji]
We took data to remeasure the Schnupp asymmetry, using the Valera method that Jamie described in elog 4821.
1 First, we locked the arms each with their PO(X,Y) signals, to get the alignment of each arm.
2. Then, we locked the Xarm with AS55I (Yarm optics, and PRM very misaligned, more than the misalign script). Since AS55 was saturating, I changed the analog gain from 24dB to 21dB. (After work was completed, the analog gain was put back to the nominal 24dB for both I&Q.)
3. We set up the Lockin similar to Jamie's description, with a few differences. We used the same f = 103.1313, but used ampl=10cts. Sin and cos gain were each 100. We changed the lowpass filter from 0.1Hz to 0.05Hz (so each measurement had a settling time of at least 20sec). We were using LSC-Lockin4, so the Lockin matrix was set so Lockin4 was reading from AS55Q, and the LSC output matrix was such that we were actuating on the ETM (X, then Y when we switched arms later).
4. By hand, we roughly found the zero crossing of the lockin-q output (which corresponded also to zero of the lockin-I, since this is the place where all of the PDH signal was in AS55I, and the lockin was reading AS55Q).
5. We took points separated by 0.2 degrees, plus and minus 1 degree from the zero-crossing phase we had found (i.e., for the Xarm, we roughly found the zero crossing at -14.39 deg, so took data from -15.39 to -13.39degrees). For each phase, we took 5 measurements (using ezcaread), at least 20 seconds apart. After moving the phase, we waited at least ~40 seconds (watching the lockin outputs on striptool, they had completely settled after 30 or 40 seconds).
6. We then repeated steps 2, 4 and 5 for the Y arm. The lockin setup didn't change, except that now we actuate on ETMY.
We did a quick estimate calculation, from our rough zero-crossings to get a rough measurement of the Schnupp asymmetry. DeltaPhi = (-14.39 - -19.79) = 5.40 . This gives us (using F_sideband = 5*11066134, the current 11MHz marconi freq) a rough Schnupp asymmetry of 4 cm.
Analysis to follow.
EDIT, JCD: The Xarm gain at this time was -0.160, and the Yarm gain was -0.170
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).
POY was looking funny, and the YARM wasn't locking. It looked like POY wasn't seeing any light at all. I went to check, and it looks like a beam dump got accidentally placed in the POY path during oplev adjustments this morning. POY is back, locking continues.
Way back, Jay had D-sub to SCSI adapters made to adapt our existing Sander box AA filters to the new SCSI based IO chassis. However, these did not fit inside the box.
At the time, we simply left the cards outside hanging, which was a hack and needed to be replaced.
Steve modified a black AA filter box so that it could fit the D-sub to SCSI adapter board on it, plus strain relief the SCSI cable, rather than let it hang. The back of the box was cut, and an extending piece of metal attached to the bottom of the box. The adapter board was screwed into the box, the SCSI plugged in, then the SCSI cable is clamped to the extending metal as well.
This modification will be propagated to the 3 remaining AA filter boards using the D-sub to SCSI adapter.
The same modification was carried out at 1X5 for PRM & SRM.
Note: D68L8EX-850Hz are removed and bypassed in 7 channels.
Because it was driving me crazy while working on the new medm screens for the simulated plant, I went and removed the aliased font entries in /usr/share/X11/fonts/misc/fonts.alias that are associated with medm. Specifically I removed the lines starting with widgetDM_. I made a backup in the same directory called fonts.alias.bak with the old lines.
Medm now behaves the same on op440m, rosalba, and allegra - i.e. it can't find the widgetDM_ scalable fonts and defaults to a legible fixed font.
Frank noticed that this particular SR560 had an offset on the output which was unzeroable by the usual method of tuning the trim pot accessible through the front panel.
I tried to zero the offset using the trimpots inside, but it became clear that the offset was due to a damaged FET, so Steve ordered ~20 of the (now obsolete*) NPD5564.
I replaced this part and adjusted the offsets and balanced the CMRR of the differential inputs mostly according to the manual (p. 17). There are a few notes that should be added to the procedure:
It looks like its working fine now. Steve's ordering some IF3602 (low-noise, balanced FET pair from Interfet) to see if we can drop the SR560's input noise to the sub-nV level.
Noise measured with the input terminated with a BNC short (not 50 Ohms) G=100, DC coupled, low-noise mode:
Since we don't have agreement between the measurements we made the other day and the earlier estimations, I wanted to repeat the demodulation angle measurement. We had to do a few things to keep the PRMI locked, since in the last few days, it hasn't been stable enough.
The mode cleaner had been very fussy lately; the WFS were pushing in a way that caused fast oscillations of the transmission and reflection powers. I turned off the servos, manually aligned the mode cleaner to transmission of about 15k and refl of about .4, centered the beams on the WFS QPDs, and turned the loops back on. Things were much stable after that. Also, Jenne noticed that the PMC loop had walked the laser PZT temperature to a bad place, and fixed it.
After aligning the carrier locked PRMI, the last piece needed to get things stable enough for sideband locking was turning off the angular damping on the PRM suspension screen (this was turned back on when we were done). Waiting until evening noise levels probably helped too. We used a 1000 count MICH excitation in the PRMI case, and recorded data for about a minute in one degree steps around the demodulation phase that looked to put the excitation entirely within the Q of the PD. Also, we notched out the excitation frequency in the MICH servo bank for today's measurement; I think it's outside of the loop bandwidth anyways, but it's good to be sure.
Jenne and I pondered a bit whether changing the AS55 demodulation phase while it (AS55 Q) is being used as the MICH control signal introduces subtleties that we haven't anticipated, but couldn't come up with anything concrete. Changing the angle from the what maximizes the Q just looks like a slight change in MICH gain, and shouldn't affect the phase of the excitation signal on the PD...
In any case, the data have been recorded, and the results will follow soon.
Since I am mainly concerned with the actuator part of the OSEM, I chose to do this measurement at the output cables for the coil drivers in 1X4. See schematic for pin-mapping. There are several parts in between my measurement point and the actual coils but I figured it's a good check to figure out if measurements made from this point yield sensible results. The slow bias voltages were ramped off under damping (to avoid un-necessarily kicking the optics when disconnecting cables) and then the suspension watchdogs were shutdown for the duration of the measurement.
I used an LCR meter to measure R and L - as prescribed by Koji, the probe leads were shorted and the readback nulled to return 0. Then for R, I corroborated the values measured with the LCR meter against a Fluke DMM (they turned out to be within +/- 0.5 ohms of the value reported by the BK Precision LCR meter which I think is reasonable).
Pin1-9 (UL) / R = 30.6Ω / L=3.23mH
Pin2-10 (LL) / R = 30.3Ω / L=3.24mH
Pin3-11 (UR) / R = 30.6Ω / L=3.25mH
Pin4-12 (LR) / R = 31.8Ω / L=3.22mH
Pin5-13 (SD) / R = 30.0Ω / L=3.25mH
Pin1-9 (UL) / R = 31.7Ω / L=3.29mH
Pin2-10 (LL) / R = 29.7Ω / L=3.26mH
Pin3-11 (UR) / R = 29.8Ω / L=3.30mH
Pin4-12 (LR) / R = 29.7Ω / L=3.27mH
Pin5-13 (SD) / R = 29.0Ω / L=3.24mH
On the basis of this measurement, I see no problems with the OSEM actuators - the wire resistances to the flange seem comparable to the nominal OSEM resistance of ~13 ohms, but this isn't outrageous I guess. But I don't know how to reconcile this with Koji's measurement at the flange - I guess I can't definitively rule out the wire resistance being 30 ohms and the OSEMs being ~1 ohm as Koji measured. How to reconcile this with the funky PRM actuator measurement? Possibilities, the way I see it, are:
I broke a small bit while using the 40m drill press to vent some 1/4-20 screws for the cryo experiment.
I replaced it and refilled the small bit row in the bit index I was using; there were ~10 missing sizes
We replaced the laser for optical lever of ETMY. And also we aligned the path so that beam spot hits the center for each optics. I attached the spectrum of the SUS-ETMY_OPLEV_SUM, the red curve is with old laser, and blue curve is with the new laser. We also measured without laser so as to measure the QPD dark noise (green curve). The change is significant, and seems much closer to other oplev spectrum.(Brown curve is the oplev spectrum of ITMY)
The new laser is:
Manufacture name: JDSU, Model number: 1103P, Serial number: PA892324
The injection power is 3.7 mW and the out coming power is 197 uW (measured just before the QPD). The output value of the SUS-ETMY_OPLEV_SUM is about 8500.
First we measure 2 spectrum ( including the dark noise). After that we replace the laser and align the optical lever path. We changed the post of one of the mirror (just before the QPD) because the hight was too low. Inside of the chamber is darker than before - actually we had scattering light inside the chamber before. We dumped the reflected light from QPD. And then we measured the spectrum of the oplev output. I also aligned oplev of ETMY after restoring the YARM configuration using IFO configure screen.
We don't know actually what was the problem, laser quality or the scattering light or some clipping. But the oplev seems to be better.
Steve: Atm2 shows increased gains correction later for UGF elog 9206
That's good, but please no more Oplev work. We want to do all of it at once and to make no more changes until we have all the parts (e.g. dumps and correct lenses) in hand and then talk over what the new design will be. I don't want to tune the beam size and loop shape every week.
I centered the ETMY OL today and found that the UGF was around 3-4x too LOW after the laser swap and re-alignment. That's why the Y arm has been shaking so much today.
NO more OL work without loop measurements and noise measurements.
RA: I'm not sure how to interperet this; I think that the SUM channel is divided by the SUM so that this is supposed to be RIN, but not sure. Can someone please take a look into the SUS model and then explain in the elog what the SUM normalization algorithm is?
I have found two great FET input chips that rival the storied, discontinued AD743. In some ways, they are even better. These parts are the OPA140 and the OPA827.
Below is a plot of the input-referred voltage noise of the two op amps with Rsource = 0, along with several others for comparison. The smooth traces are LISO models. The LT1128 and AD797 are BJT-input parts, so their voltage noise is naturally better. However, the performance you see here for the FET parts is the same you would expect for very large source impedances, due to their extremely low current noise by comparison. I have included the BJTs so that you can see what their performance is like in an absolute sense. I have also included a "measured" trace of the LT1128, since in practice their low-frequency noise can be quite higher than the spec (see, for example, Rana's evaluation of the Busby Box). The ADA4627 is another part I was looking into before, the LT1012 is a less-than-great FET chip, and the AD797 a less-than-great BJT.
As you can see, the OPA140 actually outperforms the AD743 at low frequencies, though it is ~2x worse at high frequencies. The OPA827 comes close to the AD743 at high frequencies, but is a bit worse at low ones. Both the OPA140 and OPA827 have the same low-frequency RMS spec, so I was hoping it would be a better all-around part, but, unfortunately, it seems not to be.
The TI chips also have a few more things on the AD743:
These characteristics make both parts exceptionally well suited for very-high source impedance applications, such as very-low-frequency AC-coupling preamplifiers or ultra-low-noise current sources.
(Apologies---the SR785 I was using had some annoying non-stationary peaks coming in. I verified that they did not affect the broadband floor).
Rana suggested that I measure the OPA827 and OPA140 noise with high source impedance so as to see if we could find the low-frequency current noise corner. Below is a plot of both parts with Rs = 0, 10k, and 100k.
As you can see, both parts are thermal noise limited down to 0.1 Hz for up to Rs = 100k or greater. Given that the broadband current noise level for each part is ~0.5-1 fA/rtHz, this puts an upper limit to the 1/f corner of <100 Hz. This is where the AD743 corner is, so that sounds reasonable. Perhaps I will check with even higher impedance to see if I can find it. I am not sure yet what to make of the ~10-20 kHz instability with high source impedance.
EDIT: The datasheets claim that they are Johnson noise limited up to 1 Mohm, but this is only for the broadband floor, I'd guess, so it doesn't really say anything about the low frequency corner.
This looks pretty good already. Not sure if we can even measure anything reasonable below 0.1 Hz without a lot of thermal shielding.
The 10-20 kHz oscillation may just be the loop shape of the opamp. I think you saw similar effects when using the AD743 with high impedance for the OSEM testing.
There has been an ongoing memory error in optimus with the following messages:
Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705127] [Hardware Error]: Corrected error, no action required.
Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705174] [Hardware Error]: CPU:24 (10:4:2) MC4_STATUS[Over|CE|MiscV|-|AddrV|CECC]: 0xdc04410032080a13
Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705237] [Hardware Error]: MC4_ADDR: 0x0000001ad2bd06d0
Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705264] [Hardware Error]: MC4 Error (node 6): DRAM ECC error detected on the NB.
Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705323] [Hardware Error]: cache level: L3/GEN, mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout)
Optimus is a Sun Fire X4600 M2 Split-Plane server. Based on this message, the issue seems to be in memory controller (MC) 6, chip set row (csrow) 7, channel 0. I got this same result again after installing edac-utils and running edac-util -v, which gave me:
mc6: csrow7: mc#6csrow#7channel#0: 287 Corrected Errors
and said that all other DIMMs were working fine with 0 errors. Each MC has 4 csrows numbered 4-7. I shut off optimus and checked inside and found that it consists of 8 CPU slots lined up horizontally, each with 4 DIMMs stacked vertically and 4 empty DIMM slots beneath. I'm thinking that each of the 8 CPU slots has its own memory controller (0-7) and that the csrow corresponds to the position in the vertical stack, with csrow 7 being the topmost DIMM in the stack. This would mean that MC 6, csrow 7 would be the 7th memory controller, topmost DIMM. The channel would then correspond to which one of the DIMMs in the pair is faulty although if the DIMM was replaced, both channels 0 and 1 would be switched out. Here are some sources that I used:
I'll find the exact part needed to replace soon.
Optimus' memory errors are back so I found the exact DIMM model needed to replace: http://www.ebay.com/itm/Lot-of-10-Samsung-4GB-2Rx4-PC2-5300P-555-12-L0-M393T5160QZA-CE6-ECC-Memory-/201604698112?hash=item2ef0939000:g:EgEAAOSwqBJXWFZh I'm not sure what website would be the best for buying new DIMMs but this is the part we need: Samsung 4GB 2Rx4 PC2-5300P-555-12-L0 M393T5160QZA-CE6.
I replaced the suspected faulty DIMM earlier today (actually I replaced a pair of them as per the Sun Fire X4600 manual). I did things in the following sequence, which was the recommended set of steps according to the maintenance manual and also the set of graphics on the top panel of the unit:
I then checked for memory errors using edac-utils, and over the last couple of hours, found no errors (corrected or otherwise, see Praful's earlier elog for the error messages that we were getting prior to the DIMM swap)- I guess we will need to monitor this for a while more before we can say that the issue has been resolved.
Looking at dmesg after the reboot, I noticed the following error messages (not related to the memory issue I think):
[ 19.375865] k10temp 0000:00:18.3: unreliable CPU thermal sensor; monitoring disabled
[ 19.375996] k10temp 0000:00:19.3: unreliable CPU thermal sensor; monitoring disabled
[ 19.376234] k10temp 0000:00:1a.3: unreliable CPU thermal sensor; monitoring disabled
[ 19.376362] k10temp 0000:00:1b.3: unreliable CPU thermal sensor; monitoring disabled
[ 19.376673] k10temp 0000:00:1c.3: unreliable CPU thermal sensor; monitoring disabled
[ 19.376816] k10temp 0000:00:1d.3: unreliable CPU thermal sensor; monitoring disabled
[ 19.376960] k10temp 0000:00:1e.3: unreliable CPU thermal sensor; monitoring disabled
[ 19.377152] k10temp 0000:00:1f.3: unreliable CPU thermal sensor; monitoring disabled
I wonder if this could explain why the fans on Optimus often go into overdrive and make a racket? For the moment, the fan volume seems normal, comparable to the other SunFire X4600s we have running like megatron and FB...
I did apt-get update and then apt-get upgrade on optimus. All systems are nominal.
Assembled is the list of dead pressure gauges. Their locations are also circled in Attachment 1.
For replacements, I recommend we consider the Agilent FRG-700 Pirani Inverted Magnetron Gauge. It uses dual sensing techniques to cover a broad pressure range from 3e-9 torr to atmosphere in a single unit. Although these are more expensive, I think we would net save money by not having to purchase two separate gauges (Pirani + hot/cold cathode) for each location. It would also simplify the digital controls and interlocking to have a streamlined set of pressure readbacks.
For controllers, there are two options with either serial RS232/485 or Ethernet outputs. We probably want the Agilent XGS-600, as it can handle all the gauges in our system (up to 12) in a single controller and no new software development is needed to interface it with the slow controls.
Now that the new Agilent full-range gauges (FRGs) have been received, I'm putting together an installation plan. Since my last planning note in Sept. (ELOG 15577), two more gauges appear to be malfunctioning: CC2 and PAN. Those are taken into account, as well. Below are the proposed changes for all the sensors in the system.
Update to the gauge replacement plan (15692), based on Jordan's walk-through today. He confirmed:
Based on this info (and also info from Gautam that the PAN gauge is still working), I've updated the plan as follows. In summary, I now propose we install the fifth FRG in the TP1 foreline (PTP1 location) and leave P2 and P3 where they are, as they are no longer needed elsewhere. Any comments on this plan? I plan to order all the necessary gaskets, blanks, etc. tomorrow.
The 24 V Sorenson (2nd from bottom) in the small rack west of 1x2 was repurposed to 12V 600 mA, and was run to a terminal block on the north side of 1X1. Cables were routed underneath 1X1 and 1X2 to the terminal blocks. 12V was then routed to the PSL table and banana clip terminals were added.
For the 40m Upgrade, we plan to eliminate the Mach-Zehnder and replace it with a single EOM driven by all three modulation frequencies that we'll need: f1=11MHz, f2=5*f1=55MHz, fmc=29.5MHz.
A frequency generator will produce the three frequencies and with some other electronics we'll properly combine and feed them to the EOM.
The frequency generator will have two crystals to produce the f1 and fmc signals. The f2 modulation will be obtained by a frequency multiplier (5x) from the f1.
The frequency multiplier, for the way it works, will inevitably introduce some unwanted harmonics into the signals. These will show up as extra modulation frequencies in the EOM.
In order to quantify the effects of such unwanted harmonics on the interferometer and thus to let us set some limits on their amplitude, I ran some simulations with Optickle. The way the EOM is represented is by three RF modulators in series. In order to introduce the unwanted harmonics, I just added an RF modulator in series for each of them. I also made sure not to leave any space in between the modulators, so not to introduce phase shifts.
To check the effect at DC I looked at the sensing matrix and at the error signals. I considered the 3f error signals that we plan to use for the short DOFs and looked at how they depend on the CARM offset. I repeated the simulations for several possible amplitude of the unwanted harmonics. Some results are shown in the plots attached to this entry. 'ga' is the amplitude ratio of the unwanted harmonics relative to the amplitude of the 11 & 55 MHz modulations.
Comparing to the case where there are no unwanted harmonics (ga = 0), one can see that not considerable effect on the error signals for amplitudes 40dB smaller than that of the main sidebands. Above that value, the REFL31I signals, that we're going to use to control PRCL, will start to be distorted: gain and linearity range change.
So 40 dB of attenuation in the unwanted harmonics is probably the minimum requirement on the frequency multiplier, although 60dB would provide a safer margin.
I'm still thinking how to evaluate any AC effect on the IFO.
** TODO: Plot DC sweeps with a wider range (+/- 20 pm). Also plot swept sines to look for changes in TFs out to ~10 kHz.
I re-routed around the c1lsc machine this morning. I turned the crate off, and disconnected the transmission fiber from c1lsc (which went to the receiver on c1asc). I then took the receiving fiber from c1lsc and plugged it into the receiver on c1asc.
I pulled out the c1lsc computer from the VME crate and pulled out the RFM card, which I needed for the CDS upgrade. I then replaced the lsc card back in the crate and turned it back on. Since there hasn't been a working version of the LSC code on linux1 since I overwrote it with the new CDS lsc code, this shouldn't have any significant impact on the interferometer.
I've confirmed that the RFM network seems to be in a good state (the only red lights on the RFM timing and status medm screen are LSC, ASC, and ETMX). Fast channels can still be seen with dataviewer and fb40m appears to still be happy.
The RFM card has found its new home in the SUS IO Chassis. The short fiber that used to go between c1asc and c1lsc is now on the top shelf of the new 1X3 rack.
I just realized that an unfortunate casualty of this LSC work was the deletion of the slow controls for the LSC which we still use (some sort of AUX processor). For example, the modulation
depth slider for the MC is now in an unknown state.
If you're refering to just the medm screen, those can be restored from the SVN. As we're moving to a new directory structure, starting with /opt/rtcds/caltech/c1/, the old LSC screens can all be put back in the /cvs/cds/caltech/medm/c1/lsc directory if desired.
The slow lsc aux crate, c1iscaux2, is still working, and those channels are still available. I confirmed that one was still updating. As a quick test, I went to the SVN and pulled out the C1LSC_RFADJUST.adl file, renamed it to C1LSC_RFadjust.adl and placed it in /cvs/cds/caltech/medm/c1/lsc/, and checked it linked properly from the C1IOO_ModeCleaner.adl file. I haven't touched the modulation depths, as I didn't want to mess with the mode cleaner, but if I get an OK, we can test that today and confirm that modulation depth control is still working.
Fridge brought back inside.
It happened again. Defrosting required.
After Koji and I reset the transmission normalizations last Friday, he did some alignment work that increased the Yarm power. So, I had set the transmission normalization when we weren't really at full Yarm power. Today I reset the normalization so that instead of ~1.2, the Y transmission PDs read ~1.0.
OD = 0.0036" = 0.091 mm
Length = 46" = 1168.4 mm
Resistance = 33.3 Ohms
resistivity = R * pi * (OD/2)^2
----------------- = 1.85e-7 Ohm-meters
resistivity (Ohm-meter x 10^-7)
304 Stainless 7.2
316 Stainless 7.4
Cast Steel 1.6
Is it because of the change in the resonant frequency of the BS-PRM stack? How much the load on BS-PRM changed?
Or is it because of the change in the resonant frequency of PR2/PR3
I claim that neither of those things is plausible. We took out 1 PZT, and put in 1 active TT onto the BS table. There is no way the resonant frequency changed by an appreciable amount due to that switch.
I don't think that it is the resonant frequency of the TTs either. Here, I collate the data that we have on the resonant frequencies of our tip tilts. It appears that in elog 3425 I recorded results for TTs 2 and 3, but in elog 3447 I just noted that the measurements had been done, and never put them into the elog. Ooops.
Resonant frequency and Q of modes of passive tip tilts.
Notes: "Serial Number" of TTs here is based on the SN of the top suspension point block. This does not give info about which TT is where. Pitch modes were all too low of Q to be measured, although we tried.
Tip tilt mode measurements were taken with a HeNe and PD shadow sensor setup - the TT's optic holder ring was partially obscuring the beam.
Every so often things just work out. You do the calculations, you put the lenses on the bench, you manually adjust the pointing and fiddle with the lenses a bit, you get massive chunks of assistance from Kiwamu to get the alignment controls and monitors set up and after quite a bit of fiddling and tweaking the cavity mirror alignment you might get some nice TEM_00 -like shapes showing up on your Y-arm video monitors.
So. We have resonating green light in the Y-arm. The beam is horribly off-axis and the mode-matching, while close enough to give decent looking spots, has in no way been optimised yet. Things to do tomorrow - fix the off-cavity-axis problem and tweak up the mode-matching... then start looking at the locking...
Koji asked me to perform a simulation of the response of POP QPD DC signal to mirror motions, as a function of the CARM offset. Later than promised, here are the first round of results.
I simulated a double cavity, and the PRC is folded with parameters close to the 40m configuration. POP is extracted in transmission of PR2 (1ppm, forward beam). For the moment I just placed the QPD one meter from PR2, if needed we can adjust the Gouy phase. There are two QPDs in the simulation: one senses all the field coming out in POP, the other one is filtered to sense only the contribution from the carrier field. The difference can be used to compute what a POP_2F_QPD would sense. All mirrors are moved at 1 Hz and the QPD signals are simulated:
This shows the signal on the POP QPD when all fields (carrier and 55 MHz sidebands) are sensed. This is what a real DC QPD will see. As expected at low offset ETM is dominant, while at large offset the PRC mirrors are dominant. It's interesting to note that for any mirror, there is one offset where the signal disappears.
This is the contribution coming only from the carrier. This is what an ideal QPD with an optical low pass will sense. The contribution from the carrier increases with decreasing offset, as expected since there is more power.
Finally, this is what a 2F QPD will sense. The contribution is always dominated by the PRC mirrors, and the ETM is negligible.
The zeros in the real QPD signal is clearly coming from a cancellation of the contributions from carrier and sidebands.
The code is attached.
const Pin 1 # input power
const Lprc 6.752 # power recycling cavity length
const d_BS_PR3 0.401 # folding mirror distances
const d_PR2_PR3 2.081
const d_PRM_PR2 1.876
const c 299792458 # speed of light
const fmod 5*c/(4*Lprc) # modulation frequency, matched to Lprc
% compile simulation class
m = MIST('foldeddoublecavity.mist');
% create simulation object
s = FoldedDoubleCavity(8);
% set angulat motion
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.
Amplitude of 29.485MHz input sine wave [dBm] | Value of channel C1:IOO-MC_DEMOD_LO
-------------------------------------------- | -----------------------------------
-10 | -0.000449867
-8 | -0.000449867
-6 | -0.000449867
-4 | 0.000384331
-2 | 0.00526733
0 | 0.0199163
2 | 0.0492143
4 | 0.0931613
6 | 0.161523
8 | 0.229885
10 | 0.293364
I restarted the frame builder at the following times
Tue Sep 13 14:53:49 PDT 2011
Tue Sep 13 16:46:32 PDT 2011
Tue Sep 13 17:24:16 PDT 2011
Restarted backup since fb40m was rebooted.