Right near the end of summer, I had an ISS board that was nominally working, but had a few problems I couldn't really sort out. Since I've been back, I've spent a lot of time just replacing parts, trying different circuit topologies and generally attempting to make the board function as I hoped it might in all those design stages. Below is a brief list of some of the problems I've been fixing as well as the first good characterization of the board transfer function that I've been able to get.

We'll start with some of the simple problems and proceed to more complicated ones.

• The 5V reference I was using to obtain an error signal from some arbitrary DC photodiode readout was only producing ~2.5 V. 
  • Turns out I just need a FET type op-amp for the Sallen-Key Filter that I was using to clean up any noise in the reference output, as the leakage current in a AD829 was causing a significant voltage drop. I put in an OPA140 and everything worked marvelously.
• The way I set up input grounding (i.e. send a ~0 amplitude signal through the board as an input) passed a few Amps through one of my chips causing it to burn out rather fantastically.
  • There isn't a good way to fix this on the current board (besides just getting rid of the functionality altogether) so my solution so far has just been to redesign that particular sub-system/feature and when we implement the second version of the ISS, the input grounding will be done correctly
• One of the ICs I'm using, specifically the AD8436 RMS-to-DC converter, causes some super strange oscillations in -5V power line. When this chip is soldered onto the board, the -5V supply jumps between -3V and -10V rather sporadically and the DC power-supply used to provide that -5V says that board is drawing ~600 mA on that particular power line.
  • To date, I don't really have any idea what's going with this chip, and I've tried a lot of things to remedy the problem. My first thought was that I had some sort of short somewhere so I took the chip off the board, cleaned up all the excess solder and flux around the chip's footprint and then meticulously soldered a new chip on (when I say meticulously, it took over an hour to solder 20 little feet. I really really didn't want to short anything accidentally as the chip only comes in a package with ridicously small spacing between the leads). Lo and behold, nothing happened. I still saw the same oscillations in power supply and the board was still drawing between >500 mA on that line. Just to be sure, I soldered on a third chip taking the same amount of care and had the same problems.
  • I went over the schematic in Altium that we used to order the board, and unless the manufacturer made a mistake somewhere, there aren't any incorrectly routed signals would cause, say, two active devices to try setting the voltage of a particular node to different values.
  • I got some QSOP-to-DIP package converters so that I could mess around with the AD8436 on a breadboard to make sure it functioned correctly. I set up an identical circuit to the one on the PCB and didn't see any oscillations in the power supply, both for +-5V and +-15V as the chip can handle both supply voltages. I'm not really sure how to interpret this...
  • I'm still actively trying to figure this particular problem out, but I'm shooting in the dark at this point. 
• Initial attempts to measure the transfer-function of the board were wrought with failure.
  • I figured out, with Nic's help, that the board needs the 'loop closed' with a significant broadband attenuator (to simulate the plant optics discussed in elog 9331) in order to not have constant railing of the high gain op-amp filter stages. Even after I did this, the measured transfer functions were not at all consistent with simulation. I wasn't sure if it was just a part issue, a design issue or a misunderstanding/bad data collection on my part so I just redesigned the whole servo and stuffed the board with entirely new components from around the 40m. Turns out the newly designed servo behaved more properly, as I will show below.

The above list encompasses all the issues I've had in making the ISS board function correctly. No other major problems exist to my knowledge.

I was able to measure both the open- and closed-loop transfer functions of the servo with the SR785. The results are shown below.

The transfer function with the boosts on caps at a particular value set by op-amp railing, i.e. below 100 Hz, the op-amps are already putting out their max voltage. This is the usual physical limitation when measuring the transfer function of an integrator. We can also see that the measured phase follows the simulated phase above ~300 Hz. The 'phase matching' at low frequency is again do to the op-amp railing in the servo output..

The closed-loop gain is shown below,

The measured closed-loop gain with the boosts on again matches the LISO simulation quite well except at low frequency where we are limited by op-amp railing. We compare the measured closed-loop transfer function to the desired noise suppression stipulated in my previous elog 9331,

 And we might hopefully conclude that my servo functions as desired. One should note that the op-amp railing seen in these measurements is not indicative of limitations we might face in some application of the ISS for the following reason. These transfer functions were measured with a 100 mV excitation signal (it is necessary to keep this signal amplitude large enough so that the inherent signal-to-noise ratio of the excitation source is large enough for accurate measurement) which leads to somewhat prompt railing of the op-amps. When the ISS operates to actually stabilize a laser, the input error signal will be much smaller (on the order of a few 10's of mV or less) and will decrease significantly assuming correct operation of the ISS. This means we won't see the same type of gain limitations.

What now, you ask?

Aside from the problem with the AD8436 chip, the ISS board seems to be functioning correctly. The transfer functions we have measured are correct to within the component tolerances and all of the various subsystems are behaving as they were designed to. Moving toward the goal of having this system work in situ for the CTN experiment, I need to do the following things,

• Design a housing for the board -> order said housing and the front panel previously designed
• Make sure the power supply daughter PCB boards are compatible with the ISS board and can provide power correctly
• Talk to Evan and Tara about integrating the ISS with their experiment and make sure my board can do everything it needs to in that context.

So close, or so I say all the time 

 Previously in elog 8959, I gave a very simple method for determining the noise suppression behavior of the ISS. Recently, I recalculated this requirement in a more correct fashion and again redesigned the ISS to be used in the CTN experiment.

• Determining the Requirement

Just as before, the data from PSL elog 1270 is necessary to infer a noise suppression requirement. The data presented there by Evan consists of two noise spectra, 1) the unstabilized RIN presently observed in the CTN experiment readout and 2) the theoretical brownian noise produced by thermal processes in the mirror coating+substrate. The statement "TF_mag = (Unstabilized RIN) / (Calculated Brownian Noise Limit)", where TF_mag refers to the required open-loop gain of the ISS, is actually a first order approximation of the 'required' noise suppression. In fact if we wanted the laser noise to be suppressed below the calculated brownian noise level, it is more correct to say 

        Closed-loop ISS gain = (Calculated Brownian Noise Limit) / (Unstabilized RIN)

