40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 205 of 330  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  16534   Wed Dec 22 18:16:23 2021 KojiUpdateSUSRemaining task for 2021

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)

Attachment 1: ITMX_2016_07_21.jpg
ITMX_2016_07_21.jpg
Attachment 2: Screen_Shot_2021-12-22_at_18.03.42.png
Screen_Shot_2021-12-22_at_18.03.42.png
  2074   Fri Oct 9 03:53:56 2009 JenneUpdateAdaptive FilteringRemaking the ASS

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.

  11563   Thu Sep 3 00:45:25 2015 IgnacioUpdateIOORemeasured MC2 to MCL TF + Improved subtraction performance

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.

Attachment 1: TF.zip
  8498   Fri Apr 26 20:43:51 2013 JenneUpdateLSCRemeasuring the Schnupp asymmetry

[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

  8528   Fri May 3 17:32:59 2013 JenneUpdateLSCRemeasuring the Schnupp asymmetry

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.

 Xarm_SchnuppData_April2013.png

Yarm_SchnuppData_April2013.png

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).

  1738   Mon Jul 13 15:48:05 2009 ranaOmnistructureEnvironmentRemoval of the cold air deflection device for the MOPA chiller
Around 2 PM today, I removed the blue flap which has been deflecting the cold air from the AC down into the laser chiller.
Let's watch the laser trends for a few days to see if there's any effect.
  1740   Mon Jul 13 23:03:14 2009 rob, albertoOmnistructureEnvironmentRemoval of the cold air deflection device for the MOPA chiller

Quote:
Around 2 PM today, I removed the blue flap which has been deflecting the cold air from the AC down into the laser chiller.
Let's watch the laser trends for a few days to see if there's any effect.


Alberto has moved us to stage 2 of this experiment: turning off the AC.

The situation at the control room computers with the AC on minus the blue flap is untenable--it's too cold and the air flow has an unpleasant eye-drying effect.
  1741   Tue Jul 14 00:32:46 2009 rob, albertoOmnistructureEnvironmentRemoval of the cold air deflection device for the MOPA chiller

Quote:

Quote:
Around 2 PM today, I removed the blue flap which has been deflecting the cold air from the AC down into the laser chiller.
Let's watch the laser trends for a few days to see if there's any effect.


Alberto has moved us to stage 2 of this experiment: turning off the AC.

The situation at the control room computers with the AC on minus the blue flap is untenable--it's too cold and the air flow has an unpleasant eye-drying effect.


I turned the AC back on because the temperature of the room was going up so also that of the laser chiller.
  1745   Tue Jul 14 17:48:20 2009 JenneOmnistructureEnvironmentRemoval of the cold air deflection device for the MOPA chiller

Quote:

Quote:

Quote:
Around 2 PM today, I removed the blue flap which has been deflecting the cold air from the AC down into the laser chiller.
Let's watch the laser trends for a few days to see if there's any effect.


Alberto has moved us to stage 2 of this experiment: turning off the AC.

The situation at the control room computers with the AC on minus the blue flap is untenable--it's too cold and the air flow has an unpleasant eye-drying effect.


I turned the AC back on because the temperature of the room was going up so also that of the laser chiller.


I reinstalled the blue-flap technology on the AC, because the MOPA power was dropping like a rock. A light-ish rock since it wasn't going down too fast, but the alarms started going a little while ago because PMC trans was too low, because the power was getting a little low. The laser water chiller is reading 21.97C, which is higher than it normally does/did before the AC shenanigans (It usually reads 20.00C).

Attached is a look-back of 18 hours, during which you can see in the AMPMON the time that Rana removed the blue flap around 2pm yesterday and the AMPMON changes a little bit, but not drastically, the time around 11pm when the AC was turned off, and AMPMON goes down pretty fast, and about 12:30am, when Alberto turned the AC back on, and AMPMON starts to recover. I think that the AMPMON starts to go down again in the morning because it's been crazy hot here in Pasadena, so the room might be getting warmer, especially with the laser chiller-chiller not actively chilling the laser chiller (by not being pointed at the water chiller), so the water isn't getting as cold, and the HTEMP started to go up.

In the last few minutes of having put the blue flap back on the AC, the laser chiller is already reading a lower temperature, and the AMPMON is starting to recover.
Attachment 1: ACeffectonLASER2.png
ACeffectonLASER2.png
  572   Thu Jun 26 10:56:15 2008 Max JonesUpdatePEMRemoved Magnetometer
