15 hours

[ericq,gautam]

Forgot to submit this yesterday...

While we were trying to get the X-arm locked to IR using MC2, frame-builder mysteriously crashed, necessitating us having to go down to the computer and perform a hard reboot (after having closed the PSL shutter and turning all the watchdogs to "shutdown"). All the models restarted by themselves, and everything seems back to normal now..

we did a hard reboot of c1susvme1, c1susvme2, c1sosvme, and c1susaux.  We are hoping this will fix some of the weird suspension issues we've been having (MC3 side coil, ITMX alignment).

I worked with Kevin and Gautam to create a heater circuit. The first attachment is Kevin's schematic of the circuit. The OP amp connects to the gate of the power MOSFET, and the power supply connects to the drain, while the source goes into the heater. We set the power supply voltage to 22V and varied the voltage of the input to the OP amp. At 6V to the OP amp, we got a current of 0.35A flowing through the heater and resistor. This was the peak current we got due to the OP amp being saturated (an increase in either of the power supplies did not change the current), but when we increased the voltage of the supply rails of the OP amp from 15V to 20V, we got a current of 0.5A. We would want a higher current than this, so we will need to get a different OP amp with a higher max voltage rating, and a resistor that can take more power than this one (it currently takes 5W of power, and is the best one we could find).

Kevin and I created a simulation of this circuit using CircuitLab to understand why the current was so low (second attachment). The horizontal axis is the voltage we supply to the OP amp. The blue line shows the voltage at the point between the output of the OP amp and the gate of the MOSFET. The orange line is the voltage at the point between the source of the MOSFET and the heater. The brown line is the voltage at the point between the heater and resistor. Thus, we can see that saturation occurs at about 2.1V. At that point, the gate-source voltage is the difference between the blue curve and the orange curve, which is about 4V, which is what we measured. Likewise, the voltage across the heater is the difference between the orange curve and the brown curve, which comes out to around 8V, which is also what we measured. Lastly, the voltage across the resistor is the brown curve, which is about 2V, which matches our observations. The circuit works as it should, but saturates too soon to get a high enough current out of it.

Gautam noted that it is important to measure the current correctly. We can't just use an ammeter and place it across the resistor or heater, because the internal resistance of the ammeter (~0.5 ohm) is comparable to the resistance we want to measure, so the current gets split between the circuit and the ammeter and we get an equivalent resistance of 1/R = 1/R0 + 1/Ra, where R0 is the resistance of the part we want to measure the current across, and Ra is the ammeter resistance. Thus, the new resistance will be lower and the ammeter will show a higher current value than what is actually there. So to accurately measure the current, we must place the ammeter in series with the part we want to measure. We initially got a 1A reading on the heater, which was not correct, and our setup did not heat up at all basically. When we placed the ammeter in series with the heater, we got only 0.35A.

The last two images are the setup for testing of the heater. We wrapped it around an aluminum piece and covered it with a few layers of insulating material. We can stick a thermometer in between the insulation and heater to see the temperature change. In later tests, we may insulate the whole piece so that less heat gets dissipated. In addition, we used a heat sink and thermal paste to secure the MOSFET to it, as it got very hot.

Our next steps will be to get a resistor and an OP amp that are better suited for our purposes. We will also run simulations with components that we choose to make sure that it can provide the desired current of 1A (the maximum output of the power supply is 24V, and the heater is 24 ohm, so max current is 1A). Kevin is working on that now.

I decided to calculate the fluctuation in power that we will have in the heater circuit. The resistors we ordered have 50 ppm/C and it would be useful to know what kind of fluctuation we would expect. For this, I assumed that the heater itself is an ideal resistor that has no temperature variation. The circuit diagram is found in Kevin's elog here. At saturation, the total resistance (we will have a  resistor instead of  for our new design) will be . Therefore, with a 24V input, the saturation current should be .  Therefore, the power in the heater should be (in the ideal case) 

Now, in the case where the resistor is not ideal, let's assume the temperature of the resistor changes by 10C (which is about how much we would like to heat the whole thing). Therefore, the resistor will have a new value of . The new current will then be  and the new power will be . So the difference in power going through the heater is about 0.00088W.