As this essentially gives a noise suppression spectrum i.e. a closed-loop gain in linear control theory. Below is a very simple block diagram showing how the ISS fits into the CTN experiment. The F(f) block represents my full servo board.

Some of the relevant quantities involved:

So looking at the block diagram, our full closed-loop transfer function is given by,

So then to determine the required F(f), i.e. the required transfer function for my servo, we consider the expression 

The plant transfer function is simply Plant = (C(f) * a * P * A) ~ 0.014 V/V, where I have ignored the cavity pole around 97 kHz as our open-loop transfer function ends up crossing unity gain around 10 kHz. In the above, I have included what I call a 'safety factor' of 10. Essentially, I want to design my servo such that it suppresses noise well beyond what is actually required so that we can be sure noise contributions to experiment readouts are not significantly influenced by the laser intensity noise.

• Proposed Servo Design

Using the data Evan reported for the brownian noise and free-running RIN, I came up with an F(f) to the meet the requirement as shown below.

 Where the blue curve includes the safety factor mentioned before. This plot just demonstrates that using my modular ISS design, I can meet the given noise suppression requirements.

To be complete, I'll say a little more about the final design.  As usual, the servo consists of three stages. The first is the usual LP filter that is always 'on' when the ISS loop is closed. The boosts I have chosen to use consist of an integrator with a single zero and a filter that looks somewhat like a de-whitening filter. The simulated open-loop transfer functions are shown below.

 I was working on the electronics bench and what sounded like a huge truck rolled by outside. I didn't notice anything until now, but It looks like something became misaligned when the truck passed by (~6:45-6:50 pm). I can hear a lot of noise coming out of the control room speakers and pretty much all of the IOO plots on the wall have sharp discontinuities.

I haven't been moving around much for the past 2 hours so I don't think it was me, but I thought it was worth noting.

 While looking at the PMC REFL beam for the AOM diffracted beam, we noticed that although only one beam exists between the PMC and the first steering mirror, there are two afterwards and they both go to the PMC REFL  RFPD!!! This is madness. We only want one beam on our PDH diode.

The reason that we have two beams is that that first steering mirrors is actually a (W1-PW-1025-UV-1064-45P) non-wedged window with an AR coating on only one side. So two beams come out of it. There is a terrible and floppy and illegal anodized aluminum dump close to this beam which *someone* probably intended to use as a "scraper" to get rid of one of the beams.

Black anodized aluminum is a horrible beam dump material at 1064 - its about as grey as Steve's chair. And its so soft that it scatters light back into the PMC and makes more acoustic noise. And it is mounted so poorly (only one screw) that it can easily be bumped and twist and miss the beam. Punchline: only use anodized aluminum dumps for stray light around cameras or for HeNe for OL. Its NOT allowed anywhere where we care about interferometry of NIR beams.

It was also set to dump the dimmer beam. On Monday, we should order ~5 W1 and get them with a wedge of 1-2 deg. Then we use a black glass dump for the dim beam and orient the bright one to hit the REFL camera and the PMC REFL PD.

For the weekend, I have adjusted the crappy grey aluminum flapper to catch the bright beam so that the PMC REFL image no longer shows the interference fringe of two beams. Lets see how the PMC drifts over the next 3 days.

[Rana, Nic, Evan]

We did some work today on getting the AOM back up and running so that we can implement an SR560-based ISS.

We've removed the 18 AWG wire that was previously used to power the driver and have replaced it with a 12 AWG twisted pair (black and white, enclosed in a single gray cladding). This pair runs into the PSL rack's 24 V terminal block with a 2 A fuse. We've also replaced the cable connecting the AOM to the driver; it's now RG405.