I removed the Bartington Magnetometer on the x arm to one of the outside benches. I'll be trying to determine if and how it works today. It makes a horrible high pitched sound which is due to the fact that the battery is probably 16 yrs old. It still works with ac power though and I want to see if it is still operating correctly before I ask to buy a new battery. Sorry for the bother.
  7246   Tue Aug 21 22:54:47 2012 JenneUpdateLockingRemoved beam dump from POY path

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.

  4561   Fri Apr 22 12:07:38 2011 josephb, steveUpdateCDSRemoved hanging D-sub to SCSI in 1X2

Problem:

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.

Solution:

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.

  4590   Fri Apr 29 14:36:36 2011 josephb, steveUpdateCDSRemoved hanging D-sub to SCSI in 1X5

Quote:

Problem:

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.

Solution:

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.

Attachment 1: P1070621.JPG
P1070621.JPG
  3080   Wed Jun 16 11:31:19 2010 josephbSummaryComputersRemoved scaling fonts from medm on Allegra

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.

  2806   Mon Apr 19 07:38:07 2010 ranaHowToElectronicsRepair and Calibration of SR560: s/n 59650

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:

  1. It can sometimes be that the gain proscribed by the manual is too high and saturates the output for large offsets. If that's the case, simply lower the gain, trim the offset, then return the gain to the specified value and trim again.
  2. The limit in trimming the offset is the stick slip resolution in the trim pot. This can potentially leave the whole preamp in an acoustically sensitive state. I tapped the pots with a screwdriver after tuning to make sure it was in more of a 'sticky' rather than 'slippy' region of the knob. A better design would allow for more filtering of the pot.
  3. In the CMRR tuning procedure it says to 'null sine wave output' but it should really say 'null the sine wave component at the drive frequency'. The best CMRR tuning uses a 1 kHz drive and leaves a residual 2 kHz signal due to the distortion imbalance (of the FETs I think).
  4. The CMRR tuning upsets the DC offset trim and vice versa. The best tuning is gotten by iterating slightly (go back and forth once or twice between the offset and CMRR tuning procedures).

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:

Input referred noise (nV/rHz)
f e_n

0.1

200
1 44
10 8
100 5
1000 5
10000 4
  9560   Thu Jan 16 21:38:13 2014 ericqUpdateLSCRepeat of PRC length measurement

[ericq,Jenne]

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. 

  15966   Thu Mar 25 16:02:15 2021 gautamSummarySUSRepeated measurement of coil Rs & Ls for PRM/BS

Method

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).

Result

                   PRM
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

                       BS
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

Conclusions

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:

  1. Magnets on PRM are weird in some way. Note that the free-swinging measurement for the PRM showed some unexpected features.
  2. The imbalance is coming from one of the drive chain - could be a busted current buffer for example.
  3. The measurement technique was wrong.
  9335   Mon Nov 4 12:07:55 2013 DmassOmnistructureGeneralReplaced Broken Drill Bits

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

  9202   Fri Oct 4 12:33:27 2013 MasayukiUpdateSUSReplaced the laser for Optical Lever of ETMY

[Steve, Masayuki]

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

Attachment 1: OPLEV_SUM.pdf
OPLEV_SUM.pdf
Attachment 2: ETMYoplev.png
ETMYoplev.png
  9203   Fri Oct 4 14:36:44 2013 ranaUpdateSUSReplaced the laser for Optical Lever of ETMY

  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.

  9206   Sun Oct 6 18:37:43 2013 ranaUpdateSUSReplaced the laser for Optical Lever of ETMY

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.

web-burnt-toast.jpg

  9212   Mon Oct 7 10:51:18 2013 SteveUpdateSUSReplaced the laser for Optical Lever of ETMY

 Just plot.

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?

Attachment 1: ETMXoplevETMY.png
ETMXoplevETMY.png
Attachment 2: oplevSettings.png
oplevSettings.png
  8125   Wed Feb 20 23:25:50 2013 ZachSummaryElectronicsReplacement for the AD743: OPA140 and OPA827

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:

  • Input current noise @ 1kHz
    • AD743: 6.9 fA/rtHz
    • OPA827: 2.2 fA/rtHz
    • OPA140: 0.8 fA/rtHz (!)
  • Input bias (offset) current, typ
    • AD743: 30 pA (40 pA) --- only for Vsupply = ±5 V
    • OPA827: ±3 pA (±3 pA) --- up to ±18V
    • OPA140: ±0.5 pA (±0.5 pA) (!) --- up to ±18V
  • Supply
    • Both OPA140 and OPA827 can be fed single supplies up to 36V absolute maximum
    • The OPA140 is a rail-to-rail op amp

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.

 ULN_opamp_comparison_2_20_13.png