We can use this power difference to calculate how much the temperature of the metal can we wish to heat up will change.  where  is the thermal conductivity and x is the thickness of the material. For our seismometer, I calculated it to be 0.012K.

I reengaged the heater this morning, to compare it with the free-wafting and passive box-covered data. In order to make the loop stable, I had to reduce the gain of the AD620 by 10. I have increased the TEMP_MON preamp gain by 10, so the calibration should still be ~3.5 V/K into the ADC (and in DV).

Below is a screenshot showing that the RAMmon signals are pushed to some (nonzero) value, and it appears that they stay there despite the changing PSL table temperature as measured by FSS_RMTEMP. My post from last week shows that without the heater servo the temperature of the EOM can follows RMTEMP almost exactly. So, it seems like the heater is working well at low frequencies, modulo sensor noise, which ought to be low for the thermistor. Since several things (MC, etc.) have changed since out baseline data, it migth be prudent to let this sit for a little while and then disconnect the heater to see what happens.

Just a quick update: over the past few days we've taken (at least) 5 scans around each peak [carrier - HOM3] at 9.4V/0.8A, 4 scans around [carrier - HOM5] at 12V/0.9A hot state with the reflector setup. We also have (at least) 5 scans of carrier - HOM5 in cold state. I attach a rough overview of the peak magnitude shifts in the first attachment. Analysis ongoing. All data stored in annalisa/postVent/{date}

Initial shifts just based on rought peak placement in the meantime:

            [9.4V/0.8A]   [12V/0.9A]

HOM1    10 kHz         20 kHz

HOM2    18 kHz         28 kHz

HOM3     30 kHz        40 kHz

HOM4     N/A             26 kHz

HOM5     N/A             35 kHz

I also attach the heating thermal transient from today (12V/0.9A) as seen by the opLevs. We see a shorter time constant for pitch, longer for yaw, preceeded by a dip in yaw. Similar behavior yesterday for slightly less heating, though less pronounced pre-dip. The heater is offcentered on the optic horizontally; likely this is part of the induced yaw. The spikey stuff i removed is from people walking around inside during the transient.

I've left the heater and LSC off for the night. Heater off at 2:07 am local time.

Please don't touch the oplevs; we're taking a cool down measurement.

Koji, Den

CM Servo with POY11 successfully engaged. UGF: ~15kHz.

Tonight we decided to repeat one arm locking using high-bandwidth CM servo. We low-passed AO signal to avoid saturations of the EOM. We tried different configurations that compromise between noise and loop phase margin and ended up with a pole at 30kHz. SR560 is used as a low-pass filter.

Another problem that we faced was big (~2.6V) electronic offset at the input of 40:4000 BOOST. Once engaged, cavity would be kicked out of lock. We calibrated this offset to be almost half linewidth of the cavity (~300pm). To avoid lock loss during engaging the boost we increased common mode gain to maximum (31 dB).

Measured OL is attached. UGF is 15kHz, phase margin is 60 degrees. We have also simulated evolution of loop shape during bringing AO path. Plot is attached.

The final procedure is

• set common gain up to 31dB, AO gain to 8dB, MC IN2 gain 10dB, CM offset 0.7V
• lock arm with CM slow path with bandwidth of 200 Hz
• enable AO path, gradually increase slow and fast gains by 12 dB
• enable boost

This too huge offset difference with/without "BOOST" switch should be checked.

I checked the offset situation in the CM servo boost circuit. 

- The offset voltage on the CM servo screen is a raw DAC output. This number is diluted by the voltage divider before the amplifier.
  So, the actual offset of the boost circuit was much smaller. (~20mV)

- There is a offset trimmer on the board. This was adjusted so that the boost does not generate an output offset.

- So the default offset is 0V.

- When the arm was locked with (digital) POY11, the CM servo offset is necessary to be -2.7 (now).
  This means that analog POY11Q and digital POY11 has different offset for the best resonance transmission.
  That is believable if POY11I is contributing to the digital POY11 signal.

High particle count confirmed with #2 counter

The BS camber is open only. We should close ASAP