Also disconnected the power to the old Kalmus FSS crystal driver box and turned it off. It was powered illegally. Also disconnected the power connection between the Sorensen and the old ISS AA chassis since it was wired directly without any fuse (which is a code violation). It will stay off until someone uses a proper fuse and wiring to hook it back up.

Yes, the resonance of the 2nd-order sidebands to the IFO screws up the 3f scheme.

2f (~22MHz) and 10f (~110MHz) are at x 5.6 and x 27.9 FSR from the carrier, so that's not the case.

Could we also see how much gain fluctuation of the 3f signals we would experience when the arm comes into the resonance?

 I simulated how the 3f signal is affected by the resonance condition of the arms.

To keep it simple, I only simulated a double cavity. The attached plot shows the result. In x there is the arm cavity detuning from resonance (in log scale to show what happens close to the 0 value). In the y axis there is the PRC detuning. So every vertical slice of the upper plot gives a PDH signal for a given arm detuning. The bottom plot shows the power build up inside the arm, which is dominated by the carrier.

The 3f signal is not perturbed in any significant way by the arm resonance condition. This is good and what we expected.

However, in this simulation I had to ensure that the 1f sidebands are not perfectly anti-resonant inside the arms. They are indeed quite far away from resonance. If the modulation frequency is chosen in order to make the 1f sidebands exactly ant-resonant, the 2f will be resonant. This screws up the signal: REFL_3f is made of two contributions of equal amplitude, one on the PRC sidebands resonance and the other on the PRC carrier resonance. When the arm tuning goes to zero, these two cancels out and there is no more PDH...

However, this is a limit case, since the frequency show match perfectly. If the modulation frequency is few arm line widths away from perfect anti-resonance, we have no problem.

No wonder they could not find the beam dumps. Last night was Haloween. They should of just said: Trick or treat! where are the beam dumps?

I hooked up the 4395 to the MC servo board test out (TP2A) and looked at the spectrum using our new SPAG4395.py script. We noticed a huge peak at ~3.8 MHz and correctly guessed that it was due to the beat between the MC modulation frequency 29.5 MHz and 3*f1 (~33 MHz).

So we tuned the Marconi for the main mod. from 11065910 to 11066099 Hz and saw the beat note disappear (to within the 1 Hz tuning precision of our Marconi).

New MC length tuning method! Alert the LA Times!

My conjecture is that this temperature dependent mismatch between the modulation frequency (f1) and the MC length  is what leads sometimes to our nasty saturating PC DRIVE signal. TBD.

 I couldn't find any dumps near the WFS. Koji looked. I looked twice. Maybe they are spooky and absorbing all of the light?

The MC alignment was bad and the WFS were making it drift. Koji aligned the beam into the PMC. I then restored the MC suspensions to where they were 8 days ago (back when the transmission and reflection were good). With the WFS OFF, this gave us a MC trans ~ 16000. With WFS ON it goes to 17500 which is about as good as its been over the last 80 days.

I centered the beam on the WFS with the MC unlocked and also centered the beam on the whole WFS path (it was near clipping between WFS 1 & 2). Also for some reason that beamsplitter which steers the beam onto WFS1 is a R=33% (!? why is this not a R=50% ??).

Steve, please swap this out to a BS1-1064-50-1025-45S if we have one sitting around. If not, we want to add this to the CVI purchase list, but not buy until we get a bigger list together.

I also centered this newly aligned beam into the IMC onto the PSL QPDs. We should now use these as a pointing reference for the beam into the IMC.

While doing this I noticed that the beam was almost clipping on the Uniblitz shutter used to block the PSL beam. That shutter is mounted too short and was also not centered horizontally. I removed it for now so that Steve can find a more adjustable mount for it and put it back into play. The beam going into the IMC is BIG, so you have to very careful when centering the shutter. Might be that we cannot leave it at 45 deg and still get a big enough aperture.

Note #3 for Steve: please also replace the mount for last steering mirror into the IMC with a Polanski or a Superman, that black Ultima is no good. Also the dogs must be steel - no aluminum dogs for our sensitive places.

The MC has not been able to hold lock for over a couple of hours since yesterday. I aligned the MC yesterday (elog 9320) and it lost lock in a couple of hours. I realigned the MC again around noon today only to see it drifting and lose lock again.

I have attached the MC trend for the 2 hours when the MC drifted slowly from its happy to sad state.

I wrote the scripts for cdsutils.

1. fft

usage: fft.py [-h] [-c N_CYCL] [-a N_AVG] freq channel [channel ...]

Measures the frequency content of one or more NDS channels at the specified frequecy.
    The measurement results are  magnitude, phase, real part imaginary part, and the standard deviation of the real and imaginary parts.

positional arguments:
  freq        measurement frequency
  channel     list of measurement channel