(Apologies---the SR785 I was using had some annoying non-stationary peaks coming in. I verified that they did not affect the broadband floor).

R.I.P., AD743

  8151   Sat Feb 23 18:01:38 2013 ZachSummaryElectronicsReplacement for the AD743: OPA140 and OPA827

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.

OPA140_OPA827_noise_vs_Rs.png

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.

Screen_Shot_2013-02-24_at_12.12.23_PM.png Screen_Shot_2013-02-24_at_12.12.43_PM.png

Quote:

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.

 

  8153   Sun Feb 24 16:49:00 2013 ranaSummaryElectronicsReplacement for the AD743: OPA140 and OPA827

  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.

  12239   Fri Jul 1 17:51:28 2016 PrafulSummaryElectronicsReplacing DIMM on Optimus

There has been an ongoing memory error in optimus with the following messages:

controls@optimus|~ >
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:

http://docs.oracle.com/cd/E19121-01/sf.x4600/819-4342-18/html/z40007f01291423.html#i1287456

https://siliconmechanics.zendesk.com/hc/en-us/articles/208891966-Identify-Bad-DIMM-from-EDAC

http://martinstumpf.com/how-to-diagnose-memory-errors-on-amd-x86_64-using-edac/

I'll find the exact part needed to replace soon.

  12275   Fri Jul 8 15:44:07 2016 PrafulUpdateElectronicsReplacing DIMM on Optimus

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.

  12613   Mon Nov 14 14:21:06 2016 gautamSummaryCDSReplacing DIMM on Optimus

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:

  1. Checked that Optimus was shut down
  2. Removed the power cables from the back to cut the standby power. Two of the fan units near the front of the chassis were displaying fault lights, perhaps this has been the case since the most recent power outage after which I did not reboot Optimus
  3. Took off the top cover, removed CPU 6 (labelled "G" in the unit). The manual recommends finding faulty DIMMs by looking for an LED that is supposed to indicate the location of the bad card, but I couldn't find any such LEDs in the unit we have, perhaps this is an addition to the newer modules?
  4. Replaced the topmost (w.r.t the orientation the CPU normally sits inside the chassis) DIMM card with one of the new ones Steve ordered
  5. Put everything back together, powered Optimus up again. Reboot went smoothly, fan unit fault lights which I mentioned earlier did not light up on the reboot so that doesn't look like an issue.

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...

  12615   Mon Nov 14 19:32:51 2016 ranaSummaryCDSReplacing DIMM on Optimus

I did apt-get update and then apt-get upgrade on optimus. All systems are nominal.

  15577   Wed Sep 16 12:03:07 2020 JonUpdateVACReplacing pressure gauges

Assembled is the list of dead pressure gauges. Their locations are also circled in Attachment 1.

Gauge Type Location
CC1 Cold cathode Main volume
CC3 Cold cathode Pumpspool 
CC4 Cold cathode RGA chamber
CCMC Cold cathode IMC beamline near MC2
P1b Pirani Main volume
PTP1 Pirani TP1 foreline

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.

Attachment 1: vac_gauges.png
vac_gauges.png
  15692   Wed Dec 2 12:27:49 2020 JonUpdateVACReplacing pressure gauges

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.

In summary:

  • Four of the FRGs will replace CC1/2/3/4.
  • The fifth FRG will replace CCMC if the 15.6 m cable (the longest available) will reach that location.
  • P2 and P3 will be moved to replace PTP1 and PAN, as they will be redundant once the new FRGs are installed.

Required hardware:

  • 3x CF 2.75" blanks
  • 10x CF 2.75" gaskets
  • Bolts and nut plates
Volume Sensor Location Status Proposed Action
Main P1a functioning leave
Main P1b local readback only leave
Main CC1 dead replace with FRG
Main CCMC dead replace with FRG*
Pumpspool PTP1 dead replace with P2
Pumpspool P2 functioning replace with 2.75" CF blank
Pumpspool CC2 intermittent replace with FRG
Pumpspool PTP2 functioning leave
Pumpspool P3 functioning replace with 2.75" CF blank
Pumpspool CC3 dead replace with FRG
Pumpspool PTP3 functioning leave
Pumpspool PRP functioning leave
RGA P4 functioning leave
RGA CC4 dead replace with FRG
RGA IG1 dead replace with 2.75" CF blank
Annuli PAN intermittent replace with P3
Annuli PASE functioning leave
Annuli PASV functioning leave
Annuli PABS functioning leave
Annuli PAEV functioning leave
Annuli PAEE functioning leave

 