Outside air quality is 1.7- 2.2  million particles  / cf min of 0.5 micron

 The bad outside air quality is pushing up the inside counts.

The outside air is 5 million counts / cf min for 0.3 micron and 2 million counts / cf min for 0.5 micron particles

Do not open chamber over 10,000 counts / cf min of 0.5 micron

 Air is still bad and the chambers are closed. Before lunch  Jamie repointed the PRM oplev. Manasa and I reset oplevs: BS and ITMX.

ETMX and ETMY are fine.

SRM and ITMY oplevs needs more work.

The construction activity is shaking the tables in the control room.  The compactor- large remote controlled jackhammer is in the bottom of the 16-17 ft deep hole 15 ft east of ITMY in CES bay. The suspensions  are holding OK. PRM, MC1 and MC3 are effected mostly.

New Focus Servo Controller has just arrived. We have 25 days to evaluate this product.

It will have to be shipped back to the vendor on April 4, 2011 the latest in order to get full refund.

This 3 years old HeNe [ JDS 1103P, sn 351889 ]  has been dying for some time or just playing possum at age 1,126 days

I did not replace the ETMX oplev laser because I was unable to bring up the the C1ASC_ETMX_OPTLEV_SERVO  medm screen on laptops.

A 30-day trend of the PCDRIVE from the FSS.

PRM and SRM sat. boxes have been switched for some time now - but the PRM sat. box has one channel with a different transimpedance gain, and the damping loops for the PRM and SRM were not systematically adjusted to take this into account (I just tweaked the gain for the PRM and SRM side damping loops till the optic damped). Since both sat. boxes are nominally functioning now, I saw no reason to maintain this switched configuration so I swapped the boxes back, and restored the damping settings to their values from March 29 2016, well before either of this summer's vents. In addition, I want to collect some data to analyze the sat. box noise performance so I am leaving the SRM sat. box connected to the DAQ, but with the tester box connected to where the vacuum feedthroughs would normally go (so SRM has no actuation right now). I will collect a few hours of data and revert later tonight for locking activities....

I did a quick calculation to see if the offset of the arm length which I tried last night was reasonable or not.

The conclusion is that the 20 nm offset that i tried could be a bit too close to a resonance of the 55 MHz sidebands.

A reasonable offset can be more like 10 nm or so where the phases of all the laser fields don't get extra phases of more than ~ 5 deg.

The attached plot shows where the resonances are for each sideband as a function of the displacement from the carrier's resonance.

The red solid line represent the carrier, the other solid lines are for the upper sidebands and the dashed lines are for the lower sidebands.

The top plot shows the cavity power and the bottom plot shows how much phase shift the fields get by being reflected by the arm cavity.

Apparently the closest resonances to the the main carrier one are that of the 55 MHz sidebands, and they are at +/- 22 nm.

So if we displace the arm length by 22 nm, either of the 55 MHz sidebands will enter in the arm cavity and screw up the sensing matrix for the 55 MHz family.

The beam of IR for doubling  is clipping on bnc cable to green beam transmitted pd.

I found baked allen keys on the top of the clean optics cabinet.  Somewhat heavy box that can come down in an earthquake on our heads.

NOTHING SHOULD GO ON THE TOP OF THE CABINETS OR RACKS except  small plastic boxes that storing our clean clothing.

We can not leave cables connected like this. This is a burned toast award.

So this is obviously a general problem for all the TTs.  Our in-vacuum wiring is unfortunately mirrored relative to that of aLIGO, or at least:

• aLIGO: in-vacuum pin 1 tied to shield (T1200131)
• 40m: in vacuum pin 13 tied to shield

And again, the problem is that pin 13 on the TT quadrapus cables is the one of the coil pins for one of the OSEMs.

I think the right solution is to make mirroring adapter cables for the TTs.  Modifying the pins on the stack-top brackets for just the TTs would leave us with a bunch of brackets that are different than all the rest, which I think is a bad idea.  Therefore we leave all the feed-thru-->bracket wiring the same, and make adapters.  I'll describe the adapters in a follow-up post.