optional arguments:
  -h, --help  show this help message and exit
  -c N_CYCL   define number of cycles. Default is 10
  -a N_AVG    define number of average. Default is 100

2. tf

usage: tf.py [-h] [-c N_CYCL] [-a N_AVG] [--dB] freq input output

Measures the transfer funtion of one NDS channels pair  at the specified frequecy.
    The measurement results are the coherence, magnitude, phase, real part, imaginary part, and the standard deviation of the real and imaginary parts.

positional arguments:
  freq        measurement frequency
  input       list of measurement input channel
  output      list of measurement output channel

optional arguments:
  -h, --help  show this help message and exit
  -c N_CYCL   define number of cycles. Default is 10
  -a N_AVG    define number of average. Default is 100
  --dB        print the amplitude in dB
 

3.offsets

usage: offset.py [-h] [-t SECONDS] filterbank [filterbank ...]

Zero the offset of one or more filterbank. Take average of OUT16 channel, and put (-1 * average / gain) into offset.  After change offsets, it will turn on the offset.
    example usage) offset -d 25 C1:LSC-AS55_Q C1:LSC-AS55_I

positional arguments:
  filterbank  list of filterbank to zero offset

optional arguments:
  -h, --help  show this help message and exit
  -t SECONDS  define the averaging time. default value is 10

I put these scripts in /opt/rtcds/cdsutils/trunk/lib/cdsutils.
I couldn't put them into cds library, but I will left tomorrow to Japan...

So please help me Jamie or Joe !!

By the way,

I modified the LSCoffset script  (script)/LSC/LSCoffsets.py.

usage: LSCoffsets.py [-h] [-d SECONDS] [--PDlist]

 Zero the offsets of LSC PDs. During taking average, we will close the PSL and green shutter. After zeroing, it will turn on the offsets switch.
    example usgae) LSCoffset2.py -d 20    

optional arguments:
  -h, --help  show this help message and exit
  -d SECONDS  define the averaging time. default value is 10
  --PDlist    print PD list for LSC and exit

i made new directory 'offset_backup' for old offset script. I move all old offset script into there.

But unfortunately that cannot use right now, because cds offsets script is not available yet...

MC has not been very happy since last night. 

What I did to fix this:

1. Disabled autolocker and WFS and aligned the MC to bring MC REFL down to <0.50

2. When I re-enabled autolocker, MC was losing lock everytime WFS turned ON.

3. I relocked MC, measured the spot positions and moved MC spot positions by running /opt/rtcds/caltech/c1/scripts/ASS/MC/mcassMCdecenter 
and /opt/rtcds/caltech/c1/scripts/MC/moveMC2/

4. I reset the WFS offsets by running /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets

5. MC is locked and looks happy right now with REFL DCMON at ~0.5

 We have tried to ssh into c1iscey yesterday morning. It just did not work. We have just tried it again (now) and it did work.

Lesson learned: always shut down the computer from a TERMINAL Do not turn it off by the manual power switch.

FYI, you can trick out matplotlib by creating a matplotlibrc config file. This allows you to set defaults for plot size, trace color, fonts, grids, etc., analogous to what is achieved in ATF:1840 for Matlab.

Note also that matplotlib supports LaTeX by default (if you have LaTeX installed), which means, for example, that you can include true square roots on your spectral densities:

plt.ylabel('Voltage spectral density (V/$\\sqrt{\\mathrm{Hz}}$)')

Since the backslash is used for escape characters in python, you must escape LaTeX backslashes.

For maximum effect, you can set the following lines in your matplotlibrc file:

text.usetex = True

text.latex.preamble = \usepackage{txfonts}

Then all text and mathematics in your plot will be sent through LaTeX for processing and will appear in Times.

Also, why is the conversion from watts to volts V = 50 * sqrt(W) and not V = sqrt(50 * W)?

Masayuki was able to hold both arms off-resonance with ALS long enough for me to lock the PRMI (arms still held off resonance), and take a set of transfer functions.

MICH gain is still -2.0, PRCL gain is still 0.070, which, with the ETMs misaligned, gave me UGFs of 70 for MICH and 180 for PRCL.

Now, however, with the ETMs aligned, but arms held off resonance with ALS, the UGFs have been lowered by a factor of 2 in frequency!  What is doing this??  MICH is now 40 Hz, and PRCL is now 80 Hz.

We measured the MICH and PRCL loops for several arm powers, and there was no change, at least until the arms were both resonating with powers of ~4 . 

After misaligning the ETMs, I remeasured the loops, and the UGFs went back up to where they started.

I worked on the script SPAG4395A.py tonight with Masayuki's help. This sets up the parameters on the Agilent 4395A and then acquires the spectrum data. It had a couple of bugs before: no matter what channel you requested, you always got channel R. It also would disobey any requests to reduce the attenuation and left the Auto Atten ON. The version now in the SVN allows you to choose the channel and the attenuation.

