After speaking with Jenne and Gabriele, I did a little bit of simulating based on my earlier code that looked at the angle of MICH vs. PRCL, just with cavity detuning instead of macroscopic length change.

The zero point in the following plots is with the PRC locked on the sideband. The PRC detuning was done by changing the PRM-BS microscopic length (in terms of phase), and the MICH detuning was done by adding half of the detuning to the BS-ITMY distance, and subtracting half of it from the BS-ITMX distance. 

This plot is in terms of radians, so to roughly relate it to line width, here's a plot of the POP powers as a function of the PRC detuning. 

 And glossing over the MICH offset, here's the PRC offset plots in displacement, rather than radians.

The simulation is actually slightly different now. I now use nominal ITM T values (T=.014) instead of the random R=.99 I had in place. 

(correction: Field Power should be Field Amplitude in the first plot)

I have measured the sensing matrix at a variety of PRCL offset values.

During this each measurement, I also took a 20 second average of the POP 2f signals and the ASDC signal:

All of this data was taken during a single lock stretch. 

If / when I do this again, I want to go out to larger offsets.  I won't take as many points, but I do want to see how far I can go before I lose lock, and what the phase separation looks like at larger offset values (this time, I stopped at +700 counts which is about 0.7nm, to start checking the negative values. MC has been unhappy, so I wasn't able to take very many negative offset values.) 

I conclude that these sensing matrix measurements do see changes in the phase separation with PRCL length offset (what we saw / said yesterday), but that they do not line up with Q's simulation from this afternoon in elog 9671.

The simulation says that we shouldn't be seeing large phase changes until we get out to several nanometers, however the measurement is showing that we get large phase chnages with picometer scale offsets.  Yesterday, Rana and I said that the offsets due to RAM were small (of order picometer), and that they were therefore likely not important (elog 9668).  However, now it seems that the RAM is causing significant length offsets which then cause poor MICH/PRCL phase separation.

To Do List:

* Confirm MIST simulation with Optickle.

* Look at sensing matrix data pre-lockins (in the raw sensors).

* Check that there is no clipping anywhere in the REFL path (at least out of vacuum), and that the beam is sufficiently small on all 4 REFL diodes.

* Calculate the new PRC g-factor with the new length.

All the temporary changes to the video cables and the video MUX ( 3843 ) have been reversed and the system returned to its original state.

[Nichin, Eric G, Koji]

Continuing out work from elog:10037, we wanted to check if the frequency response of AS55. Having figured out exactly how to use the Laser diode controller (LDC 3744C), we hooked up a fiber power meter to the optical fiber illuminating AS55 (that we disconnected from its mount last Friday ) and raised up the current to 150mA to get almost 0.8mW power reading.

When aligning the fiber to illuminate the PD, we found that the beam was pretty wide. So we pulled out the collimator and tweaked it to get a focused beam. The fiber was mounted back and was aligned to get a maximum DC reading. The multimeter readout 30mV finally. Taking the transimpedence as 200ohm approx., the hot current is about 1.5mA.

Network analyzer was now connected to the modulation input of the laser and the RF output from REF DET and AS55 (inputs to RF switch at rack 1Y1) were connected as input to measure the transfer function. We got just noise on the scope of NA. So, then we tried REFL33 as the Input and still got nothing (We were also not sure if this PD was properly illuminated, we did not check). However the REF DET was giving a nice response on the scope. Turns out all the PDs were disconnected form the Demodulator (D990511) on rack 1Y2.

On closer inspection the RF cable between domodulator and RF switch that was labelled AS55 had a loose SMA connector at the switch end. I will have to fix that tomorrow . For the time being Koji connected the cable labelled REFL33 to the AS55 demodulator and we finally got a response form the AS55 PD on the NA. However no readings were recorded. The power supply to REF DET was turned off in the end as Eric G claimed that it has been ON for almost a year now, which is not a good thing. Also, we removed the modulation input from NA to the diode laser and terminated the input with a 50ohm terminator.

We planned to pull out and check each and every RF cable (especially the SMA ends for faulty soldering and loose connections) and fix/ replace them as needed.

Not "hot" current but "photo" current. Is this my bad!?

It was me who told Nichin that the DC transimpedance was 200Ohm. But according to this entry I checked the RF transimpedance of AS55 before.
In my code, the DC transimpedance was defined to be 50Ohm. If we believe it, 30mV corresponds to 0.6mA.