Quote:

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.

 

  15703   Thu Dec 3 14:53:58 2020 JonUpdateVACReplacing pressure gauges

Update to the gauge replacement plan (15692), based on Jordan's walk-through today. He confirmed:

  • All of the gauges being replaced are mounted via 2.75" ConFlat flange. The new FRGs have the same footprint, so no adapters are required.
  • The longest Agilent cable (50 ft) will NOT reach the CCMC location. The fifth FRG will have to be installed somewhere closer to the X-end.

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.

Volume Sensor Location Status Proposed Action
Main P1a functioning leave
Main P1b local readback only leave
Main CC1 dead replace with FRG
Main CCMC dead remove; cap with 2.75" CF blank
Pumpspool PTP1 dead replace with FRG
Pumpspool P2 functioning leave
Pumpspool CC2 dead replace with FRG
Pumpspool PTP2 functioning leave
Pumpspool P3 functioning leave
Pumpspool CC3 dead replace with FRG
Pumpspool PTP3 functioning leave
Pumpspool PRP functioning leave
RGA P4 functioning leave
RGA CC4 dead replace with FRG
RGA IG1 dead remove; cap with 2.75" CF blank
Annuli PAN functioning leave
Annuli PASE functioning leave
Annuli PASV functioning leave
Annuli PABS functioning leave
Annuli PAEV functioning leave
Annuli PAEE functioning leave
  15158   Mon Jan 27 14:01:01 2020 JordanConfigurationGeneralRepurposed Sorenson Power Supply

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.

  1681   Tue Jun 16 20:03:41 2009 AlbertoUpdateElectronicsRequirements on Wenzel Multiplier

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.

Attachment 1: SummaryOfResult.pdf
SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf
  3274   Fri Jul 23 10:16:44 2010 josephbUpdateCDSRerouted RFM around c1lsc, took RFM card out of c1lsc

 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.

  3283   Fri Jul 23 21:35:48 2010 ranaUpdateCDSRerouted RFM around c1lsc, took RFM card out of c1lsc

 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.

  3289   Mon Jul 26 10:02:42 2010 josephbUpdateCDSRerouted RFM around c1lsc, took RFM card out of c1lsc

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.

Quote:

 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.

 

  16340   Thu Sep 16 20:18:13 2021 AnchalUpdateGeneralReset

Fridge brought back inside.

Quote:

Put outside.

Quote:

It happened again. Defrosting required.

 

 

Attachment 1: PXL_20210917_031633702.jpg
PXL_20210917_031633702.jpg
  10743   Mon Dec 1 17:43:22 2014 JenneUpdateLSCReset Yarm trans normalization

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.

  1021   Thu Oct 2 18:56:19 2008 ranaSummarySUSResistivity of Suspension Wire
Bob and Steve measured the resistance of the suspension wire today:
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
                  Length 


This was a batch of California Fine Wire from 2001 (same as used at LHO and LLO).