It then makes this plot using matplotlib. The attached image is from the REFL165 pickoff at a time tonight when the arm powers were ~5-10. I have converted the spectrum from RF electrical Watts into Volts (V = 50*sqrt(W)). To go from the analyzer input to the demod board input we should scale this spectrum by a factor of ~15 (to account for the 20 dB from the coupler and the 3 dB of the splitter and a little more for losses). On the oscilloscope we see Vpp ~5 mV, so that's ~75 mVpp at the output of the BBPD which we're using for REFL165. Perhaps we can handle another factor of ~2-3 ? I'm not sure what we have in terms of linearity measurements on this thing.

EDIT: Evan is right, its V = sqrt(50*W), not V = 50*sqrt(W). ignore y-axis above

The MC (mostly MC2) decided a few minutes ago to move, so I put the SUSPIT and SUSYAW numbers back where they were, and the tweaked up the alignment from there to get a low MC REFL DC number.  Now the MC is staying locked again, after 20 minutes of not.

 I have set the PRCL UGF to be about 180Hz, and the MICH UGF to be about 70 Hz. 

This is with locking on REFL165 I&Q, with MICH gain of -2.0 and PRCL gain of 0.70 . 

The PRCL loop only has about 30 degrees of phase margin, and is not near the top of its phase bubble.  During the day, I need to look at why we don't have more phase near 200 Hz.

 This of course changes our demod phase.  Rana plotted a 4th order elliptic filter in Matlab, and from the plot determined that we should expect around 60 degrees of difference in our phase. 