As we had planned yesterday (ELOG 10034) I and Eric Gustafson wanted to manually measure the transimpedence for REFL33. But on closer inspection I found the RF signal cable coming from the Photodiode REF DET (mounted on the POY table), that we were supposed to plug into the network analyzer, did not have an SMA connector at the end. There was just the Teflon and metal part sticking out of the insulation. So we disconnected the cable labeled REF DET from the PD and pulled it out to fix it. (POY table and from near the 1Y1 rack)

Being unable to locate any SMA male connectors in the 40m lab [pasternack PE4025], we headed over to Downs where Rich Abbott did a quick and awesome job of soldering the SMA connector and also teaching me in the process. I will write an ELOG on how to do a clean solder of the SMA connectors to the RF cable shortly for future reference.

Coming back to the 40m we rerouted the REF DET cable from near the 1Y1 rack and into the POY table. This job was done mostly by Eric. We were also unable to locate a torque wrench to tighten the cable at the PD’s end and had to leave it finger tight. Eric is planning to buy a new torque wrench as we will need it often.

Also, I cross checked the SwithList located at /users/alex.cole/switchList with the RF switch connections at 1Y1 rack and turns out it is consistent, except that at CH2 of the first switch where MC REFL was to be connected, there is a unlabeled cable. It might belong to the correct PD, but must be made sure of. The rest of the channels that are not mentioned in the list were unconnected on the RF switch.

Now instead of disconnecting REFL 33 to make measurements with the NA, we had to take out AS55 from the RF switch, as the former was very hard to remove without the torque wrench. Then Eric removed the optical fiber which was illuminating the AS55 (AS table) from its mount to hook it up to the power meter. But then we were not sure of how to operate the Laser diode controller (LDC 3744C) and decided to leave stuff as it is and continue either tomorrow or on Monday. Right now we closed the optical fiber of AS55 with a cap and it remains unmounted. The RF cables of REF DET and AS55 were left hanging near the 1Y1 rack.

Summary:

I've made several changes to the C1MCS model and C1PEM model, and have installed BLRMS filters for the MC mirror coils, which are now running. The main idea behind this test was to see how much CPU time was added as a result of setting up IPC channels to take the signals from C1MCS to C1PEM (where the BLRMS filtering happens) - I checked the average CPU time before and after installing the BLRMS filters, and saw that the increase was about 1 usec for 15 IPC channels installed (it increased from ~27usec to 28usec). A direct scaling would suggest that setting up the BLRMS for the vertex optics might push the c1sus model close to timing out - it is at ~50usec right now, and I would need, per optic, 12 IPC channels, and so for the 5 vertex optics, this would suggest that the CPU timing would be ~55usec. I have not committed either of the changed models to the SVN just yet. 

Details:

1. On Eric's suggestion, I edited the C1_SUS_SINGLE_CONTROL library part to tap the signal at the input to the output filters to the coils, as this is what we want the BLRMS of. I essentially added 5 more outputs to this part, one for each of the coils, and they are named ULIn etc to differentiate it from the signal after the output filters. I have not committed the changed library part to the SVN just yet. 
2. I used the cdsIPCx_SHMEM part to pipe the signals from C1MCS to C1PEM - a total of 15 such channels were required for the three IMC mirrors.
3. I added the same cdsIPCx_SHMEM parts to the C1PEM model in the receiving configuration, and connected their outputs to BLRMS blocks. The BLRMS blocks themselves are named as RMS_MC2_UL_COIL_IN and so on.
4. I shutdown the watchdogs to MC1, MC2 and MC3, and restarted the C1PEM and C1MCS models on C1SUS. Yutaro pointed out that on restarting C1MCS, the IMC autolocker was disabled by default - I have enabled it again manually.
5. I was under the impression that each time a BLRMS block is added, a filter bank is automatically added to the C1PEM.txt file in /opt/rtcds/caltech/c1/chans - turns out, it doesn't and my script for copying the template bandpass and lowpass filtes into the .txt files was needlessly complicated. It suffices to change the filter names in the template file, and append the template file to C1PEM.txt using the cat command: i.e. cat template.txt > C1PEM.txt. The computer generated file seems to organize the filters in alphabetical order, and my approach obviously does not do so, but the coefficients are loaded correctlty and the filters seem to be functioning correctly so I don't think this is a problem (I measured the transfer function of one of the filters with DTT, it seems to match up well with the Foton bode plot). 
6. I added a few lines to the script to also turn on the filter switches after loading the filter coefficients.