By comparison the standard tabulated resistivity for steels is (http://hypertextbook.com/facts/2006/UmranUgur.shtml):
                  resistivity (Ohm-meter x 10^-7)
-------------     ----------------
304 Stainless       7.2
316 Stainless       7.4
Cast Steel          1.6

This is all to see whether or not the 60 Hz fields produce forces on the suspension wires via coupling with the Earth's DC field.

TBD
  888   Tue Aug 26 18:19:16 2008 ranaOmnistructureElectronicsResistor Noise at the 40m
As Stefan points out in his recent ISS ilog entries at LLO, Daniel Sigg recently wrote a
recommendation memo on resistor and capacitor
choices: T070016.

While working on the PMC I have had to use leaded resistors and wondered about the noise. As it turns
out we have the RN series of 1/4 W resistors from Stackpole Electronics. The RN series are
metal film resistors (datasheet attached); metal film is what Sigg recommends for lowest flicker
noise.

So we are OK for using the Stackpole 1/4 W leaded resistors in low noise circuits.
Attachment 1: SEI-RN_RNM.pdf
SEI-RN_RNM.pdf SEI-RN_RNM.pdf
  37   Wed Oct 31 09:45:28 2007 waldmanOtherOMCResolution to DAQland saga
[Jay, Sam]

We did a rough accounting for the linear delay this morning and it comes out more or less correct. The 10 kHz 3rd order butterworth AA/AI filter gives ~90 degrees of phase at 6 kHz, or 42 microseconds. Taken together, the two AA and AI filters are worth 80 microseconds. The 1.5 sample digital delay is worth 1.5/32768 = 45 microseconds. The remaining 160 - 125 = 35 microseconds is most likely taken up by the 64 kHz to 32 kHz decimation routine, assuming this isn't accounted for already in the 1.5 sample digital delay.

It remains to be seen whether this phase delay is good enough to lock the laser to the OMC cavity
  8054   Mon Feb 11 12:49:54 2013 JenneSummaryLSCResonant freq change - why? (and passive TT mode freqs)

Quote:

  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. 

  Vertical Yaw Pos Side
TT1 f0=20, Q=18 f0=1.89, Q=3.8 f0=1.85, Q=2 f0=1.75, Q=3.2
TT2 f0=24, Q=7.8 f0=1.89, Q=2.2 f0=1.75, no Q meas f0=1.8, Q=4.5
TT3 f0=20, Q=34 f0=1.96, Q="low" f0=1.72, Q=3.3 f0=1.85, Q=6
TT4 f0=21, Q=14 f0=1.88, Q=2.3 f0=1.72, Q=1.4 f0=1.85, Q=1.9
TT5 f0=20, Q=22.7 no measurement f0=1.79, Q=1.8 f0=1.78, Q=3.5

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.

  4495   Wed Apr 6 22:13:24 2011 BryanConfigurationGreen LockingResonating green light!

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...

  10278   Sat Jul 26 14:45:33 2014 GabrieleMetaphysicsASCResponse of POP QPD

 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:

pop_qpd_all.png

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.

pop_qpd_carrier.png

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.

pop_qpd_sb.png

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.

Attachment 4: foldeddoublecavity.mist
classname FoldedDoubleCavity

# parameters
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
... 51 more lines ...
Attachment 5: pop_qpd.m
% compile simulation class
clear classes
m = MIST('foldeddoublecavity.mist');

% create simulation object
s = FoldedDoubleCavity(8);

% set angulat motion
s.PRM.setMotionShape('pitch');
s.PR2.setMotionShape('pitch');
... 85 more lines ...
  10888   Tue Jan 13 01:11:51 2015 diegoUpdateLSCResponse of error signals to MICH EXC

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.

 

 

Attachment 1: MICH_to_REFL33Q_ASDC_12Jan2015_1.pdf
MICH_to_REFL33Q_ASDC_12Jan2015_1.pdf
Attachment 2: MICH_to_REFL33Q_ASDC_12Jan2015_2.pdf
MICH_to_REFL33Q_ASDC_12Jan2015_2.pdf
Attachment 3: MICH_to_REFL33Q_ASDC_12Jan2015_3.pdf
MICH_to_REFL33Q_ASDC_12Jan2015_3.pdf
  585   Fri Jun 27 18:21:01 2008 JenneUpdateElectronicsResponse of the LO input on the MC demod board
The alarm handler has been flipping out saying that the LO input of the MC's demod board is too low, so at Rana's suggestion, Eric and I measured the response of the LO input. We used an SR345 function generator at 29.485MHz and several different amplitudes to make a table. The demod board should see an input from the LO between 0-2dBm. When I measured what was going into the LO input from the 29.5MHz delay line phase shifter, the LO input was seeing 4dBm. I'm going to put a 3dB attenuator between the phase shifter and the demod board.

Also, now that we have this table of response values, I'm going to change the settings of the alarm handler to something more reasonable.
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
  275   Sat Jan 26 18:48:43 2008 JohnSummaryComputersRestart iscepics
iscepics died this afternoon. We restarted it and restored settings from yesterday. I've written up instructions in the wiki.
  5396   Tue Sep 13 19:04:58 2011 SureshUpdateComputer Scripts / ProgramsRestarted Frame builder several times while compiling c1ioo, c1mcs and c1rfm

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

  1564   Fri May 8 10:05:40 2009 AlanOmnistructureComputersRestarted backup since fb40m was rebooted

Restarted backup since fb40m was rebooted.

ELOG V3.1.3-