Looks like all of the accelerometers and seismometers have been disconnected since early AM last Monday when Clara disconnected them for her sensor noise measurement.

    ..
m * x  = (x_G - x) * k  + d(x_G - x) * b
                          dt

• m = mass
  
• x = displacement of the mass
  
• x_G = displacement of the ground
  
• k = spring constant
  
• b = damping constant
  

x               w0^2  +  i*w*w0/Q
----    =    -----------------------
x_G           w0^2 + i*w*w0/Q - w^2

• w0 = sqrt(k/m) = natural frequency of spring + mass
  
• w = frequency of ground motion
  
• Q = q-factor of spring + mass system = 1/2 for critically damped system
  

d  (x - x_G)          (    w0^2  +  i*w*w0/Q          )    .                    w^2               .
dt                 =  (  -----------------------  - 1 ) * x_G   =      ----------------------- * x_G
                      (   w0^2 + i*w*w0/Q - w^2       )                w0^2 + i*w*w0/Q - w^2

I  measured the transfer function of the new coil driver board. This was done to estimate the correct Sim-Dewhithinng and Anti-Dewhitening digital filters in the CDS. 

Attachment 1: Shows the setup used to measure the TF of the Coil driver board.
Attachment 2: Coil driver board replaced by a DB9 cable (Reference).
Attachment 3: The magnitude and phase response of the measured and simulated TF (Coil driver parameters mentioned here (D2100145) )

Update

Attachment 4: The magnitude and phase response of the simulated and measured TF for the two operating modes. (The coil driver has two modes of operation i.e. Run and Acuisition)

I estimated the transfer function of the seismic stacks using a rough model I made based on the LIGO document LIGO T000058 -00. I used a Q of 3.3 for the viton springs, and resonant frequencies of 2.3, 7.5, 15, and 22 Hz (measured in that document for the horizontal motion). I multiplied the simple mass-spring transfer function four times for each layer of metal/spring, with the respective resonant frequency for each. The pendulum suspending the test masses has a resonant frequency of 0.74 and a Q of 3, according to the same document.

When I multiply the net transfer function (pendulum included, the green line above) by the differential motion of the x arm that I measured in eLog 7186, I find the differential motion of the test mass (NOTE: I converted the differential motion to displacement by multiplying by (1/2*pi*f)).

It agrees within an order of magnitude to the seismic wall from the displacement noise spectrum hanging above the control room computers.

Finally, I looked at how the geophone and accelerometer noise spectra looked compared to the ground differential motion (any STACIS sensor signal will also be multiplied by the stack/pendulum transfer function, so I'm comparing to the differential motion before it goes through the chamber). Below about 1 Hz, it is clear from the plot below that the STACIS could never be of any benefit, even with accelerometers rather than geophones as the feedback sensors.

 I made the plots a little nicer and added new sensor noises (from Brian Lantz's scripts and measurements). Click to enlarge.

The last plot shows that these other sensors' noises are lower than the differential ground motion below 1 Hz.  Though 3 seismometers per STACIS is impractical, this shows that such seismometers could be used as feedforward sensors and provide isolation against differential ground motion. At these noise levels, the noise of the high voltage amplifier circuit in the STACIS would probably be the limiting factor.

For the preparation of the electronics upgrade, three 18bit DAC AI chassis were transformed to 16bit version.

The power supply connections were touched, so the units were tested with +/-18V, and they work as expected.

Using Alberto's paper LIGO-T10002-09-R titled "40m RF PDs Upgrade", I calibrated the vertical axis in the bode plots I had obtained for the two PDs ET-3010 and ET-3040.

I am not sure whether the values I have obtained are correct or not(i.e. whether the calibration is correct or not). Kindly review them.

EDIT: Attached the formula used to calculate transimpedance for each data point and the values of other paramaters.

EDIT 2: Updated the plots by changing the conversion for gettin ghte ratio of the transfer functions from 10^(y/10) to 10^(y/20).

EDIT: Please ignore the following data. The revised data and plot are in Elog 10089 

Yesterday evening, I conducted the same measurements done in Elog-10059 using the same REF PD (NF 1611) and the same model of BBPD, but on different piece that needed to be checked. 

I moved the NA from near rack 1Y1 to the Jenne laser table and back again after the readings were done.

 Acquiring data

• The following conditions were set on Network Analyzer Agilent 4395:

1) Frequency sweep range: 1MHz to 300 MHz.

2) Number of Points sampled in  the range: 201

3) Type of sweep: Logarithmic

• Set the NA to give the corresponding transfer function value (output of BBPD over output of 1611) and also Phase response in degrees.
• Save the data into floppy disk for processing on the computer.

 Results

The Plots of transimpedence obtained are attached. The data and matlab code used is in the zip file.

The transimpedance of  Broadband photodiode (D1002969-v8) was around 50kV/A-70kV/A (Unusually high) for most of the range (2), but the value started falling as the frequency approached 200 MHz.

The high impedance might be because the PD is faulty.   

Oh, nice! This must be a new technique to have a higher transimpedance by breaking the PD.

Now both BBPDs are showing abnormally high impedance.
(Remember, you have not revised your previous entry after my pointing out you have a bug in the code.)

You should break down the measurement into each raw numbers for validation.
And if this high impedance is still true, you should point out what is causing of this anomaly.

  [Nichin, Koji] 

Today evening, me and koji decided to get down to the problem of why the trasimpedence plots were not as they were supposed to be for Broadband photodiode (D1002969-v8) S1200269. There were a few problems that we encountered:

• Turns out the REF PD was not illuminated properly, for maximum output. The DC output voltage turned out to be much higher than the previous measurement. Since I assumed that the REF PD had not been touched since the first day I took readings, I did not check this.
• The fork holding the Test PD was a bit out of shape and only one side of it was clamping down the PD. This made the PD vulnerable swivel about that one side. We replaced it with a new one.
• I was setting the current diving the Jenne laser to about 20mA and this resulted in nocthes at higer frequencies in the network analyzer due to over driving of the diode laser. Once we reduced this to about 12.5-13 mA they disappeared. Also, the current limit setting was set at 40mA which is way too high for the jenne laser and might have resulted in damaging it if someone had accidentally increased the current. We have now set it at 20mA.