Next steps:

Now that I have a procedure in place to install the BLRMS filters, we can do so for other channels as well, such as for the coils and Oplevs of the vertex optics, and the remaining PEM channels (SEIS, accelerometers, microphones?). For the vertex optics though, I am not sure if we need to do some rearrangement to the c1sus model to make sure it does not time out...

In order to use the 0th-order deflection beam from the AOM for cavity mode scans, I've coaligned this beam to the existing mode-matching/launch optics set up for the 1st-order beam.

Instead of being dumped, the 0th-order beam is now steered by two 45-degree mirrors into the existing beam path. The second mirror is on a flip mount so that we can quickly switch between 0th-order/1st-order injections. None of the existing optics were touched, so the 1st-order beam alignment should still be undisturbed.

Currently the 0th-order beam is being injected into the IFO. After attenuating so as to not exceed 100 mW incident on the fiber, approximately 50 mW of power reaches the AS table. That coupling efficiency is similar to what we have with the 1st-order beam. With the Y-arm cavity locked and the AUX PLL locked at RF offset = 47.60 MHz (an Y-arm FSR), I observed a -50 dBm beat note at Y-end transmission.

As per Gautam's request, I list the changes that were made since he left:

1. The AOM driver was connected to a signal generator.

2. The first order beam from the AOM was coupled into the PMC while the zero-order beam is blocked. We might want to keep this configuration if the pointing stability is adequate.

3. c1psl got Burt restored to Dec 1st.

4. Megatron got updated.

Currently, c1susaux seems unresponsive and needs to be rebooted.

Last week Alex merged in the changes I had made to the local 40m copy of the Real Time Code Generator.  These were to add a new part, called FiltMuxMatrix, which is a matrix of filter banks, as well as fixing the filter medm generation code so the filter banks actually have working time stamps.

I checked out a new version of the CDS SVN with these changes merged in.  Changes that will be added in the near future by Rolf and Alex include the addition of "tags".  These are pieces in simulink which act as a bridge between two points, so you can reduce the amount of wire clutter on diagrams.  Otherwise they have no real affect on the generated C code.  Also the ADC/DAC channel selector and in fact the ADC/DAC parts will be changing.  The MIT group has requested the channel selector be freed up for its original purpose in matlab, so Rolf is working on that.

The new checkout includes the new directory scheme Rolf is pushing.  So when you run the code generator and more specifically, install SYS, it places code in /opt/rtcds/caltech/c1/ type directories, like medm, chans, target, scripts.

For the time being, Alex has created a directory /rtcds on Linux1 under /home/cds.  He then created softlinks to that directory on megatron, c1iscex, and allegra in the /opt directory.  This was an easy way to have a shared path.

However, it does mean on each new FE  machine after setting up the mounting of /home/cds from Linux1, we also need to create the /opt/rtcds link to /cvs/cds/rtcds.

After checking out the CDS SVN, we discovered there some files missing that Alex had added to his version, but not the main branch.  Alex came over to the 40m and proceeded to get all those files checked in.  We then checked it out again.  Changes were made to the awg, framebuilder, and nds codes and needed to be rebuilt. 

There's a new naming scheme for models.  You need to include the site before the 3 letter system name.  So lsc.mdl become c1lsc.mdl.

Certain other file name conventions were also changed.  Instead of tpchn_c1.par, tpchn_c2.par, etc, its now tpchn_c1lsc.par, tpchn_c2lsp.par, etc.  The system name is included at the end of the filename, to help make it clearer what file goes with what.

This required an edit of the chnconf file, which has explicit calls to those file names.  Once we edited that file, we had to reload the xinetd service which its apparently a subpart of (this can be accomplished by /etc/init.d/xinetd stop, then /etc/init.d/xinetd start).

/etc/rc.d/rc.local also had to be edited for the new model names (c1lsc, c1lsp, etc).

The daqdrc file (for the framebuilder) now parses which dcu_rate to use from the tpchn_c1lsc.par type files, so the dcu_rate 20 = 16384 lines have been removed.  set gds_server has also been removed, and replaced with tpconfig "/opt/rtcds/caltech/c1/target/gds/param/testpoint.par";  from which it can get the hostname.  This information is now derived from the c1SYS.mdl file.

Hostname needs to be added to the .mdl files, in the cdsParameter block (i.e. host=megatron).