To actually set the phase, I locked PRMI on AS55Q and REFL33I (MICH gain = -8.0, PRCL gain = +0.05, with 1's in the matrix elements).  I then turned on the PRCL oscillation notch (564 Hz), and turned on the sensing matrix's drive at that frequency, and looked at the spectrum of REFL165. 

The previous REFL165 demod phase was 96 degrees, so I was looking around either 36 degrees or 156 degrees.  The phase that minimized the peak in the Q signal while driving PRCL was 37.5 degrees.  Good work Matlab/Rana.

I then looked at the transfer functions between REFL33 and AS55 and REFL165, to see if there were any sign flips that happened.  There were not.  As expected, it was just a little extra phase delay.

I was able to lock PRMI with REFL 165 again after this phasing, and I am now taking transfer functions of the MICH and PRCL loops to make sure that we have the gains about right.

As we are meditating on things to look at for PRMI + 2 arms, Rana brought up the question of the demod board situation. 

We then found this table on the wiki (LSC demod boards) that indicates that all of the demod boards were originally given lowpass filters, no matter the demodulation frequency.  Back in September, I switched out the low pass filter for a bandpass filter in POP110, and put in the same bandpass when putting together AS110 (elog 9100).  So, the 11MHz diodes are probably okay with lowpasses, and the 110 diodes are okay, but we need to think about all the other ones. 

We should probably do a first guess by putting in a bandpass filter, but then simulate and measure to figure out what our requirements are for attenuation at the non-demodulation frequencies for each board.

The SXBPs from Minicircuits look pretty good, but there are lots of options on their website.

For tonight, Rana has put a coax 100 MHz highpass filter on the input to the REFL165 demod board.

 After some torture Masayuki admitted that he and Steve ignored this elog and just turned off the power button. He blames Steve entirely.

to keep from damaging our computers and our data, NEVER DO THAT.

controls@pianosa:~ 0$ cat /etc/apt/preferences.d/pin_python-matplotlib
Package: python-matplotlib
Pin: release a=lucid
Pin-Priority: 1000 

I forgot that there were a couple of different matplotlib packages that all needed to be pinned.  To be safe I decided to just pin all packages to the lucid versions.  This will still allow us to install lscsoft packages that are not ubuntu, but it will always prefer packages from lucid instead.  Here's the new pinning file:

controls@pianosa:~ 0$ cat /etc/apt/preferences.d/pinning 
Package: *
Pin: release a=lucid
Pin-Priority: 1000
controls@pianosa:~ 0$ 

Jenne just discovered an issue with the python-matplotlib package that I knew was coming but forgot about.

We pull packages from the LSCSOFT Debian "squeeze" archive, which is a convenient way for us to install LIGO data analysis software.  There are no LSCSOFT archives for Ubuntu, and Debian "squeeze" is the closest supported distribution to Ubuntu 10.04 "lucid", which is what we are using.

DASWG recently added python-matplotlib to the LSCSOFT squeeze archive.  The version they added (1.0.1-3) supersedes the version in lucid, so by default apt wants to install it.  However, the LSCSOFT version is compiled against a newer version of some standard libraries, so it won't function on our system and seg faults.

The solution (a solution) is to use apt "pinning" to pin the package to the lucid version that works.  I've added the following file on all the 10.04 workstations to prevent the package from upgrading to the LSCSOFT version:

controls@pianosa:~ 0$ cat /etc/apt/preferences.d/pin_python-matplotlib
Package: python-matplotlib
Pin: release a=lucid
Pin-Priority: 1000

Masayuki was concerned that some LSC channels were giving him all zeros.  After seeing the error in the terminal window running dataviewer (it said something like 'daqd overloaded'), I checked the lsc model, and sure enough, all the test points were used.

So, I found an entry by Jamie (elog 8431) where he reminds us how to clear the test points.  I followed the instructions, and now we're seeing real data (not digital zeros) again.

[Steve, Masayuki]

We lowered the c1iscey machine to make space upside of the computer for heat flow. 

First we turned off the computer. And then we droped the computer down by 1  notches in the rack. Now the upside and downside spaces are almost same. We restarted the computer after that and we leave the door open.

8 day minute trend of some of the IMC alignment signals.

That step ~2 days ago in the WFS2 yaw control signal shows that I didn't do such a good job on yaw.

Nic is going to come over some time and give us a new Gouy telescope that let's us have bigger beams on the WFS. At LLO, Hartmut demonstrated recently how bigger beams can reduce offsets somehow...mechanism TBD.

Also, we must angle the WFS and figure out how to dump the reflections at the same time that we rework the table for the telescope.

Steve, can you please put 2 mounted  razor dumps near the WFS for this purpose??    

            Tuesday: Razor dumps are waiting for you.

The command to get the data from spectrum analyzer right now

From command line, put ./netgpibdata -i 192.168.113.108 -d AG4395A -a 17 -f meas01

(EDIT JCD:  You must first be in the correct folder:  /opt/rtcds/caltech/c1/scripts/general/netgpibdata/)

(EDIT JCD again: "meas01" in the command line instruction will be the name of the filename.  Also, the output file meas01.dat has a comment in the first line that must be deleted before you can plot the data.  This sucks, and we should write a script to strip that line, then make nice plots.)

Please take notice that although IP address of AG4395A is same as written in the help of netgpibdata, the GPIB address is not same. It's 17.

How to use  'scope from control room.

Open the browser. Put the IP adress of 'scope (192.168.113.25) into adrress bar of the browser. If it's on the network, below screen will open.

You can control 'scope, get the data, and so on from control room.

Please take notice that Google Chrome cannot connect the 'scope. So you have to use the Firefox or other browser.

 I connected the 'scope between REFL165 output and demod board input. I split the signal from coupler using the splitter (Mini-Circuits ZFSC-2-5). One signal is going to 'scope CH1 and the other is going to spectrum analyzer. I connected the 'scope to 40MARS. The IP adress is 192.168.113.25. I connected that by cabling from 1X2.

Masayuki was running LAN cables near the MC2 chamber. This caused the MC2 suspension to move and unlocked the MC. I looked at the long term (2 days) and short term (2 hours) trend of the MC suspensions. I restored the old alignment as described above using ezcaservo.

C1:SUS-MC2_SUSPIT_INMON was restored to 1020 and C1:SUS-MC2_SUSYAW_INMON was restored to 490.

Attachment: Dataviewer trend (2 hours)

 Neither of these computers were listed in the Martian Host Table in the wiki, so I put them on there.  It's handy to keep this updated, so that we know what IP addresses are available.

 It would be nice if we could use the existing seismometer cable and place a 2-terminal temperature sensor within the stainless-steel can. A device like the AD590/592 can drive current over a long cable run without pickup issues since its a current source. Inside of the seismometer breakout box we should make a circuit to scale the signal to be close to zero at 25 C and have a slope of 1 V/deg. There are example circuits in the application note - we can just make them on a piece of vector board and glue to the inside of the breakout box (where we connect to the regulated power).

 I attach the drawings for Guralp and T-240/STS-2 connector plates. Drawings contain all information about the screws, O-rings and connectors.

Basically, box mounting receptacle for seismometer cable is attached to the connector plate with 6-32 screws. Inside cable should be ~ 1m long and connect the plate with seismometer.

For T-240 realization we have an additional LEMO connector for temperature and pressure monitoring inside the station. We should buy sensors and plug them into some machine with slow controls.

LEMO connector has 9 pins. 4 will be used for temperature and pressure sensors and spare 5 can be used for future ideas.

Also I think it might be better to put two T-240 into isolation stations.

  I thought it would be enough to notch the fundamental and the first harmonic, but sometime tonight the 2nd harmonic at 1892.88 Hz also got rung up.

I made a "Violin3" stopband filter for it and measured its Q using the ole DTT heterodyne secret handshake. Seems much too high to me - it would be nice if someone else would look at this plot and estimate the Q from it.

Turned the PSL HEPA switch back ON - I think its been off for at least a week. I turned the HEPA's variac to 20 after finishing the alignment on the table.

 At some point tonight we lost our CA connection to c1auxex (which is actually the computer at the X End and controls the ETMX, but has a Y sticker). We could telnet to it, but its puny RAM must have been overloaded with too many EPICS connections that bypassed the CArepeater. I went around and booted some machines and it seems to be back and allowing damping now. Along the way I keyed off the crate to c1auxex a couple of times.

When trying to close the rack door I saw that Charlie/Steve had illegally connected the power cable for the illuminator through the door so that it couldn't close, so I disconnected it so that they can run it properly and feel better about themselves.

Disclaimer: Steve had nothing to do with this connection. I rerouted the cable the correct way. 10-28-2013

** what does this coherence tell us about the noise in the arms ?

  I made the Yoichi laptop into a CDS laptop called 'asia' a few months ago. Somehow I mistakenly gave it the IP address of our little Acer laptop which is called 'farfalla'. This makes farfalla's network not work. I put the old Dell Aldabella by the PMC where farfalla was and am now upgrading farfalla from CentOS to Ubuntu 10.04 LTS 32-bit. I have updated the hostable on linux1 to give farfalla the 230 IP address and let 'asia' keep 225.

 The MC had been unlocked for the last 4 hours and was crying out to me so I gave it some attention. Its happier now.

From the trend (AtM #1), I saw that the MC2 suspension has moved by ~10 microradians. Since the MC cavity divergence angle is lambda/(pi*w0) ~ 200 microradians, this isn't so much, but enough to cause it to lock on bad modes sometimes. Attackmint too shows that there's not much in monotonic drift over the last 40 nights.

I moved back MC2 to its old alignment with these commands:

ezcaservo -r C1:SUS-MC2_SUSPIT_INMON -s -1017 -g 0.0009 C1:SUS-MC2_PIT_COMM -t 300

ezcaservo -r C1:SUS-MC2_SUSYAW_INMON -s 490 -g 0.0009 C1:SUS-MC2_YAW_COMM -t 332

Then I went out to the table and aligned the beam into MC using the last two steering mirrors good enough so that the WFS coming on doesn't make the visibility any better. In this nominal state, I unlocked the MC and then aligned the reflected beam onto the center of the LSC PD as well as the WFS. The beam on the first WFS is a little small - next time someone wants to improve our Gouy phase telescope, we might try to make it bigger there. On the LSC PD, the beam was off-center by a few hundred microns.

[Jenne, Masayuki]

We changed the Directional coupler from ZMDC-20-3 to ZMDC-20-5-S+ because that coupler seemed to introduce some high frequency noise.

 I measured the spectrum of the REFL165 output using AG4395A. As this entry we put the directional coupler between REFL165 output and demod board input, so I measure the signal from the coupler during the PRMI was locked.

 After measure REFL165, I also measured REFL55 output in order to make sure that the signal is not smaller than noise because of coupler. I terminated the couple output of coupler on the REFL165, and take signal from REFL55 output port directly. Both plots seems same except for around the resonant frequency of each PDs. From this plot we cannot say that the coupler reduce signal to spectrum analyser too much.

 After this measurement I reconnected the REFL165 to analyser and reconnected the REFL55 output to demod board.

We were locking the PRMI, but it is very rumbly today.  I reduced the MICH servo gain from -0.8 to -0.4 , and things seem to be better.  Now my MICH UGF is about 60Hz.

 I went to re-align the beam into the PMC just now. I also tapped all the components between the laser and the PMC; nothing seems suspicious or loose.

The only problem was that someone (probably Steve or Valera) had closed down the iris just downstream of the AOM to ~1-2 mm diameter. This is much too tight! Don't leave irises closed down after aligning. An iris is not to b used as a beam dump. Getting it within a factor of 5-10 of the beam size will certainly make extra noise from clipping/scattering. After opening the iris, the reflected beam onto the PMC REFL camera is notably changed.

Not sure if this will have any effect on our worsening transmission drift, but let's see over the weekend.

I took pictures of this clipping as well as the beam position on Steve's new Retro Position Sensor, but I can't find the cable for the Olympus 570UZ. Steve, please buy a couple more USB data cables of this particular kind so that we don't have to hunt so much if one of the cryo (?) people borrows a cable.

Attachment shows PMC power levels before and after alignment. After alignment, you can see spikes from where I was tapping the mounts in the beamline. We ought to replace the U-100 mount ahead of the AOM with a Polanski

EDIT: Cryo team returns cable - receives punishments. Picture added.

 The PMC transmission continuously degrades. In order to see what is really drifting the laser output after PBS was sampled as shown.

Summary

When PRMI + 2arms are locked yesterday, we heard the noise from suspension violin mode. For attenuation of that noise, we should design the resonant filter at that frequency and put into the ALS servo. I tried to measure the violin mode of ETMs SUS.

What I did

 1.The arms were locked by IR PDH. I used awggui to excite the suspention. I injected the Normal waveform, 10 Hz of bandwidth wave into C1:SUS-ETMs_ULCOIL_EXC. I put cheby filter in the FIlter of awggui. The order of that filter was 4, that has same bandwidth as that of injection wave and ripple was 4dB. I increase the injection gain with some ramp time(5sec). I swept from 600 Hz to 700 Hz. During that injection I saw the PDH error signal (POX11I and POY11I) in order to find resonance peak of violin mode.
 In ETMX resonances were easily found. That were at 631 Hz and 691 Hz. the 631 Hz peak was seen ALS error signal yesterday. On the other hand, I couldn't find ETMY violin mode. No peaks appeared any frequency.

2. For find the ETMY violin mode, I used dtt swept sine measurement. The excitation channel was C1:SUS-ETMs_ULCOIL_EXC. I measured the TF from excitation channel to POX11I and POY11I error signal. The measurement range was above 400 Hz and below 1000Hz,. The number of point is 600. I attached that result.
In ETMX curve, the coherence become bad near the resonant frequency of violin mode and also the TF is large. Although ETMX violin modes are obvious, ETMY violin modes are not visible. At 660 Hz, 780 Hz, 900 Hz the coherence is not good. That is because 60 Hz comb noise.

Discussion

 I attached the spectrum of the POX and POY error signal. Black and red curve is measured different time. I didn't inject any signal in both measurement, but the violin mode excitation has huge difference. Also there are peaks at beat frequency between violin mode and bounce mode(16 Hz), yaw motion(3 Hz). In ALS in-loop noise or XARM in-loop measurement, sometimes this region had big spikes. That was because of this resonance. And also that resonance peak couples to POY11I.

 I will measure the Q and design the resonant filter for ALS.

As Jenne's Elog we want to see Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if the signal is saturated while bring the arms into resonance.
I started to connect the spectrum analyser and the 'scope to REFL165 output.

Directional coupler (Mini=-circuits ZMDC-10-2 ZMDC-20-3) was connected just before the dimod boad input. The main output of coupler is plugged into demod board's input.The other output of the coupler is connected to AG4395A using BNC cable.

The spectrum analyser output can be read using netgpibdata in control room. The IP address is 192.168.113.108 and the GPIB address is 17. For this I dissconected the network hub from another AG4395A, which is at the front of 1X2 lack.

I didn't connected the 300 MHz 'scope right now, but tomorrow it will be connected using power splitter and also be able to get data by internet. For connect 'scope to network, I disconected the network hub from SR785.

Rather than limp along with a broken SLOW channel system, I fixed it so that the EDCU files made during the RCG build actually get used and added to the channel list (and thereby available in DV and trends).

I first started by adding all of the EDCU files. This completely fails; daqd just doesn't start and gives some weird exceptions.

So I removed a bunch of them and it runs OK now with ~15000 channels. Previously we had ~1500 slow channels.

An in-between config tonight had ~58000 channels and was also running fine, but the connection to the FB would time out when using DV after several minutes. Possibly we can fix this by adding some more RAM to the FB (the DAQD process uses up 45% of the CPU and 39% of the 8 GB of RAM).

Another issue in getting this to work was that there were a bunch of channel name conflicts between the old C0EDCU.ini and the sub-system EDCU files that I was trying to add. I went through by hand and deleted all of the duplicates from the old file. The new frame files are 80 MB, the old ones were 66 MB.

I hope that /frames doesn't become full - not sure how that is wiped...

Sorry, that was a goof on my part.  It should be working now.

 I have modified the ETM suspension models to include a schmidt triggering block, so that we can choose between using the high gain low power Thorlabs PD and the low gain high power QPD. 

The Thorlabs high gain PD signal is used as the signal to trigger on, so we need to put appropriate thresholds in.

If things are "triggered", that will imply that the Thorlabs PD is seeing a lot of power, so we should be using the QPD SUM channel instead.  There is a "choice" block after the trigger block, to do this switching.

Since the LSC model will only see the output of this choice block, the gain that is currently in C1:LSC-TR[X or Y]_GAIN should be moved to the end SUS model.  We also need to find the correct gain for the QPD sum channels so that they are also normalized to "1" for single arm full power so that we can smoothly go between the 2 diodes.

Rana has promised to make screens, and write scripts for the switching stuff.

 Dataviewer seems to run fine on Chiara (Ubuntu 12), but not on Rossa or Pianosa (Ubuntu 10), or Megatron, which I assume is also something medium-old.

We get the error:

controls@megatron:~ 0$ dataviewer
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Error in obtaining chan info.
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1

Sadface :(   We also get the popup saying "Couldn't connect to fb:8088"

 Really? What cavity length did you use in the calculation?

I calibrated the ALS-OFFSETTER output.
I measured the FSR of cavity in unit of counts. That was 395 counts. Our cavity FSR is 3.8 MHz, so 1 count of the OFFSETTER output is 9.7 kHz.