After these changes the measurements are as follows:

I moved the NA from near rack 1Y1 to the Jenne laser table. 

 Acquiring data

• Jenne Laser driving current: 12.8mA 
• The following conditions were set on Network Analyzer Agilent 4395:

1) Frequency sweep range: 1MHz to 300 MHz.

2) Number of Points sampled in  the range: 801

3) Type of sweep: Logarithmic

• Set the NA to give the corresponding transfer function value (output of BBPD over output of 1611) and also Phase response in degrees.
• Save the data into floppy disk for processing on the computer.

 Results

DC output voltage of REF PD: 0.568V

DC output voltage of BBPD: 18mV

Power incident on REF PD and BBPD respectively: 0.184mW  and 0.143mW

Hence, Responsivity for REF PD and BBPD respectively:  0.315 A/W and 0.063 A/W 

Responsivity given in the Datasheet for REF PD and BBPD : 0.68 A/W and 0.1 A/W

The reason for these differences are unknown to me and must be investigated.

The Plots of transimpedence obtained are attached. The data and matlab code used is in the zip file.

The transimpedance of  Broadband photodiode (D1002969-v8) S1200269 was around 1kV/A-2kV/A for most of the range, but the value started falling as the frequency approached 100 MHz. This BBPD is best when used at 10-30 MHz.

[Gautam Koji]

Taking the opportunity to shutdown c1ioo for adding a DAC card, we shutdown chiara and worked on moving of the main disk to the bigger home.

We shutdown most of the martian machines including the control machines, megatron, optimus, and nodus.

- Before shutting down chiara, we ran rsync to make the 4TB disk (used to be teh backup) and /cvs/cds synced.

sudo rsync -a --progress /home/cds/ /media/40mBackup

- Modified /etc/fstab

proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda1 during installation
UUID=972db769-4020-4b74-b943-9b868c26043a /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=a3f5d977-72d7-47c9-a059-38633d16413e none            swap    sw              0       0
UUID="90a5c98a-22fb-4685-9c17-77ed07a5e000"    /media/40mBackup       ext4      defaults,relatime,commit=60       0         0
#fb:/frames      /frames nfs     ro,bg

UUID=92dc7073-bf4d-4c58-8052-63129ff5755b   /home/cds    ext4    defaults,relatime,commit=60    0   0

- Shutdown chiara. Put the 4TB disk in the chassis. We also installed a new disk (but later it turned out that it only has 2TB...)

- Restart the mahcine. This already made the 4TB disk mounted as /cvs/cds .