After that Alex informed me the IOP processor needs to be running for the other models to work properly, as well as for the Framebuilder to work.

The models and framebuilder now get their timing signal from the IOP (input/output processor).  This must be running in order for the other models or FB to run properly.  Its generally named c1x00 or c1x01 or similar.  The last two numbers ideally are unique to each FE computer.

Initially there was a problem running on Megatron, because the IOP gets its timing signal from the IO chassis, and there was none connected to megatron.  However, he has since modified the code so that if there's no IO chassis, the IOP processor just uses the system clock.  It has been tested and runs on megatron now.

The FSS SLOW actuator often runs off away from zero and into a region where the mode hopping is bad and makes a lot of frequency noise (e.g. that 8 hour period a few weeks ago when Jamie couldn't lock the MC).

It should not have this behavior. The SLOW loop should only be running when the MC is locked.

Today I found that the threshold was set back to 0.2 V (which is approximately the correct value for the RefCav locking). Its being compared to the MC TRANS, so the correct value should be ~1/2 of the maximum MC TRANS.

To find this out, I read this piece of text:

    # Make sure the loop is supposed to be active
    if (get_value("C1:IOO-MC_TRANS_SUM") < get_value("C1:PSL-FSS_LOCKEDLEVEL")) {
    print("Reference Cavity not locked -- control loop disabled.\n");
    next;
    }

from scripts/PSL/FSS/FSSSlowServo. I set the threshold using the commmand:

caput -c -t C1:PSL-FSS_LOCKEDLEVEL 12000

Then I restarted the code on op340m, by typing:

> nohup FSSSlowServo

and then closing the terminal. Seems to be behaving correctly now. Previously, the value was so low that the SLOW loop was never turning itself off.

I have increased the temperature setpoint in the office area by ~0.75 deg F. Figure attached. Also a few days ago I increased the setpoint of the AC in the control room. Looks like the Laser is able to handle the changes in office area temperature so far, but lets see how it fares over the weekend.

I had to change the c1ioo model and restart the fb since the paths allowing us to select various signals to demodulate using the lockins were not correct. The signal selection vector was not flexible enough to permit us to select the signals to demod.

fb was restarted twice at following times.  The changes have been commited to the svn.

Fri Sep 16 13:35:47 PDT 2011

Fri Sep 16 14:36:21 PDT 2011

I'm looking for an ether net based  power switch for turning lights on and off for the vacuum system from MEDM screen.  This is what I found

Jamie please take a look at it.

 I installed 4 remote AC power on/off strip at

1Y1   for the Vertex area 4 chamber illuminating lights ( CIL )

1Y3   for HV ps for PZT steering mirrors that should be interlocked with P1 pressure gauge. Power off above 3 mTorr

1Y4   for  ETMY CILs,

1X9   for ETMX CILs

I need one volunteer to help me to make MEDM screen and connect the network to the switches.

The cert for nodus has been renewed for another 2 years.

The following is the basic procedure for getting a new cert: (Note certs are only good for two years as of 2018)
openssl req -sha256 -nodes -newkey rsa:2048 -keyout nodus.ligo.caltech.edu.key -out nodus.ligo.caltech.edu.csr
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:CaliforniaLocality Name (eg, city) []:Pasadena
Organization Name (eg, company) [Internet Widgits Pty Ltd]:California Institute of Technology
Organizational Unit Name (eg, section) []:LIGO
Common Name (eg, YOUR name) []:nodus.ligo.caltech.edu

Leave the e-mail address, challenge password and optional company name blank. A new private key will be generated.
chown root nodus.ligo.caltech.edu.key
chgrp root nodus.ligo.caltech.edu.key
chmod 0600 nodus.ligo.caltech.edu.key
The nodus.ligo.caltech.edu.csr file is what is sent in for the cert.
This file should be sent to either ryan@ligo.caltech.edu or security@caltech.edu and copy wallace_l@ligo.caltech.edu.

A URL llink with the new cert to be downloaded will be sent to the requestor.

Once the files are downloaded, the new cert and intermediate cert, they can be copied and renamed.

The PEM-encoded host certificate by itself is saved at:

  /etc/httpd/ssl/nodus.ligo.caltech.edu.crt

The nodus.ligo.caltech.edu.key file should be in the same directory or whichever directory is indicated in the ssl.conf located in /etc/httpd/conf.d/  directory.

httpd will need to be restarted in order for it to see the new cert.

Updated the cert in /etc/httpd/ssl. The new cert is good until March 12, 2022.

Jenne and I centered the MCR camera on the AP table.

We moved the camera as far as it could go on its mount without shifting its screws, and adjusted the optic that the camera looks at for the rest of the way.

 The spot was still off center on the quad display in the control room, so I re-recentered it today.

[Yaakov, Jenne]

The short version:

Rana and Koji pointed out to us that the MCR camera view was still not good.  There were 2 problems:

(1) Diagonal stripes through the beam spot.  Yuta and I saw this a week or 2 before he left, but we were bad and didn't elog it, and didn't investigate.  Bad grad students.

(2) Clipping of the left side of the beam (as seen on the monitors).  This wasn't noticed until Yaakov's earlier camera work, since the clipped part of the beam wasn't on the monitor.

The fix for #1 was to partially close the iris which is the first "optic" the beam sees on the AP table after leaving the vacuum. 

The "fix" for #2 was that the wrong beam has been going to the camera for an unknown length of time.  We picked the correct beam, and all is well again.

We moved the 10% BS that splits the main beam into the (MC REFL PD) path and the (MCR camera + WFS) path.  It looked like the transmission through there was close to the edge of the BS.  We didn't think that this was causing the clipping that we saw on the camera (since when we stepped MC1 in Yaw, the beam spot had to move a lot before we saw any clipping), but it seemed like a good idea to make the beam not near the edge of the optic, especially since, being a 2" optic, there was plenty of room, and we were only using ~half of the optic.  We didn't touch anything else in the WFS path, since that looks at the transmission through this BS, but we had to realign the beam onto MC REFL.

The long version:

(1)  The fix for #1 was to partially close the iris which is the first "optic" the beam sees on the AP table after leaving the vacuum.  It looks like that's why the iris was there in the first place.  When we found it this evening, the iris was totally open, so my current theory is that someone was on the AP table doing something, and accidentally bumped the handle for the iris, then left it completely open when they realized that they had touched it.  I think Steve had been doing something on the AP table around then, but since Yuta and I didn't elog our observation (bad grad students!), I can't correlate it with any of Steve's elogs. We were not able to find exactly where this "glow" that the iris is used to obscure comes from, but we traced it as far as the viewport, so there's something going on inside.

(2)  The "fix" for #2 was that the wrong beam has been going to the camera for an unknown length of time.  We picked the correct beam, and all is well again. 

We spent a long time trying to figure out what was going on here.  Eventually, we moved the camera around to different places (i.e. right before the MC REFL PD, with some ND filters, and then we used a window to pick off a piece of the beam right as it comes out of the vacuum before going through the iris, put some ND filters, then the camera).  We thought that right before the MC REFL PD was also being clipped, indicating that the clipping was happening in the vacuum (since the only common things between the MC REFL PD path and the camera path are the iris, which we had removed completely, and a 2" 10% beam splitter.  However, when we looked at a pickoff of the main beam before any beamsplitters, we didn't see any evidence of clipping.  I think that when we had the camera by MC REFL, we could have been clipping on the ND filters that I had placed there.  I didn't think to check that at the time, and it was kind of a pain to mush the camera into the space, so we didn't repeat that.  Then we went back to the nominal MCR camera place to look around.  We discovered that the Y1 which splits the camera path from the WFS path has a ghost beam which is clipping on the top right side (as you look at the face of the optic) of the optic, and this is the beam that was going to the camera (it's a Y1 since we only want a teensy bit of light to go to the camera, the rest goes to the WFS).  There is another beam which is the main beam, going through the center of the optic, which is the one which also reflects and heads to the WFS.  This is the beam which we should have on the camera.  Yaakov put the camera back in it's usual place, and put the correct beam onto the center of the camera.  We did a check to make sure that the main beam isn't clipping, and when I step MC1 yaw, the beam must move ~1.5mm before we start to see any clipping on the very edge of the beam.  To see / measure this, we removed the optic which directs the beam to the camera, and taped an IR card to the inside of the black box.  This is ~about the same distance as to the nominal camera position, which means that the beam would have to move by 1.5mm on the camera to see any clipping.  The MC REFL PD is even farther from MC1 than our IR card, so the beam has to fall off the PD before we see the clipping.  Thus, I'm not worried about any clipping for this main beam.  Moral of the story, if you made it this far:  There wasn't any clipping on any beams going to either the WFS or the MC REFL PD, only the beam going to the camera.

I centered the oplev of the ETMY, because I found that Yarm lost lock every 10 minutes, and the ETMY oplev was misaligned very much. I attached the 40 minutes trend of oplev and LSC-TRY. Yarm looks more stable. After centering of the oplev, the YARM looks to be more stable.

When both arms were locked, we found that ITMY optical lever was very off-center. This seems to have happened after the c1susaux rebooting we did in June 17th. I opened the ITMY table and realigned the OPLev beam to the center when the arm was locked. I repeated this process for BS, PRM and ETMY. I did PRM because I've known that we have been keeping its OpLev off. The reason was clear once I opened the table. The oplev reflection beam was hitting the PD box instead of the PD. After correcting, I was able to swithc on PRM opLev loops and saw normal functioning.

[Diego, Jenne]

We centered the OpLevs for ITMX and ITMY.
 

I've upgraded our cdsutils installation to v382; there have been some changes to pydv which will allow me to implement the auto y-scaling on our lockloss plots. 

After some brief testing, things seem to still work...

 Aim: to scan the cavitymodes of IMC

The circuit used: 

 Attachment4

Results obtained:

Attachment 1,2,3

I tried the idea that the PRC can resonate f1 and f2 at the same time if the arm gives the reflection phase to f1 and f2 with the ratio of 1 vs 5.

The details are described on wiki. The point is this removes all of the PRC/SRC/asymmetry mumbo jumbo.

The calculated cavity lengths for f_mod of 11.065399MHz are:

• Arm Length: 37.7974 [m]

• PRC Length: 6.7538 [m]

• SRC Length: 5.39915 [m]

• Asymmetry (lx-ly): 0.0342 [m]

Here is the actual values derived from the photos.

• Arm Length: 37.54 [m] (0.26m too short)

• PRC Length: 6.760 [m] (6mm too long)

• SRC Length: 5.415 [m] (16mm too long)

• Asymmetry (lx-ly): 0.0266 [m] (8mm too long)

The code to produce a cavity scan simulation and then fitting the data and re-evaluating the initiallt set parameters can be found in this git repo.

The 'CavitScanSimulation' python script now produces a cavity scan with custom parameters which can be easily modified. It also introduces the first TEMs(n+m=0,1,2,3,4) to the laser with power going as (1/(2(n+m)+1))^2 {Selected carefully}. The only care that needs to be taken is that the frequency span should be somewhere near an integral multiple of the FSR so that there are equal number of resonances for all modes and sidebands. This code, as of now also calls the 'FitCavityScan' script which performs the fitting procedure on the data generated above{This data is actually written in a '.mat' file} and generates the Fit parameter data files. The Simulation code then calls the 'CalculatingPhysicalParameters' script which evaluates the data based on the Fit parameters and outputs some physically relevant results like the FSR, Finesse, Modulation Depths, TMS{Current Output is the Estimated RoCs of the two mirrors which isn't something we want directly, so it can be modified a bit to output TMS based on the HOMs}. The scripts do some 'Linearity' checks which might not really be of much significance but can be seen as a reference. Also, the ipython notebook will show all intermediate plots for the actual data and data with custom noise, fit data, FSR fitting, linearity checks, Bessel Ratio plot with mod_depths.

Hiro Yamamoto has updated SIS (Static Interferometer Simulation) to allow us to do the MCMC based inference of the 40m arm cavity mirror maps. 

The latest version is in git.ligo.org: IFOsim/SIS/

In the examples directory I have put 3 files:

1. mcmcCavityScans.m - runs many cavity scans using parfor and saves the data
2. plotCavityScans.m - loads the .mat file with the data and plots it
3. plotCavityScans.py - python file which also loads & plots, but nicer since python has a transparency option for the traces.

Attached is the plots and the data. The first attached plot is a low resolution one: 200 scans of 100 frequency points each. Second plot is 200 scans of 300 points each.

The run was done assuming perfect LIGO arm params with a random set of Zernike perturbations for each run. The amplitude of each Zernike was chosen from a Normal distribution with a standard deviation of 10 nm.

We need to come up with a better guess for the initial distribution from which to sample, and also to use the more smart sampling that one does using the MCMC Hammer.

 So, I was wrong about which cable it was, probably in my rush to get some lunch.  The actual culprit was the octopus cable that Bob made waaay back in the day (~2 years ago) to go from the "ADC out" of the breakout box (37pin Male Dsub) to 9 BNCs.  As it turns out, the Gur1Z channel of that cable was broken on both ends!!! 

On one end, we have the 37 pin Dsub.  The cable used was so thick (way too thick for this application) that it made a super rigid connection between the wires and the connector, and any bending of the cable stressed this connection, despite the strain-relief of the backshell.  The Gur1Z connection snapped off when I was gently wiggling the connections to check them out.  Also, since the wires were all so thick, they didn't really fit into the hole in the backshell, so 2 or 3 of them were squished.....straight through the insulation so that several channels were shorted together / potentially shorted to ground.  This may explain some of the nasty behavior that Rana and I had seen (although I might have forgotten to elog? My bad.) that even with the inputs of the breakout box all terminated, there was high coherence between the channels.  Terminated inputs should give random noise, so this was fishy. 

On the other end of the cable we have the 9 BNCs.  I had finished redoing the 37pin end of the cable, and was 'beeping' it to check it out, when to my dismay I found that the Gur1Z channels (the inside and the outer shield of the BNC connector) were shorted together.  I removed these 2 wires from the Dsub connector to confirm that the BNC was at fault.  Koji looked at the BNC with me after I chopped it off of the cable.  Bad news strikes again.  To get the wires to fit in the inner pin of the BNC connector, the cable-maker had cut off several strands of the wire to make it skinnier.  It appears that over the years these cut-off strands wiggled their way to touching the outer shield.  This appears to be a danger for all of the BNCs on this cable: a little bit of torque (which one might expect during plugging and unplugging a BNC) and the 2 sides of the differential measurement will be shorted together.

I then decided to start afresh and make my own cable.  I found some AWG26 8-twisted-pair cable laying around underneath the Yarm (since this was all I could find, I was just going to do the Gur1 and Gur2 channels, and leave out the Gur3's).  The 37 Dsub side was easy, but I seem not able to connect such skinny wire to the BNC connectors in a robust way.  Since this bad cable has so far cost me ~2.5 16-hour days of grief, I don't want my new version of it to also be bad.  At this point, I await the advice of one wiser than I. I think BNC connectors are designed for something a little closer to ~20AWG, but I could be wrong.  Also, they are obviously optimized for coax cable. So what I have now is never going to be great.  Maybe tomorrow I can go to the Electronics Shop / Store and buy BNC connectors that are meant to be soldered-to.  That would be awesome.

Since I currently have no functional cable to go from Breakout box to ADC, the Guralps are unplugged for tonight.

Conclusions for the day / evening:  Frank, Alastair and Jenna are mostly absolved of blame, although the traveling to Bridge and opening and closing the box (which usually involves more plugging and unplugging of cables) probably didn't help this cable out too much.  Also, Bob definitely owes me a Sugar Napoleon or something.

 In other news, since the Gur2Z ADC channel is totally wacked, I have taken over (but not renamed) the Ranger channel for Gur2Z for now.  Jan still has the Ranger hostage over in Bridge, so this is okay for now.

Over the day, I have been working on a C++ program to interface with Pylon to capture images and reduce dependence on the Pylon GUI. The program uses the Pylon header files along with opencv headers. While ultimately a wrapper in python may be developed for the program, the current C++ program at, 

/users/jigyasa/GigEcode/Grab/Grab.cpp when compiled as

g++ -Wl,--enable-new-dtags -Wl,-rpath,/opt/pylon5/lib64 -o Grab Grab.o -L/opt/pylon5/lib64 -Wl,-E -lpylonbase -lpylonutility -lGenApi_gcc_v3_0_Basler_pylon_v5_0 -lGCBase_gcc_v3_0_Basler_pylon_v5_0 `pkg-config opencv --cflags --libs`

returns an executable file named Grab which can be executed as ./Grab

This captures one image from the camera and displays it, additionally it also displays the gray value of the first pixel.

I am working on adding more utility to the program such as manually adjusting exposure, gain and also on the python wrapper (Cython has been installed locally on Ottavia for the purpose)!

The 3 Panasonic Ceramic Kits Books, 1206 NPO, SMT are well stocked. The 4 th one needs to be refilled at some values.

I labeled them on the cover for fast access. See Atm1

The Metalized Polyester Film Book with through holes mount are in good shape also. Atm2

The AVX Ceramic 1206,  Garrett cab, range: 1pF - 22 microF 50V...... 67 values

Note here: that the value of dielectric, capacitance / voltage will vary

NPO: 1 pF - 1 nF /  50V .......37 values

X7R : 1 nF -  0.082 microF /  50V,  0.1 microF /  100V.......27 values

Y5V:  4.7 microF / 6.3 V,  10 microF / 10V,  22 microF / 6.3V.........3 values 

To get a feel for the Capacitive Bridge problems, we setup a simple bridge using fixed (1 nF) caps on a breadboard. We used an SR830 Lock-In amplifier to drive it and readout the noise.

We measured the cap values with an LCR meter. They were all within a few % of 0.99 nF.

With a 0.5 V drive to the top of the bridge, the A-B voltage was ~2 mV as expected from the matching of the capacitors.

(** Note about the gain in the SR830: In order to find the magnitude of the input referred signal, one has to divide by G. G = (10 V)/ Sensitivity. 'Sensitivity' is the setting on the front panel.)

1. Directly measuring from Vs to ground gives 0.5 V, as expected. This is done to verify the calibration later on.
2. Shorting the A and B wires to ground gives ~0 V and lets us measure the noise. On the spectrum analyzer it was ~400 nV/rHz at 100 Hz and rising slowly to 4 uV/rHz at 100 mHz. In this state, the sensitivity was 10 mV, so the overall gain was 1000. That gives an input referred level of ~0.4 nV/rHz at the input.

3. Hooking up now to A-B: the signal is ~10x larger than the 'dark' noise everywhere. 2 uV/rHz @ 100 Hz, 10 uV/rHz @ 10 Hz, 50 uV/rHz @ 1 Hz. The spectrum is very non-stationary; changing by factors of several up and down between averages. Probably a problem with the cheapo contacts in the breadboard + wind. The gain in this state was still 1000. So at 1 Hz, its 50 nV/rHz referred to the input.

To convert into units of capacitance fluctuation, we multiply by the capacitance of the capacitors (1 nF) and divide out by the peak-peak voltage (1 V). So the bridge sensitivity is 50e-9 * 1e-9 = 5 x 10^-17 F/rHz.

If we assume that we will have a capacitive displacement transducer giving 1 nF capacitance change for a 0.1 mm displacement, this bridge would have a sensitivity of 5 x 10^-12 m/rHz @ 1 Hz. We would like to do ~50-100x better than this. The next steps should be:

1. Solder it all together on a PCB to have less air current sensitivity and decent contacts.
2. Use a low-noise FET input. Since the impedance of the bridge is ~5 kOhms at this frequency, we are probably current noise limited.
3. Estimate the oscillator amplitude noise sensitivity.

The measurement setup for the Capacitor Bridge Test is still sitting on one of the work benches.

Unless the experiment is supposed to continue today, the equipment shouldn't have been left on the bench. It should have been  taken back to the lab.

Also the cart with HP network analyzer used for the test was left in the desk area. That shouldn't have left floating around in the desk area anyway.

The people responsible for that, are kindly invited to clean up after themselves.

Camera and accesories returned

One HAM-A coildriver and one sat amp borrowed -> QIL

https://nodus.ligo.caltech.edu:8081/QIL/2616

Canon camera / small silver tripod / macro zoom lens / LED ring light borrowed -> QIL

Canon EOS Rebel T3i has been purchased. See rating

OAF is successfully canceling noise again, thanks to Matt!

Here is a plot showing more than a factor of 10 noise reduction around 3Hz (similar to what we saw in the simulations)

The changes that has made it work are:

• use of RANGER channel (with ACC_MC1_X and/or ACC_MC2_X)
• mu = 0.01, tau = 1.0e-6, ntaps = 2000, nDown = 16
• nDelay = 5 and nDelay = 7 both work (may not be so sensitive on delay at low frequencies)
• Main changes: filter bank on the PEM channels (ASS_TOP_PEM_## filters: 0.1:0, 1:, Notch24, AA32)
• Added the AI800 filter for upsampling in MC1 (should not matter)

 Matt suggested playing with the emphasis (EMPH) filters to cancel noise in different frequency bands.

The restore scripts from the IFO config screen half-failed, with this error:

retrying (1/5)...
retrying (2/5)...
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Wed Nov 13 2013 17:24:00.389261330
..................................................................

Jamie, do you know what this might be?  When requested, ETMY was not misaligned or restored, but we got these errors.  So, somehow we're not talking properly to EY, but other things seem fine (the models are running okay, the suspension is damped, etc, etc.)