The silver lining to this whole thing, if there is one, is that I wired the polarity on the out-of-vac adapter cable at the coil driver in such a way that the drive/send signal went to the grounded in-vac pin.  If I had by chance wired the polarity oppositely everything would probably have worked, except that the return for one of the coils would have gone through the cable shield and the chamber, rather than the return pin to the coil driver.  I'll let you image the problems that would have caused.

Making new adapters will take a little while, but I think we can proceed with the installation and alignment with a temporary setup in the mean time by taking advantage of the polarity I mention above.  We can temporarily swap the polarity so that we can drive current to the coil using pin 13.  This will allow us to complete the installation and do all the alignment.  Once the in-vac adapter cable arrives, we just put it in, fix the out-of-vac polarity, check that everything works as expected, and button up.

We'll pick up all this when we're back on Jan 7.  Steve will put in an order for the in-vac adapter cables ASAP.

I take full responsibility for this fuck up.  We've been unable to find any in-vac wiring diagrams, but I should have checked all of the wiring during the last vent so that we could have prepared for this ahead of time.  Sorry.

From the mode scan measurements of the arms(elog #6859), ~6% of mode-mismatch comes from 2nd-order mode. That means we have longitudinal mismatch.

Suppose every mirrors are well positioned and well polished with designed RoC, except for the MMT1-MMT2 length. To get ~6% of mode-mismatch, MMT1-MMT2 length should be ~28cm longer (or ~26cm shorter) than designed value.
I don't know whether this is possible or not, but if they are actually longer(or shorter), we should fix it on the next vent.
I found some related elog on MMT (see #3088).




RoC and length parameters I used is below. They maybe wrong because I just guessed them. Please tell me the actual values.
Mirror thickness and effect of the incident angle is not considered yet.

== RoCs ==
MC2 19.965 m (???)
PRM 115.5 m (not used in calculation; just used to guess MC parameters)
ITM flat
ETM 57.37 m

== Lengths ==
MC round trip 27.084 m (???)
MC1 - MC3  0.18 m (???)
MC3 - MMT1 0.884+1.0442 m
MMT1 - MMT2 1.876 m
MMT2 - PRM 2.0079+0.4956 m
PRM - ITM 4.4433+2.2738 m
ITM - ETM 39 m

The MC waist is correct as is the arm RoCs. Most likely the error is in the telescope length or its distance from the MC. Jenne probably has all the numbers and can give us a surface plot showing how the MM degrades as a function of those two parameters.

 Koji did a nice job increasing light power with some joggling.

Alberto is visiting us from Australia. He brought some terrific presents. It is going to be very demanding task to wait for the rest of the 40m team

to return from Wales to taste coffee:  PNG Peaberry of Wagonga, Monsooned Malabar of Jindebah and Signature Blue Blend of Cosmorex.

 I'm taking full responsibility for this action and I told them after lunch Friday.

HOW NOT TO:

The BS isolation stack  supported by two beam tubes and they can pivot around the pivot point.

Here is a hypothetical scenario which could make the glitches in the LSC error signals. It can be considered as a 4 step phenomenon.

        (1) up conversion noise due to a large motion at 3 Hz

   => (2) rms level exceeds the line width (a.k.a. linear range) in some LSC sensors

   => (3) unlocks some of the DOFs  in a moment

   => (4) glitches due to the short unlock.

- - plan  - -

 In order to check this hypothesis the low finesse PRMI must serve as a good test configuration.

What I will do is to gradually decrease the offset in MICH such that the finesse of PRMI becomes higher.

And at each different finesse I will check the spectra, glitch rate, and etc.

 I changed the default shell on our control room iMac to bash. Since we're really, really using bash as the shell for LIGO, we might as well get used to it. As we do this for the workstations, some things will fail, but we can adopt Jamie's private .bashrc to get started and then fix it up later.

Rana, Steve,

I have adapted one of Evan's python scripts into an ipython notebook for calculating our PRMI sensing matrix - the work is ~half done.

The script gets the data from the various PD channels (like REFL33_I) and demdoulates it at the modulation frequencies. At the moment its using just the sensing channels, but with the recent addition of the SUS-LSC_OUT_DQ channels, we can demod the actuation channels as well and not have to hand code the exc amplitudes and the basolute phase. Please ignore the phase for the moment.

The attached PDF shows the demod (including lowpass) outputs for a 2 minute stretch of PRMI locked on f2. Next step is to average these numbers and make the radar plots with the error bars. The script is scripts/LSC/SensingMatrix/PRMIsensMat.ipynb and is in the SVN now.

** along the way, I noticed that the reason this notebook hasn't been working since last night is that someone sadly installed a new anaconda python distro today  without telling anyone by ELOG. This new distro didn't have all the packages of the previous one. I've updated it with astropy and uncertainties packages.

I've fixed the Radar plot making part, so that's now included too. The radial direction is linear, so you can see from the smearing of the blobs that the uncertainty is represented in the graphics due to each measurement being a small semi-transparent dot. Next, we'll put the output of the statistics on the plot: mean, std, and kurtosis.

My bad, sorry! 

Yesterday, I was trying to install a package with anaconda's package manager, conda, but it was crashing in some weird way. I wasn't able to fix it, which led me to create a fresh installation. 

[Haixing / Kiwamu]

 As a part of the Wednesday's cabling work, we spent some times for identifying the RFPD interface cables.

The RFPD interface cables are made of a 15 pin flat cable, containing DC power conductors for the RFPDs and the DC signal path.

The list below is the status of the interface cables.

- - - - RFPD name, (cable status) - - - -

- REFL11 (identified and labeling done)

- REFL33 (identified and labeling done)

- REFL55 (identified and labeling done)

- REFL165 (no cable found)

- AS55 (identified and labeling done)

- AS165 (identified and labeling done)

- POP22/110 (identified and labeling done)

- POX11 (identified and labeling done)

- POY11 (identified and labeling done)

- POY55 (identified and labeling done)

We still have two cables which are not yet identified. Their heads are around the LSC rack and labeled 'unidentified'

Matlab version of ifo digital noise estimation code is almost ready. It estimates digital noise introduced by each filter bank in each model. I'm waiting for NDS group to complete function to download online data to Matlab. Now code downloads data from the past that is not great because not all _IN1 channels are recorded and some of them are recorded at lower frequencies.

There might be some useful functions in this code for other applications as I've heard during the meetings. This is what it does

• reads model names from the input list
• for each model
  
  • finds corresponding Foton file and extracts modules with sos filters and sampling rate of the model
  • finds corresponding MDL file and makes a search for subsystems with "top_names" tag and "biquad=1" tag
  • creates _IN1 channel names using module names and subsystems with "top_names" tag
  • for each channel inside the model
    
    • reads filter bank parameters (which filters are ON, switches, limit, offset...)
    • downloads data
    • calculates output and estimates digital noise
    • checks that output is less them limit if it is on
    • reports if something is wrong

NDS group plans to release the function to download online data this week. Hopefully, it will be possible to download ~30 channels at a time. Code will need a few minutes of data for each channel. So it will be possible to check the whole ifo during the night.

At this point I've checked 40m using DQ channels. We have ~40 IN1_DQ channels with non-empty filter banks. These are osems channels. Digital noise is low for them.

Running train-of-thought elog:

East N2 cylinder found empty, replaced. West is >2kpsi

Removed Yuta-specific code from damprestore. A grep for 'yuta' in the python files within /scripts/ shows some other occurances, but nothing that is really in use at this time. New feature of damprestore.py: remembers oplev status.

Ran LSCoffsets. 

WFS offsets relieved (all <20).

Adjusted FSS offset to minimize MC_FAST_MON

ASS ran (but the arm alignment has been astoundingly stable lately. I haven't touched it all this week)

ITMX is the only optic that got a correction over 20 counts. 

BS and *TM oplev spots look well centered, except for ITMX. 

I undid the gain reduction rana introduced because X ASS seemed to be really slow. It is currently fine in its older state. What's going on here?

Some network latency stuff is going on, even freezing up terminals when trying to write text files. This may (or may not) be correlated with the summary page rysnc jobs on nodus. It occurs to me that we have a DAQ ethernet network seperate from the martian network, but the frame transfers need to go through the martian network, since nodus is the only way out to the outside world. If we had a machine/gateway directly from the DAQ network to the caltech network, the martian network wouldn't get bogged down when frames are being uploaded

GTRY = 0.55, ok. Aligned GTRX to 0.52, also ok

Y beatnote was found easily. Have spent >30 minutes looking for X green beatnote. Typical FSS slow and X temperature ranges don't seem to be giving much. Will check the beat alignment with a scope, but if the beat is too high to begin with, it may not work...

I suspect a problem with the X Green BBPD

I could see the IR beatnote between the PSL and AUX X lasers at the input to the frequency counter. (I believe it is a real beatnote because it reacted as expected to the end temperature moving, and stabilizing the end laser to the arm). However, when placing the IR beatnote at a frequency which should've made the green beatnote visible on an analyzer and/or scope, no beatnote was found. I played with the beat alignment to no avail; the DC output of the BBPD behaved as expected, but I never saw anything in the RF output or on the control room analyzer.  I also checked the beatnote signal chain by hooking up a 1mV 26MHz signal into the cable that hooks up to the RF out of the BBPD; the signal showed up clearly on the control room analyzer. 

I'm not sure what may have happened. ELOG 9996 may be related. 

I'm calling it a night. 

Given my suspicion of fault with the X Green BBPD, Koji generously provided me with another one that he had confirmed to be working. 

However, I turns out I was mistaken. With the existing BBPD, I did indeed witness a beat in the RF output, but it is somehow something like 20dBm smaller than it should be. This is why I missed it the other night. Here's a video of a RF output on a scope, wherein the beat is only barely visible because I've set the trigger level very low. I could not make the beatnote any larger through any alignment motions; I had gotten to this point by doing near/far field overlap on the PSL table. 

I'm not sure what could have caused this. Mode mismatch? By eye, the beam spots looked about the same in the near and far fields, and we haven't had to touch the mode matching in quite some time... I've given up on trying to solve this for tonight. 

Just for kicks, I hooked up the fiber PD IR beatnotes as inputs to the ALS DFD. The X beat is too small to even really see above the control room analyzer's noise floor, but the Y beat looked big enough. With the arms locked on IR, the phase tracker output RMS was a few kHz, so not even worth thinking about any further. Not so surprising. 

Finally, I put back / hooked up everything in its nominal state. 

I've started working on a general routine to measure noise couplings in our interferometers. Often this is done with swept sine measurements, but this misses the nonlinear part of the coupling, especially if the linear part is alreay reduced through some compensation or feedforward scheme. Rana suggested using a series of narrow band-limited noise injections. 

The structure I'm working on is a python script that uses the AWG interface written by Chris W. to create the excitations. Afterwards, I calculate a series of PSD estimates from the data (i.e. a spectrogram), and apply a two-sample, unequal variance, t-test to test for statisically significant increases in the noise spectra to try and evaluate the nonlinear contriubutions to the noise. I've started a git repository at github.com/e-q/ifoCoupling with the code. 

So far, I've tested one such injection of noise coupling from the ETMX oplev error point to the single arm length error signal. It's completely missing the user interface and structure to do a general series of measurements, but this is just organizational; I'm trying to get the math/science down first. 

Here's a result from today:

Median, instead of the usual mean, PSDs are used throughout, to reject outliers/glitches.

The linear part of the coupling can be estimated using the coherence / spectrum height in the excitation band, but I'm not sure what the best what to present/paramerize the nonlinear parts of each individaul excitation band's result is.

Also, I anticipate being able to write an excitation auto-leveling routine, gradually increasing the exctiation level until the excited spectrum is some amount  noisier than the baseline spectrum, up to some maximum amount configurable by the user. 

The excitation shaping could probably be improved, too. It's currently and elliptic + butterworth bandpass for a sharp edge and rolloff. 

I'm open to any thoughts and/or suggestions anyone may have!

Looks like a very handy code, especially with the real statistical tests.

I would make sure to use much smaller excitation amplitudes. Since the coupling is nonlinear, we expect that its only a good noise budget estimator when the excitation amplitude is less than a factor of 3 above the quiesscent excitation.