- Restart bind9 with DHCP for the diskless clients (cf. https://wiki-40m.ligo.caltech.edu/CDS/How_to_join_martian)

sudo service bind9 restart
sudo service isc-dhcp-server restart

- Looks like /etc/resolv.conf is automatically overwritten by a tool or something everytime we restart the machine!? I still don't know how to avoid this. (cf.  https://www.ctrl.blog/entry/resolvconf-tutorial). But at least for today we manually wrote /etc/resolv.conf

controls@chiara|backup> cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.113.104
nameserver 131.215.125.1
nameserver 8.8.8.8

search martian

Follow up:

- At least it was confirmed that the local backup (4TB->2TB) is regularly running every morning.

- The 2TB disk was used up to 95%. To ease the size of the remaining space, I have further compressed the burt snapshot folders. (~2016). This released another 150GB. The 2TB is currently used up to  87%.

Prev

Filesystem      1K-blocks       Used  Available Use% Mounted on
/dev/sdc1      3845709644 1731391748 1918967020  48% /home/cds
/dev/sdd1      2113786796 1886162780  120249888  95% /media/40mBackup

Now

Filesystem      1K-blocks       Used  Available Use% Mounted on
/dev/sdc1      3845709644 1731706744 1918652024  48% /home/cds
/dev/sdd1      2113786796 1728124828  278287840  87% /media/40mBackup

[Jenne, Diego]

Tonight we were able to transition DARM from DC transmission signals to AS55Q/(TRX+TRY).  That's about as far as we've gotten though.

Here are the details:

• Set the ASDC->MICH matrix element such that the MICH fringes were 0-1.  For some reason this number seems to change by ~10% or so each night.
• Followed main carm_cm_up script, although stopped at MICH offset of 25% (mostly because I forgot to let it go to 50% - no fundamental reason)
• So, MICH was at 25% (with a + for the gain accidentally, even though we decided yesterday that - was better), arm powers were about 1.1 or so.
• Took transfer functions driving DARM and looking at normalized AS55Q, and driving CARM looking at normalized REFL11I.
  • There is still not a lot of coherence in the CARM->REFL11I case, so we decided to stick with DARM for starters.
  • The TF between DARM and AS55Q looked really nice!
• Prepared the unused DARM error signal row, including an offset before the blend matrix.
• Transitioned over to normalized AS55Q.
  • This left the DARM servo filterbank with a zero digital offset.
  • But, the error signal had an offset before it got to the DARM filter bank.
    • This offset does not have any ramping (I don't know how to do that when building a model), so it's not as nice for reducing an offset.
    • Maybe we can, after transitioning to the new signal, move the offset to the DARM servo filterbank?
• Was reducing the DARM offset so that we were at the true AS55Q zero crossing.
• Saw that the UGF servo lines were starting to get a bit lost in the noise, so I increased the DARM's amplitude.
  • I don't know if the UGF servo was already too far gone and increasing the SNR couldn't recover it, or if I was driving too hard and directly kicked myself out of lock.  Either way, we lost lock.

The carm_cm_up script now should get all the way to this point by itself, although occasionally the PRMI part will lose lock (but not the arms), so you have to go back to the 3nm CARM offset and relock the central part.  I have written a little "relockPRMI.sh" script that lives in ..../scripts/PRFPMI/ that will take care of this for you.  

We were able to transition DARM to AS55Q a total of 3 or so times tonight.  The first time was with the + MICH gain, and the rest of the times were with - MICH gain.  The carm_up script now asks for a sign for the MICH gain just after asking for a CARM offset sign. 

I think that we understand all of our locklosses from these states.  Twice (including the time described above) the UGF lines got lost in the noise, and the UGF servos went crazy.  Once the PRCL loop rang up, because a filter that wasn't supposed to be on was on.  This was a terrible filter that I had made a long time ago, and was never supposed to be part of the locking sequence, but it was getting turned on by a restore script, and kept eating our phase.  Anyhow, I have deleted this terrible boost filter so it won't happen again (it was called "boost test", which may give you an idea of how non-confident I was in its readiness for prime-time).  The last time of the night I must not have been quite close enough in CARM offset, so we should probably check with a TF before making this last jump.

Diego wrote a nifty burt restoring script that will clear out all the elements of the input matrix and the normalization matrix for a row that you tell it (i.e. DARM_A will clear out all the elements in the first row of those 2 matrices).  This is useful for the switches back and forth between the _A and _B signals, to make sure that everything is in order.  So, I now run those clear scripts, then put in the elements that I want for the next step.  For example, DARM initially locks with ALS using the A row.  Then, DARM transitions to the B row for DC transmission.  Then, I prepare the A row for AS55Q locking, and I don't want any elements accidentally left from the ALS signal.  It lives in ..../scripts/LSC/InputMatrix/

Thoughts for tomorrow:

Daytime re-commission the Xarm ASS.

Nighttime try to get back to DARM on AS55Q and push farther forward. 

Why AS55/(TRX + TRY) instead of just TRX? Isn't (TRX+TRY) controlled by CARM?

(question is secretly from Kiwamu)

Better elog tomorrow - notes for now:

REFL165 for PRMI has been "a champ" (quote from Q).  We're able to sit on ALS at average arm powers of 30ish.  Nice. 

Some ALSfool work - measured cancellation almost as good as single arm. 

One time transitioned CARM -> normalized REFL55I

Many times did DARM -> normalized AS55Q, see lots of noise at 39ish Hz - may be coupling from MICH??

Arm ASC loops helped improve dark port contrast. 

Note to selfs:  Need to make sure DTT templates have correct freq ordering - must be small freqs to large freqs.

[Jenne, EricQ]

A slightly more coherent elog for last night's work.

All night, we've been using REFL165 to hold the PRMI.  It's working very nicely.  To help it catch lock, I've set the gain in the PRCL filter bank high, and then the *0.6 filter triggers on.  The carm_cm_up script now will lock the PRMI on REFL165. 

We had to reset the REFL165 phase after we acquired lock - it was -91, but now is -48.  I'm not sure why it changed so significantly from the PRMI-only config to the PRFPMI config.

We measured the ALS fool cancellation with the arms held off resonance, at arm powers of a few.  Although, they were moving around a lot, but the measurement stayed nice and smooth.  Anyhow, we get almost as good of cancellation as we saw with the single arm (after we made sure that both phase trackers had the same UGF):

ALSfool_PRFPMI_2Mar2015.pdf

We were able to partly engage it one time, but we lost lock at some point.  Since the frame builder / daqd decided that that would be just the *perfect* time to crash and restart, we don't have any frame data for this time.  We can see up to a few seconds before the lockloss, while we were ramping up the RF PD loop gain though, and MICH was hitting the rails.  I'm not sure if that's what caused the lockloss, but it probably didn't help.

The ALS fool gain was 22, and we were using FMs 4, 6 (the pendulum and Rana's "comp1"), the same filters that were used for the single arm case.  The LSC-MC filter bank gain lost lock when we got to about 5.6 (we were taking +3dB steps).

We were using REFL55I/(TRX + TRY) as our CARM RF error signal.  We were using REFL55 rather than REFL11 because we were worried that REFL11 didn't look good - maybe it was saturating or something.  To be looked into.

Here's the striptool that was running at the time, since we don't have frame data:

At this point, since we weren't sure what the final gain should be for the RF CARM signal, and we could sit at nice high arm powers (arm powers of 30ish correspond to CARM offsets of about 50pm), we decided to try just a straight jump over to the RF signals. 

The first time around, we jumped CARM to (-0.2)*REFL55/(TRX+TRY), but we only stayed lock for 1 or 2 seconds.  That was around 1:55am.

We decided that perhaps it would be good to get DARM moved over first, since it has a much wider linewidth, so the rest of the trials for the night were transitioning DARM over to (0.0006)*AS55Q/(TRX + TRY).  AS55 was saturating, so we reduced its analog gain from 18dB to 9dB and re-ran the LSC offsets.  The MICH noise was pretty high when we were at low CARM offset, although we noticed it more when DARM was on AS55.  In particular, there is some peak just below 40Hz that is causing a whole comb of harmonics, and dominating the MICH, PRC and DARM spectra.  I will try to get a snapshot of that tonight - I don't think we saved any spectra from last night.  Turning off DARM's FM3 boost helped lower the MICH noise, so we think that the problem is significant coupling between the two degrees of freedom. 

After the first one or two tries of getting DARM to AS55, we started engaging the arm ASC loops - they helped the dark port contrast considerably.  The POP spot still moves around, but the dark port gets much darker, and is more symmetric with the ASC on.

Just in case there was some confusion, the champagne on my desk is not to be opened before I get back, no matter how many signals are transitioned to RF.

[Jenne, Diego, EricQ]

Hopefully there will be more later, but Chiara just went down (network? other?  Q is in there right now looking at it), so this is a so-far-tonight elog.

We have successfully transitioned MICH over from REFL33Q to ASDC in both the PRMI and PRFPMI configurations.  Next up is to start reducing the CARM offset.

Resetting the REFL demod phases

I have been unable to lock the PRMI for more than teeny blips since Thursday.  So, tonight I finally got it to lock with MICH on AS55Q and PRCL on REFL33I, and used that to set the demod phases. 

Setting the demod phases, I used an oscillation of 100 cts to PRM, at 400.123 Hz.

REFL 33 demod phase started at 148deg, now 133.2deg.

REFL165 phase started at -105.53, now -172.

No signal in REFL55????  Time series and spectra both look just like noise.  Need to check alignment of beam on PD, or if cables unplugged!!

REFL11 phase started at 16.75, now 18.9deg.

Was then able to lock on REFL 33 I&Q, like normal.

Transitioning PRMI from REFL33Q to ASDC

With the PRMI locked on REFL33 I&Q, I found that a MICH offset of -5 counts gives a minimum in ASDC.  From my earlier elog this evening (http://nodus.ligo.caltech.edu:8080/40m/10887), I expect the minimum to be at +1.4nm.  This is only one point though, so I don't know the calibration of the MICH offset yet (we should get this calib during the day by looking at MICH-only).  Anyhow, this informed which side was positive and negative relative to my Optickle plots, so I know that I wanted positive offset in the MICH servo.

I was able to comfortably hold lock at +20 counts.  Looking at a calibration line at 143.125 Hz, I determined that I wanted the matrix element for ASDC to be -0.05.  After I made that transition using ezcastep, I put the POPDC normalization in.  At the time, POPDC was about 151counts, so I put 1/151 in the POPDC->Mich matrix element.

So, here were the final lock parameters.  Note that in PRMI-only, you can acquire lock like this, and with a variety of MICH offsets:

Locking PRMI part of PRFPMI

Since the PRMI has been fussy, I'm including a brief note on the PRMI settings when the arms are held with ALS off by roughly 3nm.  To get to this point, we just ran the usual carm_cm_up script, and didn't let it run anymore when it asked for confirmation that PRMI was locked.

With MICH offset of -30 counts, AS port is pretty bright.  ASDC dark offset is set to -475.4 by the LSCoffsets script. with MICH offset = 0, ASDC_OUT is around 300counts.  But, with MICH offset = -30, ASDC_OUT is about 525 counts.  So, I put that 525 counts into the ASDC filterbank offset (so it is now the dark offset + this extra offset), so the ASDC offset is currently around -1,000.  This makes the ASDC signal roughly zero when I am ready to transition MICH over to it.  In principle I should probably set it so the average is the same as the MICH offset, but the noise is so high relative to that offset, that it doesn't matter.

After this, we engaged the CARM and DARM UGF servos.  MICH was gain peaking, so I think we might want to turn that one on too, rather than my by-hand turning down the gain.

The transition has been successful 4 or 5 times with the arms held off resonance at 3nm.  Once, we reduced the CARM offset as low as 1.7 (and had to lower the MICH gain to 1.5), but we were still hearing a woomp-woomp sound.  Not sure what that was from.  At this point, Chiara died, so we lost lock.  After that, we re-acquired lock a few more times, but MC keeps losing it.  We are still able to make the MICH to ASDC transition though, which is good.

The transition won't work if the PRCL UGF servo is not on.  The gain multiplier goes from about 1.1 up to 2.4, so the PRCL gain is certainly changing through the transition.

Diego has written up scripts for the individual UGF servos (look for an elog from him separately), so now the carm_cm_up script goes as far as locking the PRMI on REFL33 I&Q, and then it starts to transition.  PRCL UGF is engaged, MICH offset is set to -30 counts, MICH is transitioned to ASDC, POP normalization engaged, CARM UGF servo turned on, and DARM UGF servo turned on.  There are "read"s in the script before each step, so you can stop whenever you like.

Here's the final configuration for the PRFPMI while the arms are held at 3nm, with MICH on ASDC (so after the transition):

The transition for MICH to ASDC has been successful with the arms held off resonance several times tonight. It's all part of the carm_cm_up script now. I think that if we hadn't lost about an hour of time and our momentum, we would have gotten farther.  I have high hopes for tomorrow night!

These are the parameters of the UGF servos we used last night:

Some tweaking of such parameters and the commissioning of the MICH servo will be done soon; an elog post about the UGF scripts/medm screens also will be done soon.

Steve pointed out to me (this is not in his original elog, although you can see it in the photo if you look closely), that we can't really move the table legs any closer to the chamber.  We have maybe 3" of clearance between the table leg and the blue support tube that supports the bottom of the stack.  Therefore, we can't just

So Steve's proposal is to leave the legs exactly where they are, and just put a larger table on those legs.  This leaves 9" unsupported on the chamber side, and 3" unsupported on the far side.  The tables are 4" thick. 

Steve also mentions that we will lose 1.5" on all 4 sides of the table, with the new acrylic boxes, so we'll be down to 1'9" unless we get the larger table, in which case we'd have 2'9", and 3'9" on the long direction.

I would like to see a sketch of the end tables, so we can see if 1'9" x 3'9" is enough.  Manasa is working on a new end table layout in parallel to the ringdown stuff.  If we're actually concerned about the input angle of the oplevs, then to fix that we need to either get the bigger table and hang it off the edge of the legs, or perhaps as Dmass suggested, get a "doggy cone collar", and give ourselves a larger opening angle of access to the viewport, from the current table location.

I measured the transmitted power @1064nm on one of the LaserOptik mirrors labled SN6

Here is the data

The mirror is not a good reflector at 0 deg.

 More data on the transmission. Measured the tranmission as a funtion of incidence angle at 1064nm

...Looks like the coating is out of spec at any angle for 1064nm. E11200219-v2

The coating should have very low 1064nm p transmission at 45 degrees, which the plot seems to indicate that it does.  That's really the only part of the spec that this measurement is saying anything about.    What makes you say it's out of spec?

Ok, yes, sorry, the data itself does indicate that the transmission is way too high at 45 degrees for 1064 p.

 I have completed all of the model modifications and medm screen updates to allow for feedback from the transmon QPD pitch and yaw signals to the ITMs. Now, we can design and test actual loops...

The signals come from c1sc[x/y] to c1rfm via RFM, and then go to c1ass via dolphin. 

Out of curiosity about the RFM+dolphin delay, I took a TF of an excitation at the end SUS model (C1:SUS-ETM[X/Y]_QPD_[PIT/YAW]_EXC) to the input FM in the ASC model (C1:ASC-ETM[X/Y]_QPD_[PIT/YAW]_IN1). All four signals exhibit the same delay of 122usec. I saved the dtt file in Templates/ASC/transmonQPDdelay.xml

This is less than a degree under 20Hz, so we don't have to worry about it. 

We need to work farther on checking out the end transmission QPD electronics situation. 

In bullet-point form, we need to:

* Ensure that the Weiss QPD head modifications have been made on these diodes.  (cf. Rai W's LLO elogs on QPDs)

* Ensure that the QPD biases are somewhere in the range of 10-15V, not the old 100V.  (Because we only need HV to make the capacitance low for RF use. Low voltage means less power dissipation in the head)

* Ensure the Rana/Rob modifications have been propagated to the whitening boards, so that we have full dynamic range.  (Steve is looking for the marked up paper schematics)

* Replace signal path resistors with low noise metal film resistors.

* Check QPDs / whitening boards for oscillation (with a scope probe), ensure that we chose an appropriate analog gain.

In thinking about the transimpedances that we want, we thought about the current that we expect.  We should get about 100 mW of light transmitted through the ETMs when we have full IFO lock.  There is a 50/50 BS to split the light between the QPD and the Thorlabs transmission diode, so we have about 50 mW incident on the QPDs, which is about 13 mW per quadrant.  With a sensitivity of about 0.15 Amps/Watt for silicon, this means that we're expecting to see about 2 mA of current per quadrant once we have the IFO fully resonant. We want this to correspond to about 5V, which means we want a transimpedance gain of around 2.5 kOhm. 

For the things that need checking, each quadrant has:

Photodiode  ------  Gain Switch 1 ----- Gain Switch 2  ------ Gain Switch 3 ------ Variable Gain Amplifier ------- Whitening stage 1 (z @ 4 Hz, p @ 40 Hz)  ------- Whitening stage 2 (z @ 4 Hz, p @ 40 Hz)

We want to check on the status of each of these switches, and whether they actually do what they say on the QPD Head screens.  Q has checked out and fixed the bit outputs for the whitening stages, but the rest still needs to be checked out.  Also note that the Switch 1, Switch 2 and Switch 3 are common to all 4 quadrants (i.e. enabling switch 1 on one quadrant enables it on all quadrants), but the variable gains and the whitening stages are individual for each quadrant.

I've measured the sensing for each of the arms, by using our calibrated oplevs, in terms of QPD counts per micron. It is:

In the absence of a lens, the QPD would be significantly more sensitive to cavity axis translation than tilt, and thus about equally sensitive to ITM and ETM angle. However, there are lenses on the end tables. I didn't go out and look at them, but found some elogs from Annalisa that mentioned 1m focal length lenses. Back-of-the-envelope calculations convince me that this can plausibly lead to the above sensitivity ratios.

I used these quantities to come up with an actuation matrix for the ASC loops, and measured the effective plant seen by the FM, fitted it to some poles( looks like zpk([],-2*pi*[1.47+3.67i,1.47-3.67i],160); ), and designed a control servo. Here is the designed loop:

The servo works on both arms, both DoFs. A DTT measurement agrees with the designed loop shape, up to a few degrees, which are probably due to the CDS delay. The RMS of the QPD error signals goes down by about 20dB, and are currently dominated by the bounce mode, so maybe we can try to sneak in some resonant gain...?

Once we confirm that they work when locking, we can write up and down lines into the locking scripts...

 [Quick post, will follow up with further detail later. Excuse my sleepy ELOG writing]

Goal: Check out the transmon QPD signal chain; see if whitening works. Assess noise for 1/sqrt(TRX/Y) use. 

First impression: Whitening would not switch on when toggling the de-whitening. The front monitors on the whitening boards are misleading; they are taken a few stages before the real output. ADC noise was by far the limiting noise source. 

I updated the binary logic in the c1scx and c1scy to actually make the binary IO module output some bits. 

After consulting a secret wiring diagram on the wiki, not linked on the rack information page (here), I worked out which bits correspond to the bypass switches in the whitening board ( a fairly modified D990399, with some notes here)

Now, FM1 and FM2 (dewhitening filters on the ETM QPD quadrants) trigger the corresponding whitening in the boards. Here's a quick TF I took of the quadrant 1 board at ETMY. (I should take a whitening+dewhitening TF too, and post it here...)

Seems to roughly work. Some features may be due to non-accounted for elements in the anti-imaging of the DAC channels I used for the excitation, or such things. The board likely needs some attention, and at least a survey of what is there. 

I also need to take dark noise data, and convert into the equivalent displacement noise in the 1/sqrt(TRX/Y) error signals. For the no-whitening ADC noise, I estimated ~1pm RMS noise on a 38pm linewidth of PRFPMI arms. 

My apologies for all of that crap I left at the Y-end... I cleaned the rest of it up today. 

I took transfer functions of the four ETMY QPD whitening channels today. (Attempted the ETMX ones too, but had troubles driving the board; detailed below). I've attached a zip with the DTT xml files for the cases of no whitening / 1 whitening stage / both whitening stages engaged. Here's a plot of both whitening stages engaged. 

Given the way I measured, the DAC output anti-imaging is in the TFs as well. ( This is a D000186 board; with something like a 4th order elliptic LP, but I need to look at the board / fit the TF to see the parameters, there are different revisions with different filter shapes.) 

The c1scy model had excitation blocks on some of the unused DAC channels (C1:SCY-XXX_CHAN9 etc.), but these were in the second DAC output connection, and not cabled up. However, the 8th channel on the DAC had no connection in the simulink model, so I added another excitation block there (C1:SCY-XXX_CHAN8), and used the anti-imaging front panel lemo connector to drive the input of the whitening board. 

I also added a similar channel to the SCX model, but no data would show up in the channel as viewed by data viewer (though the channel name was black), or in analog world. There's the additional weirdness that the SCY excitation channels show up under SCX in DTT and awggui... I'm not entirely sure what's going on here.

I still need to look at the noise, and peek inside the boards, to check for homemade modifications and see if there are bad things like thick film resistors that may be spoiling the noise performance...

[Joe, Alex]

Yesterday during the day, Alex ran a script to fix the time stamps in the trends files we had messed up back during the daqd change overs around Feb 17th and 23rd.  See this elog for more information on the trend problem.

Due to how the script runs, basically taking all the data and making a new copy with the correct time stamps, the data collected while the script was running didn't get converted over.  So when he did the final copy of the corrected data, it created a several hour gap in the data from yesterday during the day time.

The original files still exist on the fb machine in /frames/trend/minute_raw_22mar2011 directory.

• Compare the TF after different segments of time, starting from the same point. Meaning, measuring the TF after 5,10,15,20... minutes, looking when and if the TF stablizes (stops changing).
  

• Compare the TF between same-length segments, from different times. Meaning, comparing for example 2 segments of 10 minutes taken from different times.
  

• As you can see in the attached PDF, the changes start being minor after 200,000 data points, which correspont to 200,000/256 s, which is approximately 13 minutes.
  If you look at the PDF file, it is arranged from shorter times to longer in the order of: 3, 6, 13, 26 and 39 minutes.
  

• As expected, the TF between different segmants of the same length is not completely the same. Again, you can look at the attached PDF.
  Sorry the titles are the same. Each 2 consecutive pages represent the same length of segment in different times. The order of segment's lengths is: 3, 13, 26 and 39 minutes
  

[Yuta, Hiroki]

In preparation for locking the PRFPMI, we tried to lock the sideband-resonant PRMI (but failed) on Aug. 1st:

• Locked PRY. The resulting UGFs were consistent with the previous lock (elog #17521).
• Locked carrier-resonant PRMI with 1f. The resulting UGFs were consistent with the previous lock (elog #17696)
• Tried to lock sideband-resonant PRMI with 1f (REFL55_I for PRCL and _Q for MICH) but failed. This should be due to the large mixed PRCL signal in REFL55_Q.

Next:

• Precisely tune the demod. angle and minimize the PRCL signal in REFL55_Q so that the MICH signal is dominant over the PRCL signal.
• Try locking sideband-resonant PRMI again.

We tried locking PRMI for the first time since we have solved the strange ITMX/Y issue by replacing the anti-imaging modules (elog #17738).
So we started with locking PRY and carrier-resonant PRMI before locking sideband-resonant PRMI.

Locking PRY:
We misaligned ITMX and locked PRY. Locking conditions are as follows:

• MICH​
  REFL55_I (24 dB whitening gain, 76.02 deg demod. angle), C1:LSC-PRCL_GAIN=-0.03, Actuator=
  1*PRM
  -> UGF ~ 200 Hz
   
• PRCL
  REFL11_I (15 dB whitening gain, 32.638 deg demod angle) C1:LSC-PRCL_GAIN=-0.8, Actuator=
  1*PRM
  -> UGF ~ 120 Hz 

These UGFs are consistent with the previous lock (100 Hz for both, elog #17521) taking into account the increased gain (*2) of the anti-imaging modules (elog #17738) and the difference of the whitening gains.

Locking carrier-resonant PRMI:
We succeeded in locking PRMI after restoring ITMX and aligning PRMI. There was nothing strange in this locking.
The locking conditions and the results are as follows:

• MICH
  AS55_Q (24 dB whitening gain, 2.1 deg demod angle), Power norm. = 1*POPDC, C1:LSC-MICH_GAIN=400, Actuator=0.5*BS-0.33*PRM
  -> UGF ~ 50 Hz (consistent with elog #17696)
   
• PRCL
  REFL11_I (15 dB whitening gain, 32.638 deg demod angle), Power norm. = off, C1:LSC-PRCL_GAIN=-0.005, Actuator = 1*PRM
  -> UGF ~ 220 Hz (consistent with elog #17696)
   
• Resulting POPDC: ~1600 at maximum
• Data for noise budget: gpstime 1374968385 - 1374968500

Trials for locking sideband-resonant PRMI:
We calculated the appropriate gains for MICH and PRCL to realize the same UGFs as carrier-resonant PRMI.
Also, we reduced the whitening gain for REFL55_Q to 12 dB as the error signal were saturated at its peak.
We tried locking changing some parameters based on the following conditions but failed:

• MICH
   REFL55_Q (12 dB whitening gain, 76.02 deg demod angle), Power norm. = off, C1:LSC-MICH_GAIN=0.1,Actuator = 0.5*BS-0.33*PRM
   
• PRCL
  REFL55_I (12 dB whitening gain, 76.02 deg demod angle), Power norm. = off, C1:LSC-PRCL_GAIN=-0.0004, Actuator = 1*PRM 
   
• Trigger
  Varied the threshold using the POP110_I (The power of the upper and lower sidebands. In other words, the beatnote between upper and lower sidebands).

This failure should be due to the large mixed PRCL signal in REFL55_Q.
We need to precisely tune the demod. angle and minimize the PRCL signal in REFL55_Q so that the MICH signal is dominant over the PRCL signal.
 

Much of tonight was spent fighting with ETMX.  This time, ASC was definitely off, there was nothing coming out of the ASC filter banks except the static output of the ASS.  I tried turning off the 1000 count POS offset, but I think that made it a little worse. I ended up putting the offset back.

It's a little confusing, since it sometimes moves when there is no LSC actuation.  However, it definitely moves when there is some LSC actuation.  I did a test where every time I enabled the IR arm locking and caught lock, I saw a step in the SUSPIT and SUSYAW error signals.  Once lock was aquired, it would settle and stay somewhere. If I unlocked the cavity, there was no "undo" step - it just stayed where it was.  I wasn't letting it sit long enough to see if it spontaneously moved during this test.

Here's a plot of this test.  The only button I'm touching is the LSC enable button.  ASC is off, ASS is frozen (DC values exist, but no dither, no feedback).  This was done when the 1000 count POS offset was off. The steps are less bad when the offset is on.

In between fighting with the ETM, I was able to do several trials with the PRFPMI. 

I was playing with CARM and ALS fool.

First, I used REFL55 normalized by the sum of the transmissions as the error signal for the MC filter bank and saw that REFL11 (as an out of loop signal) got much more smooth, and centered around zero.  However, I wasn't able to get the same thing with REFL11.  No matter the sign I used for the MC filter bank, the IFO would squeak (some high freq gain peaking I think), and then I'd lose lock.  This was true whether I used REFL11 through the common mode board or just directly into the ADC.

Just now, I did one trial of switching DARM over to AS55Q, just to grab a spectra of the MICH noise that Q and I saw yesterday.

PRFPMI_DARMonAS55Q_3Mar2015.pdf

I'm a little confused by some delay that seems to exist between the "A" and "B" error signals (right after the LSC input matrix) and the _IN1 point of the servo filters.  I didn't save the measurement (bad Jenne), but there's a ~40 degree difference between DARM_A_ERR/DARM_IN2 and DARM_IN1/DARM_IN2.  I don't think there should be anything there.  Anyhow, it makes the DARM loop measurements look funny.  If you just look at, say, DARM_B_ERR/DARM_IN2, you'll think that there's no way that the loop will be stable.  However, it will actually be fine. 

For tomorrow, we should take the DARM loop measurement with much less actuation.  As with last night, I blew the lock by trying to measure the DARM loop.

[Jenne, Diego]

First, random notes:

• saw a violin peak in CARM / DARM at 638.0Hz.  Assumed it was one of the ETMs, even though it doesn't match any of the frequencies in our handy-dandy chart: wiki resonances
  • Put an extra notch in the ETM violin filters.
  • Just now realized that I was actuating MC2 at the time for CARM (although 638 is also not what we have in the chart for MC2).  The MC2/ETM violin filters should be shared between eachother.
• Measured CARM and DARM loops on ALS comm and diff, gains should be 8, not 6.  Fixed in Lock_ALS_CARM_and_DARM script. 
• MC has been fussy tonight.  I started actuating CARM on ETMs, and that helped, but we've still had several unexplained MC locklosses. 
  • PC and FSS Slow are okay right now, but they have been mad earlier tonight.  Do we need to check the PID tuning for FSS slow?
• When I first started locking this evening, I was able to hold nice high arm powers (with the usual factor of 2+ RIN), so the IFO seemed okay except for the fussy MC.

Koji suggested last week that we put a cavity pole filter into the ALS error signals, and then compensate for that in the CARM and DARM servos.  The idea is that any RF signals we want to transfer to will have some kind of frequency dependence, and at the final zero CARM offset that will be a simple cavity pole. 

I put a pole at 200 Hz, with a zero at 6 kHz into the LSC-ALS[X,Y] filter banks in FM1, and then also put a zero at 200 Hz with a pole at 6 kHz into both the CARM and DARM servos at FM7.  Ideally I wouldn't have the 6kHz in there, but the compensation filter in the CARM/DARM servos needs a pole somewhere, so I put in the zero in the ALS signals so that they match.  Foton thinks that multiplying the two filters should give a flat response, to within 1e-6dB and 1e-6 deg. 

We can lock CARM and DARM on ALS with the new filters, but it seems to be not very stable.  We've measured transfer functions in both configurations, and between 50-500Hz, there is no difference (i.e., our matching filters are matching, and cancelling each other out).  We sometimes spontaneously lose lock when we're just sitting somewhere with the new configuration, and we cannot run any find IR resonance scripts and stay locked.  We've tried the regular old script, as well as Diego's new gentler script.  We always fail with the regular script during the coarse scan.  With Diego's script, we made it through the coarse scan, but spontaneously lost lock while the script was calculating the location of the peak.  So, we determine that there is something unstable about the new configuration that we don't understand.  Turning off all the new filters and going back to the old configuration is just as robust as always.  Confusing. 

Where did these 200Hz, 6kHz come from?

I wonder what are the correct filters to be incorporated in the filter banks for the cav pole compensarion.

Facts:

1. ALS Common and Diff have the cavity pole for the green (fcav_GR)

2. IR DARM has the cavity pole of the arms for IR (fcav_IR_DARM)

3. IR CARM (REFL, POP, POX, or POY) has the double cavity pole (fcav_IR_CARM)

Calculations:

1. T(ITM_GR) = 1.094%, T(ETM_GR) = 4.579% => F=108.6 (cf. https://wiki-40m.ligo.caltech.edu/Core_Optics)
L = 37.8 m (cf. http://nodus.ligo.caltech.edu:8080/40m/9804)
=> fcav_GR = c /( 4 L F) = 18.3 kHz ... ignore

2. T(ITM_IR) = 1.384%, T(ETM_IR) = 13.7ppm => F=450.4
=> fcav_IR_DARM = 4.40 kHz

3. The common cavity pole is lower than fcav_IR by factor of power recycling gain.
=> fcav_IR_CARM = fcav_IR / (P_TR * T_PRM)
P_TR is normalized for the locked arm cavity with the PRM misaligned.
T_PRM is 5.637%

e.g. for the TR of 100, fcav_IR_CARM = 4.40/(100*0.05637) = 780Hz

                         (IR CARM) o--|
                                      +--[CARM 780Hz zero / ??? pole]
(ALSX) o--|   |-[ALS C 780Hz pole]----|
          | M |
(ALSY) o--|   |-[ALS D 4.40kHz pole]--|
                                      +--[DARM 4.40kHz zero / ??? pole]
                         (IR DARM) o--|
???Hz pole is to ensure the servo filters does not have infinite gain at f=infinite, but in practice we probably can ignore it as long as it is provided by a roll-off filter

I worked in Yend station, trying to get the ETMY QPD to work properly. When I started, only one (quadrant #3) of the 4 quadrants were seeing any lights. By just changing the beam splitter that reflects some light off to the QPD, I was able to get some amount of light in quadrant #2. However, no amount of steering would show any light in any other quadrants.

The only reason I could think of is that the incoming beam gets partially clipped as it seems to be hitting the beam splitter near the top edge. So for this to work properly, a mirror upstream needs to be adjusted which would change the alignment of TRX photodiode. Without the light on TRX photodiode, there is no lock and there is no light. So one can't steer this beam without lossing lock.

I tried one trick, in which, I changed the YARM lock trigger to POY DC signal. I got it to work to get the lock going even when TRY was covered by a beam finder card. However, this lock was still bit finicky and would loose lock very frequently. It didn't seem worth it to potentially break the YARM locking system for ETMY QPD before running this by anyone and this late in evening. So I reset everything to how it was (except the beam splitter that reflects light to EMTY QPD. That now has equal ligth falling on quadrant #2 and #3.

The settings I temporarily changed were:

• C1:LSC-TRIG_MTRX_7_10 changed from 0 to -1 (uses POY DC as trigger)
• C1:LSC-TRIG_MTRX_7_13 changed from 1 to 0 (stops using TRY DC as trigger)
• C1:LSC-YARM_TRIG_THRESH_ON changed from 0.3 to -22
• C1:LSC-YARM_TRIG_THRESH_OFF changed from 0.1 to -23.6
• C1:LSC-YARM_FM_TRIG_THRESH_ON changed from 0.5 to -22
• C1:LSC-YARM_FM_TRIG_THRESH_OFF changed from 0.1 to -23.6

All these were reverted back to there previous values manually at the end.

[Mirko, Jenne]

Mirko edited the c-code to use Den's stuff that he put in the elog last night.  We then tried to compile and install, but it crashed c1lsc again.  We reverted to the simple, working c-code, pushed the physical reset button on c1lsc, and things started getting better.  The suspensions had the same problem as last night...we had to do a soft shutdown of c1sus to get things better again. 

I did a by-hand burt restore for all of the models on c1lsc and c1sus, since the auto burt restore isn't working.

I have recovered the yaw values pretty much .  As the PZT1 rails in this direction perhaps this is the more relevant of the two alignments.  The beam is translated in the vertical direction, but this can be easily corrected by changing the pitch of MC2

However note that if the WFS are switched on .. MC is going to follow the PSL beam. 

[koji, steve, gautam]

We debugged this in the following way:

1. Disconnect all fuses in the terminal blocks coming from the +/- 20 VDC Sorensens.
2. Check that they are indeed isolated using DMM.
3. Test blocks of fuses in order to identify where the problem is happening (i.e. plug fuses in, turn up Sorensen voltage knobs, look for current overload). We did things in the following order:
   • MC suspensions
   • BS, PRM and SRM
   • ITMY
   • ITMX
   • Trillium interface box.
4. Turns out that the Trillium box is the culprit.
5. Confirmed that the problem is in the trillium interface box and not in the seismometer itself by unplugging all cables leading out of the interface box, and checking that the problem persists when the box is powered on.

So for now, the power cable to the box is disconnected on the back end. We have to pull it out and debug it at some point.

Apart from this, megatron was un-sshable so I had to hard reboot it, and restart the MCautolocker, FSSslowPy and nds2 processes on it. I also restarted the modbusIOC processes for the PSL channels on c1auxex (for which the physical Acromag units sit in 1X5 and hence were affected by our work), mainly so that the FSS_RMTEMP channel worked again. Now, IMC autolocker is working fine, arms are locked (we can recover TRX and TRY~1.0), and everything seems to be back to a nominal state. Phew.

The trillium interface box was removed from the rack.

The problem was the incorrect use of an under-spec TVS (Transient Voltage Suppression) diodes (~ semiconductor fuse) for the protection circuit.
The TVS diodes we had had the breakdown voltages lower than the supplied voltages of +/-20V. This over-voltage eventually caused the catastrophic breakdown of one of the diodes.

I don't find any particular reason to have these diodes during the laboratory use of the interface. Therefore, I've removed the TVS diodes and left them unreplaced. The circuit was tested on the bench and returned to the rack. All the cables are hooked up, and now the BRLMs look as usual.

Details

- The board version was found to be D1000749-v2

- There was an obvious sign of burning or thermal history around the components D17 and D14. The solder of the D17 was so brittle that just a finger touch was enough to remove the component.

- These D components are TVS diodes (Transient Voltage Suppression Diodes) manufactured by Littelfuse Inc. It is sort of a surge/overvoltage protector to protect rest of the circuit to be exposed to excess voltage. The specified component for D17/D14 was 5.0SMMDJ20A with reverse standoff voltage (~operating voltage) of 20V and the breakdown voltage of 22.20V(min)~24.50V(max). However, the spec sheet told that the marking of the proper component must be "5BEW" rather than "DEM," which is visible on the component. Some search revealed that the used component was SMDJ15A, which has the breakdown voltage of 16.70V~18.50V. This spec is way too low compared to the supplied voltage of +/-20V.

Yesterday, while we were bringing the CDS system back online, we noticed that the control room wall StripTool traces for the seismic BLRMS signals did not come back to the levels we are used to seeing even after restarting the PEM model. There are no red lights on the CDS overview screen indicative of DAQ problems. Trending the DQ-ed seismometer signals (these are the calibrated (?) seismometer signals, not the BLRMS) over the last 30 days, it looks like

1. On ~1st December, the signals all went to 0 - this is consistent with signals in the other models, I think this is when the DAQ processes crashed.
2. On ~8 December, all the signals picked up a DC offset of a few 100s (counts? or um/s? this number is after a cts2vel calibration filter). I couldn't find anything in the elog on 8 December that may be related to this problem.

I poked around at the electronics rack (1X5/1X6) which houses the 1U interface box for these signals - on its front panel, there is a switch that has selectable positions "UVW" and "XYZ". It is currently set to the latter. I am assuming the former refers to velocities in the xyz directions, and the latter is displacement in these directions. Is this the nominal state? I didn't spend too much time debugging the signal further for now.

UVW refers to the 3 internal, orthogonal velocity sensors which are not aligned with the vertical or horizontal directions. XYZ refers to the linear combinations of UVW which correspond to north, east, and up.

I moved the two Trillium seismometers that Den left on the electronics bench out onto the new concrete blocks in the lab that will be their final resting places.  I moved one onto the slab at the vertex and the other to the slab at the Y end.  I left them both locked and just sitting on the concrete.

The pile of readout electronics that were sitting next to them I moved on to the yellow foam box half way down the MC tube, between the MC tube and the X arm tube.  This is obviously not a good place to store them, but I couldn't think of a better place to put them for the moment.

Earlier today I constructed yet another SISO filter for MCL. The one thing that stands out about this filter is its strong roll off . This prevents high frequency noise injection into YARM. The caviat, filter performance suffered  quite a bit, but there is subtraction going on.

I have realized that Vectfit lacks the ability of constraining the fits it produces, (AC coupling, rolloff, etc) even with very nitpicky weighting. So the way I used vectfit to produce this filter will be explained in a future eLOG, I think it might be promising. 

Anyways, the usual plots are shown below. 

Filter:

T240-X (SISO)

Training data + Predicted FIR and IIR subtraction:

 

Online subtraction results:(High freq. stuff shown for noise injection evaluation of the filter)

MCL

 

YARM

 

 

 

Subtraction performace:

 

The latest greatest UPS has been delivered. I will move it to near the vacuum rack in its packaging for storage. It weighs >100lbs so care will have to be taken when installing - can the rack even support this?