It is not an angel, it is clearly a four leaf clover (also known as "quadrifoglio"). It is very rare, it brings good luck!

  Very nice!!  I was wondering, shouldn't the driving matrix be such that MICH pushes on SRM as well?

This week, the other SURF students and I got acquainted with the caltech campus, LIGO 40m lab and the expectations of the SURF program.  We went to a lot of safety meetings and lectures that established a framework for the jobs we will be doing over the course of the summer.  I went on several tours of the 40m interferometer (one each with Jenne, Jamie and Steve) to get an overview of the layout and specifics of the setup.  I read parts of R. Ward and A. Parameswaran's theses and Saulson's book in order to prepare myself and gain a broader understanding of the purpose of LIGO.

I also began working in Python this week, primarily graphing PSDs of data from the C1:SUS-ETMY_SENSOR_LR, C1:SUS-ETMY_SENSOR_LL, C1:SUS-ETMY_SENSOR_UR, and C1:SUS-ETMY_SENSOR_UL channels.  I will eventually be using Python to generate the plots for the summary pages, so this is good practice.  The code that I have been working on can be found in /users/elizabeth.davison/script5.py.  Additionally, I have been going through the G1 summary pages and attempting to understand the plots available on them and the code that is available.

My plans for the upcoming week begin with modifying my code and potentially calibrating the channel data so that it is in units of length instead of counts.  I will also access the code from the G1 pages and go over it in depth, hopefully gaining insight into the structure of the website.

I have been working on configuration of the Daily Summary webpages and have been attempting to create a "PSL health" page.  This page will display the PMC power, the temperature on the PSL table and the PSL table microphone levels.  Thus far, I have managed to make the extra PSL tab and configure the graph of the interior temperature, using channel C1:PSL-FSS_RMTEMP.

I have been attempting to make a spectrogram for one of the PMC channels, but there is an issue with the spectrogram setup, as Duncan Macleod noted in ELOG 6686:

"At the moment a package version issue means the spectrogram doesn't work, but the spectrum should. At the time of writing, to use the spectrum simple add 'plot-dataplot2'."

Because of this issue, I have also been trying to make the spectrogram plots work.  Thus far, I have fixed the issue with one of the spectrogram plots, but there are several problems with the other four that I need to address.  I have also been looking at the microphone channels and trying to make the plot for them work.  I checked which microphone was on the PSL table and plotted it in matplotlib to make sure it was working.  However, when I tried to incorporate it into the daily summary pages, the script stops at that point!  It might simply be taking an excessively long time, but I have to figure out why this is the case.

                                                 (I am using channel C1:PEM-MIC_6_IN1_DQ, if this is blatantly wrong, please let me know!!)

The main point of this ELOG is that I have working test-daily summary pages online!  They can be found here:

https://nodus.ligo.caltech.edu:30889/40m-summary-test/archive_daily/20120710/

Also, if anyone has more requests for what they would like to see on the finalized summary pages site, please respond to this post or email me at: endavison@umail.ucsb.edu

Over the past week, I have been focusing on the issues I brought up in my last ELOG,  6956.  I spent quite a while attempting to modify the script and create my own spectrogram function within the existing code.  I also checked out the channels on the PSL table for the PSL health page and produced a spectrogram plot of the PMC reflected, transmitted, and input powers, the PZT Voltage and the laser output power.  When I was entering these channels into the configuration script, I came across an issue with the way the python script parses this.  If there were spaces between the channel names (for example: C1:PSL-PMC_INPUT_DC, C1:PSL-PMC_RFPDDC... etc) the program would not recognize the channels.  I made some alterations to the parsing script such that all white spaces at the beginning and end of the channels were stripped and the program could find them.

 The next thing that I worked on was attempting to see if the microphone channels were actually stopping the program or just taking an extraordinarily long time.  I tried running the program with shorter time samples and that seemed to work quite well!  However, I had to leave it running overnight in order to finish.  I am sure that this difference comes from the fact that the microphone channels are fast channels.  I would like to somehow make it run more quickly, and am thinking about how best to do this.

I finally got my spectrogram function to work after quite a bit of trouble.  There were issues with mismatched data and limit sets that I discovered came from times when only a few frames (one or two) were in one block.  I added some code to  ignore small data blocks  like those and the program works very well now!  It seems like the best way to get the right limits is to let the program automatically set the limits (they are nicely log-scaled and everything) but there are some issues that produce questionable results.  I spent a while adding a colormap option to the script so that the spectrogram colors can be adjusted!  This mostly took so long because, on Monday night, some strange things were happening with the PMC that made the program fail (zeros were being output, which caused an uproar in the logarithmic data limits).  I was incredibly worried about this and thought that I had somehow messed up the script (this happened in the middle of when I was tinkering with the cmap option) so I undid all of my work!  It was only when I realized it was still going on and Masha and Jenne were talking about the PMC issues that I figured out that it was an external issue.  I then went in and set manual limits so that a blank spectrogram and redid everything.

The spectrogram is not operational and the colormap can be customized.  I need to fix the problem with the autoscaled axes (perhaps adding a lower bound?) so that the program does not crash when there is an issue.

Yesterday, I spoke with Rana about what my next step should be.  He advised me to look at ELOGs from Steve (6678) and Koji (6675) about what they wanted to see on the site.  These gave me a good map of what is needed on the site and where I will go next.

I need to find out what is going on with the weather channels and figure out how to calibrate the microphones.  I will also be making sure there are correct units on all of the plots and figure out how to take only a short section of data for the microphone channels.  I have already modified the tab template so that it is similar to Koji's ELOG idea and will be making further changes to the layout of the summary pages themselves.  I will also be working on having the right plots up consistently on the site.

The summary pages are now online (Daily Summary), and will eventually be found on the 40m Wiki page under "LOGS-Daily Summary". (Currently, the linked website is the former summary page site)

Currently, all of the IFO and Acoustic channels have placeholders (they are not showing the real data yet) and the Weather channels are not working, although the Weather Station in the interferometer room is working (I am looking into this - any theories as to why this is would be appreciated!!).

I am looking for advice on what else to include in these pages.  It would be fantastic if everyone could take a moment to look over what I have so far (especially the completed page from July 23, 2012) and give me their opinions on:

1.  What else you would like to see included

2.  Any specific applications to your area of work that I have overlooked

3.  What the most helpful parts of the pages are

4.  Any ways that I could make the existing pages more helpful

5.  Any other questions, comments, clarifications or suggestions

Finally, are the hourly subplots actually helpful?  It seems to me like they would be superfluous if the whole page were updating every 1-2 hours (as it theoretically eventually will).  These subplots can be seen on the July 24, 2012 page.

My email address is endavison@umail.ucsb.edu.

 Thank you!  

Rana and I traced the cables that ran from c1pem1 to the Weather Station monitor.  We found that the flat blue cable that is plugged into c1pem1 was not connected to the black cable from the Weather Station.  We don't know why they are unplugged, but the Weather Station had been inactive since 2010.  Rana plugged them back in (they are now connected via a sketchy connector that had its pins askew) and now the channels are outputting correct data!  Everything else seems to be in good order and now I can use the data from the Weather Station for the summary pages!

This week, I made several modifications to the Summary page scripts, made preliminary Microphone BLRMS channels and, with Rana's help, got the Weather Station working again. 

I changed the spectrogram and spectrum options in the Summary Pages so that, given the sampling frequency (which is gathered by the program), the NFFT and overlap are calculated internally.  This is an improvement over user-entered values because it saves the time of having to know the sampling frequency for each desired plot.  In addition, I set up another .sh file that can generate summary pages for any given day.  Although this will probably not be useful in the final site, it is quite helpful now because I can go back and populate the pages.  The current summary pages file is called "c1_summary_page.sh" and the one that is set up to get a specific day is called "liz_c1_summary_page.sh".  I also made a few adjustments to the .css file for the webpage so that plots completely show up (they were getting cut off on the edges before) and are easier to see.  I also figured out that the minute and second trend options weren't working because the channel names have to be modified to CHANNEL.mean, CHANNEL.min and CHANNEL.max.  So that is all in working order now, although I'm not sure if I should just use the mean trends or look at all of them (the plots could get crowded if I choose to do this).  Another modification I made to the python summary page script was adding an option to have an image on one of the pages.  This was useful because I can now put requested MEDM screens up on the site.  The image option can be accessed if, in the configuration file, you use "image-" instead of "data-" for the first word of the section header.

I also added a link to the final summary page website on the 40 meter wiki page (my summary page are currently located in the summary-test pages, but they will be moved over once they are more finalized).  I fleshed out the graphs on the summary pages as well, and have useful plots for the OSEM and OPLEV channels.  Instead of using the STS BLRMS channels, I have decided to use the GUR BLRMS channels that Masha made.  I ELOGged about my progress and asked for any advice or recommendations a few days ago (7012) and it would still be great if everyone could take a look at what I currently have up on the website and tell me what they think!  July 22 and 23 are the most finalized pages thus far, so are probably the best to look at.

https://nodus.ligo.caltech.edu:30889/40m-summary-test/archive_daily/20120723/

This week, I also tried to fix the problems with the Weather Station, which had not been operational since 2010.  All of the channels on the weather station monitor seemed to be producing accurate data except the rain gauge, so I went on the roof of the Machine Shop to see if anything was blatantly wrong with it.  Other than a lot of dust and spiders, it was in working condition.  I plan on going up again to clean it because, in the manual, it is recommended that the rain collector be cleaned every one to two years...  I also cleared the "daily rain" option on the monitor and set all rain-related things to zero.  Rana and I then traced the cabled from c1pem1 to the weather station monitor, and found that thy were disconnected.  In fact, the connector was broken apart and the pins were bent.  After we reconnected them, the weather station was once again operational!  In order to prevent accidental disconnection in the future, it may be wise to secure this connection with cable ties.  It went out of order again briefly on Tuesday, but I reconnected it and now it is in much sturdier shape!

The most recent thing that I have been doing in relation to my project has been making BLRMS channels for the MIC channels.  With Jenne's assistance, I made the channels, compiled and ran the model on c1sus, made filters, and included the channels on the PEM MEDM screen .  I have a few modifications to make and want to .  One issue that I have come across is that the sampling rate for the PEM system is 2 kHz, and the audio frequencies range all the way up to 20 kHz.  Because of this, I am only taking BLRMS data in the 1-1000 Hz range.  This may be problematic because some of these channels may only show noise (For example, 1-3 and 3-10 Hz may be completely useless).

The pictures below are of the main connections in the Weather Station.  This first is the one that Rana and I connected (it is now better connected and looks like a small beige box), located near the beam-splitter chamber, and the second is the c1pem1 rack.  For more information on the subject, there is a convenient wiki page: https://wiki-40m.ligo.caltech.edu/Weather_Station

The summary pages can now be accessed from the "Daily Summary" link under LOGS on the 40 meter Wiki page.

Over the past week, I have continued refining the summary pages.  They are now online in their final home, and can be easily accessed from the 40 meter Wiki page!  (It can be accessed by the Daily Summary link under "LOGS").  I have one final section to add plots to (the IFO section is currently still only "dummy" plots) but the rest are showing correct data!  I have many edits to make in order for them to be more intelligible, but they are available for browsing if anyone feels so inclined.

I also spent quite a while formatting the pages so that the days are in PDT time instead of UTC time.  This process was quite time consuming and required modifications in several files, but I tracked my changes with git so they are easy to pinpoint.  I also did a bit of css editing and rewriting of a few html generation functions so that the website is more appealing.  (One example of this is that the graphs on each individual summary page are now full sized instead of a third of the size.

This week, I also worked with the BLRMS mic channels I made.  I edited the band pass and low pass filters that I had created last week and made coherence plots of the channels.  I encountered two major issues while doing this.  Firstly, the coherence of the channels decreases dramatically above 40 Hz.  I will look at this more today, but am wondering why it is the case.  If nothing could be done about this, it would render three of my channels ineffective.  The other issue is that the Nyquist frequency is at 1000 Hz, which is the upper limit of my highest frequency channel (300-1000 Hz).  I am not sure if this really affects the channel, but it looks very different from all of the other channels.  I am also wondering whether the channels below 20 Hz are useful at all, or whether they are just showing noise.

The microphone calibration has been something I have been trying to figure out for quite some time, but I recently found a value on the website that makes the EM172 microphones and has a value for their sensitivity.  I determined the transfer factor from this sensitivity as 39.8107 mV/Pa, although I am not sure if all of the mics will be consistent with this.

Please check the summary pages out at the link below and let me know if there are any modifications I should make!  All existing pages are up to date and contain all of the pages I have.

Questions, comments, and suggestions will be appreciated! Contact me at endavison@umail.ucsb.edu

https://nodus.ligo.caltech.edu:30889/40m-summary/

Over the past week, I have been working on my progress report and finalizing the summary pages.  I have a few more things to address in the pages (such as starting at 6 AM, including spectrograms where necessary and generating plots for the days more than ~a week ago) but they are mostly finalized.  I added all of the existing acoustic and seismic channels so the PEM page is up to date.  The microphone plots include information about the transfer factor that I found on their information sheet (http://www.primomic.com/).  If there are any plots that are missing or need editing, please let me know!

I also modified the c1_summary_page.sh script to run either the daily plots or current updating plots by taking in an argument in the command line.  It can be run ./c1_summary_page.sh 2012/07/27
 or ./c1_summary_page.sh now to generate the current day's pages.  (Essentially, I combined the two scripts I had been running separately.)  I have been commenting my code so it is more easily understandable and have been working on writing a file that explains how to run the code and the main alterations I made.  The most exciting thing that has taken place this week is that  the script went from taking ~6 hours to run to taking less than 5 minutes.  This was done by using minute trends for all of the channels and limiting the spectrum plot data.

The summary pages for each day now contain only the most essential plots that give a good overview of the state of the interferometer and its environment instead of every plot that is created for that day.

I am waiting for Duncan to send me some spectrogram updates he has made that downsample the timeseries data before plotting the spectrogram.  This will make it run much more quickly and introduce a more viable spectrogram option.

Today's Summary Pages can be accessed by the link on the wiki page or at:

https://nodus.ligo.caltech.edu:30889/40m-summary/archive_daily/20120808/

Over the past week I have been continuing to finalize the daily summary pages, attempting to keep the total run time under half an hour so that they can be run frequently.  I have had many hang ups with the spectrograms and am currently using second trends (with this method, the entire script takes 15 minutes to run).  I also have a backup method that takes 3 minutes of data for every 12 minutes, but could not implement any interpolation correctly.  This might be a future focus, or the summary pages could be configured to run in parallel and full data for the spectrograms can be used.  I configured Steve's tab to include one page of images and one page of plots and fixed the scripts so that it corrects for daylight savings time (at the beginning of the running, the program prints 'DST' or 'Not DST').

Right now, I am focusing on making coherence plots in a spectrogram style (similar to the matlab 'coh_carpet' function) and a spectrogram depicting Gaussianity (similar to the plots made by the RayleighMonitor).  I have also been working on my  final paper and presentation.

I just wrote a short description of how to run the daily summary pages and the configuration process for making changes to the site.  It can be found in /users/public_html/40m-summary and is named README.txt.  If I need to clarify anything, please let me know!  The configuration process should be relatively straightforward, so it will be easy to add plots or change them when there are changes at the 40 meter.

Looked at ITMX. Johannes and I both saw a fairly large speck of dust near the center of the HR side. We tried to take some photos but couldn't get any with good focus. 

[Lydia, Johannes]

Took photos to document the original OSEM orientation and wrote down the serial numbers for each position. We removed the OSEMs, moved the suspension to the accessible side of the table and took out the optic, which was brought to the clean room to have the magnets reglued. The ETMY chamber is now closed up with the OSEMs and clamps inside on the table, and should not need to be reopened until the magnets have been reattached. 

[ericq, Lydia]

The epoxy arrived. Eric managed to remove the excess glue below the guiderod with a razor blade (see attachment 1). The magnet and dumbell that came apart were reglued successfully and passed the stregth test of picking up the magnet from the table by the dumbell, so the magnet was glued back on the optic and is setting in the gluing apparatus (see attachment 2).

We double checked the polarity against the side magnets on ETMY. Because of the gluing position strategy (a fixed distance toward the HR side from the groove location), the other side magnet appears slightly below the center of the gluing barrel, which after some discussion with Koji was determined to be ok. 

I took some pictures with the digital microscope of the aluminum standoffs removed from ETMX. The first one had some leftover epoxy still attached, so I was able to distinguish which part of the groove was occupied by the wire. A better microscope would help (this one has a maximum magification of 80, 200 or so would be much better) but I was still able to see what looks like a second minimum inside the groove at the wire location (see Attachments 1 and 2). The bottom edge of the standoff shows the profile of the groove on the opposite side from the glue. I took several photos with different lighting angles and at different locations on the microscope stage and convinced myself that this was not just an artificial effect. I also took photos of the groove in a different place and did not see this feature (Attachment 3).

The other standoff in the same container had no visible damage to the groove or to the body of the rod. I rotated it under the mocroscope and could celarly see the 'V' shape all the way around. The smooth undanaged groove caught the light more easily and was obvious. The damaged one is scratched around much of the surface, but the undamaged standoff is very smooth. Eric, were both aluminum standoffs in the container with the extra ruby one taken off ETMX, or was one of them new? in any case, see Attachement 4 for a comparison. The believed damage is somewhat visible on the top edge of the lower standoff in the photo. 

[Edit:] Also, in the drawings it looks like the specified radius for the bottom of the groove (0.001 in) is smaller than the radius of the wire (0.00085 in). This would prevent having two clean points of contact like Steve and Gautam were describing as the goal. This is also true of drawings for the new Sapphire guiderods, though the dimensions are in metric units the specified radius of the groove bottom is smaller than the wire's diameter, but larger than its radius. Maybe this providied the initial ability for the wire to move around and carve two distinct grooves. 

Here are the photos we took showing the magnet positions in the OSEMs, and others showing the positions of the wire and unglued standoff. These were taken before the pitch balancing adjustment Gautam described, which apparently cause UR to be a little too high. Thoe OSEMs were all inserted only until the ends of the magnets were almost inside, to lower the risk of knocking any magnets off.

 At the time of these pictures, all magnets except LL were intentionally positioned slightly above the center of the OSEM in anticipation of wire sag. The LL magnet was approximately centered in the OSEM. It was not possible to get both LL and UL the same height relative to their respective OSEMs, possibly due to a spacing error when they were glued to the optic. 

Attachment 1: Position of wire along bottom of the optic. Looks adequately centered and not kinked. 

Attachment 2: Photo showing good contact between the sandoff and the barrel of the optic. The standoff does not appear to be resting on glue from the guiderod. 

Attachment 3: Shows position of standoff and wire after rough pitch banacing. Wire is visibly resting in the groove.

Attachment 4: SD magnet location photographed through OSEM.

Attachment 5: LL magnet location photographed through OSEM.

Attachment 6: LR magnet location photographed through OSEM.

Attachment 7: UL magnet location photographed through OSEM.

Attachment 8: UR magnet location photographed through OSEM.

Actually, if the power goes off and back on, the ethernet connection comes back online after about 5 seconds, or faster if it is disconnected and reconnected. The main issue was that the cable had partially slipped out (ie both power and network connections were loose); I suggest that the final setup should use ethernet cables that have a locking tab as this one does not. 

[ericq, Lydia]

We changed the seismometer channel names from, e.g. C1:PEM-SEIS_GUR1_X to C1:PEM-SEIS_EY_X.

• GUR1 referred to the seismometer at the Y end, GUR2 referred to the seismometer at the X end, and STS1 referred to the seismometer at the vertex. These have been renamed EY, EX, and BS respectively in all channel and filter names. 
• The models for c1pem and c1oaf were changed in Simulink. The DAQ boxes were also updated with the new names. The script which forcibly renames channels saved to disk was edited to no longer refer to the GUR1, GUR2 etc channels. Going along with what Rana suggested we decided not to change the names of the renamed channels this way when saving, so the data saved from the seismometers can be found under e.g. C1:PEM-SEIS_EY_X_OUT_DQ. 
• The filter files generated by Foton were changed to reflect the new channel names. 
• We compiled the changes to the models and restarted the models on the relevant machines (c1lsc for the c1oaf model and c1sus for the c1pem model). c1sus_aux was down so we manually restarted it to turn off the watchdogs as a precaution before putting too much strain on c1sus. 
• The MEDM screens now show the correct information, relabeled with the new names under PEM-RMS. 
• The striptool display projected on the wall now shows the appropriate C1:PEM-RMS_BS channels and has been renamed to "SeismicRainbowBS.strip" 
• We verivied that the new channels can be accessed live and the data from the DQ channels is saved to disk. 
• After the changes were complete, we attempted to commiting to svn (the commit also included bringing the MEDM screen files into version control.) However the svn server was taking a long time to respond, so we will try again tomorrow to commit the file changes. 
• There are still some lefotver unused channels with name sinculding STS_2 and STS_3 that refer to seismomters we no longer use. We left these alone. 

Summary of new channel names:

C1:PEM-RMS_{BS, EX, or EY}_{X, Y, or Z} followed by the same filtering options as before, e.g. _BP_1_3_OUT

C1:PEM-SEIS_{BS, EX, or EY}_{X, Y, or Z}_{EXC, IN1, IN2, OUT, or OUT_DQ} 

C1:OAF-WIT_{BS, EX, or EY}_{X, Y, or Z}_{EXC, IN1, IN2, or OUT} 

[gautam, johannes, lydia]

We decided to try some different approaches on minimizing the ETMY bounce coupling today, since the peak height in the previously attched spectrum was  higher than the previously recorded levels in 2011 for all but the LR OSEM.

• We recoreded a coarse reference spectrum with the light door off and the HEPA filter on. 
• We attempted to match UL, UR and LL orientation to their apparent position in photos takes before the OSEMs were initially removed. We found that every OSEM showed a stronger bounce coupling, including those that had not been moved. We repeated the spectrum a few times, damping the optic and then turning the damping back off between each data set. The effect persisted, so we decided to move them back to where they started today (the final posiitons of our earlier optimization attempt). 
• The peaks returned to approximately their reference levels for all except LL. UL was still the worst overall, so we attempted to more finely tune its angle without success: we saw increases in the peak height in both directions again (when turned approx. 3-4 degrees). 
• We then turned the UL OSEM by 90 degrees. (See Attachment 1). Surprisingly, the 16.4 Hz peak height was greatly reduced (by a factor of 7-9). We took another spectrum to confirm and the peak was significantly lower than the reference yet again. We decided to leave the OSEM in this configuration in order to take a finer spectrum (See Attachment 2). However, this means that while the magnet looks well centered in the OSEM, the sideways range of motion is reduced and there are no earthquake stops preventing string side to side swings, so care should be taken in the ETMY chamber. 
• Before starting, we had discussed a possilbe mechanism for bounce coupling that could potentially be minimized by turning the OSEM so that the nominal beam direction was horizontal. This would be possible if the beam of light inside the OSEM were directed toward the front or back, i.e. if it had some component parallel to the POS axis. Then, if the component of the beam in the plane of the optic's surface is oriented vertically, the bounce mode will move the edge of the magnet's shadow in and out of the center of the beam, allowing for strong coupling (proportional to the size of the angle). Turning the OSEM by 90 degrees would eliminate this kind of coupling. 
• It's also true that (regardless of the mechanism) minimizing bounce couling for an OSEM maximizes the side coupling. The side coupling values of the pre-vent diagonalization matrices might be useful to compare to what we see now, to find out if the minimization we do in fact increases the side coupling (if not, maybe we are not truly minimizing the bounce coupling but observing some other effect, or our measurement method is too inconsistent.) Thoughts on this are welcome. 
• Now that this improvement has been found, we should do a more thorough investigation to see where the true optimum position is (no small steps have been taken around this new position, and the minimum could also be at some angle in between).
• In the interest of finishing the vent, should we try to find out exactly why the optimal angles seem so different than expected, or should we just try to minimize as best we can and move on to setting up the Y arm cavity? 

[Teng, Lydia]

We would like to establish a system for setting up ADC channels and integrating them into the existing EPICS framework, so that we can gradually switch over channels that are currently handled by the aging slow machines. Otherwise, we will be stuck when they eventually fail. As a preliminary test for this method, we are in the process of setting up an Acromag ADC to read the "Diagnostic" output of the PSL controller. This information will also be useful to monitor the health of the PSL. 

Today, we accomplished the following:

• Configured the Acromag XT1221 for use on the martian netowrk. It is assigned the static IP 192.168.113.237, with hostname iocPSLmon. 
• Connected the Acromag to a switch on the 1X6 cabinet, and set it up on a desk near the X arm door with a 24V DC power supply. 
• Verified that the IP was reachable from a control room desktop. 
• Modified the files from Aiden's wiki page (myiocconfig.cmd and IOCTEST.db) to reflect our setup. 
• Attached input 0 to a DC voltage and retrieved the output over the network. 
  • Channel name: "C3:ACROMAG_INPUT0" 
  • Values are currently uncalibrated, the voltage is represented by a 16 bit signed integer
  • We changed the value of the DC input and verified that the channel output changed in the expected direction

The power supply has been turned off for the night. 

[Lydia, Teng]

We ran the scripts to diagonalize the damping matrices using the free swinging data from staurday night/sunday morning. The actual entries used for damping have not been changed. However, we did generate updated matrices for all the main optics (not including the mode cleaner optics, which were not free swinging over the weekend).

• The scripts appear to be mostly working as intended, with a couple of issues:
  • The plots made by makeSUSSpectra claim to be showing spectra of the individual OSEM readings, but are actually dofs calculated using the ideal input matrix.
  • The existing parameters file (for the peak finding) was only fitting the lorentz peaks to a very narrow band of data, close to the bandwidth of the spectrum. Too narrow a band means that the initial guess must be very close, and also means there are not enough points to fit to.
    • We modified a copy of the paramters file to use a wider band (~.1 Hz) for fitting, and also use updated estimates of the mode frequencies.
    • This was largely successful, but the ITMY POS peak is very close to the SIDE peak, and POS is also stringly coupled to SIDE, so the wider bandwidth fitting can't separate the peaks. (See attachment 1)
    • A longer time series, plus more accurate initial guesses for the resonance frequencies, would allow us to fit to a smaller (~.03 Hz) band without encountering the stated issues.
    • A better way than manually examining plots to choose an initial frequency guess would be to automatically start at the overall maximum point in the spectrum between 0.4 and 1.5 Hz
• Most of the diagonalization results seem good: "Badness" numbers of 4-6 and secondary peaks very supressed or absent on spectra plotted in dof basis (See attachment 2). ITMY, perhaps beacuse of a related issue, has phase problems with the matrix elements that result in messages like "osem/dof 2/1 is imaginary."

The beam splitter that directs light into the MC REFL photodiode has not been replaced; there is still a mirror there. Gautam suggested we wait to replace it until the PSL shutter is open so the beam can be aligned. However, this must be done before going to high power.

GV addendum: What I suggested was to try and recover the arm alignment using the current low power configuration after pumpdown - since we were well aligned just before pumpdown, we should be able to recover this alignment pretty easily at low power. After locking both arms and running the dither align (also center all Oplevs), we can go ahead do the following:

• Replace mirror in MC Refl path with 10% reflection BS (Johannes, Lydia and I confirmed that this is on the AP table earlier today). Then align the reflected beam onto the PD using the tiny mirror
• Replace HR mirror in Transmon path at the EY table
• Replace ND filters on Transmon QPDs at EX and EY tables
• Repalce ND filter on Transmon CCD at EY table
• Revert MC autolocker to the nominal version instead of the low power version we have been using during the vent
• Turn up MC to nominal power by rotating the wave plate on the PSL table - confirm that we have nominal levels by measuring with power meter
• Recover single arm locks, green beatnotes etc at nominal operating conditions
   

Last night from 8:30 pm to 8:30 am PDT, ETMY UL signal was glitchy again. As of now it seems to have quieted back down, but we pushed on the cables on the board at the Y end to hopefully prevent it from coming back. After doing so it still seems to be behaving well.

[Lydia, Teng]

We continued to work on the diagonalization scripts today and devised a way of choosing starting parameters that seems to work much better, and is easier to use, than tuning up to 15 parameters by hand per optic.

• As before, the spectrum for each dof is estimated by using the "ideal" input matrix.
• The starting guess for the peak frequency for each dof is the bin which achieves the maximum value of the spectrum between 0.4 and 1.5 Hz.
• If another dof has a higher value at that frequency, the next highest peak is used. (Sometimes, for example, the peak in PIT at the POS frequency is stronger than the real POS peak!)
• The peak height is initially guessed to be the spectrum value at the initial frequncy guess.
• The width paramter Q can still be read from a file, but for all the times we tried, the peaks were found successfully if Q was initially guessed to be 300, so there might be no need to do this.
• Spectra should still be examined to make sure the results make sense, and once we look at free swinging data in vacuum, we should compare the frequency results to the wiki values.
• Reasonably good matrix values are saved to peakFit/inMats/1157630417. We got good diagonalization results for all but ITMY (see below). The values used for damping have not been overwritten.

We still noticed phase problems with ITMY, which appear to be preventing good diagonalization (See Attachment 1). Almost every degree of freedom has a significant imaginary part in the sensing matrix. We looked at the phases of the cross spectra in DDT and saw that indeed, the OSEM signals do not have the appropriate relative phases at the peak frequencies, especially in PIT and YAW (see Attachment 2: the phase at the peak is about 30 degrees when it should be 180). These phases are different for data takes ~24 hours apart, but are still wrong. We also looked at this information for ETMY and saw the correct behavior. We temporarily moved the pitch and yaw sliders for ITMY and looked at the OSEM response on a striptool, and the signals moved in the expected way. Can anyone suggest a reason why this would be happening? Is there another stretch of data (besides this past weekend) which would be good to compare to?

When I restarted c1susaux yesterday, I didn't know that I needed to disable the coil outputs first. So when it came back online, it attempted to damp all the vertex area optics and ITMX got stuck

We should make a note in the Computer Restart Procedures wiki page indicating the importance of disabling the coils before rebooting c1susaux, c1auxex, and c1auxey. Today c1auxey was rebooted properly without incident. If the slider values etc go back to their previous values on their own, is it necessary to do a BURT restore? I tried doing one for c1susaux today and there were some errors for ASC channels, but the alignment sliders went right back to the proper place after reboot yesterday.

Today the main optics were free swinging for several hours, so I attempted diagonalization in vacuum.

• ITMY still has bad phases. I looked at the spectra for this and other optics, and it looks like the other optics have the 60Hz line notched out for all coils while ITMY only has it notched on the side coil. (Using C1:SUS-ITMY_SENSOR channels). Where is this controlled from, and could it be the source of the issue? 
  • I tried using a different coil as the "standard," with the other coils compared against it in tfestimate. Default is UL, I tried UR and LL. The phase problems were still present for ITMY, but the script was still working fine for other optics.
  • The phase difference between coils is different for different start times.
  • A short segment of the time series for ITMY shows significantly more high frequency noise than for other optics at the same time.
• The ETMY matrix for vacuum has the wrong sign for UL coupling to pitch! The diagonalization results look OK on the graph, but the butterfly mode still has small peaks (See attachment 1). When the individual coil spectra are plotted, the angular degrees of freedom show very weak coupling for UL to pitch, and LL to yaw. We initially replaced the matrix on the MEDM screen with the one generated by the script. After realizing this, the PIT row was changed to 1 1 -1 -1 0, but the effectiveness of the damping on the locked transmission fluctuations was about the same both ways.

[Teng, Lydia]

• We fixed the 60Hz filter on ITMY. This improved the phase problems somewhat but one coil (UL) is still about 12 degrees out of phase compared to the others for all the dofs. Is there some other place where a filter coule be applied to just one coil sensor? I pressed the "Load coefficients" button for UL, so maybe that will have helped.
• We want to interpret the coil signals to have an accurate measurement of each dof. This means what the input matrix should describe is the dependence of each dof on the OSEM signals, which is found by inverting the matrix which describes the sensitivity of each OSEM to changes in that degree of freedom.
  • We looked at the spectra of the individual coils for ITMY and ETMY (See attachment 1 & 2). The coupling between some coils and applicable resonance peaks is very weak (~0.1 times the sensitivity of the other coils).
  • However, when a certain degree of freedom, e.g. pitch, is deliberately driven using awggui, the response of the ITMY coils is clear on the StripTool and is about the same magnitude for all of the face OSEMS. So, it seems like the diagonalization script does not always succeed at measuring the relative sensitivity of the OSEMs to the degrees of freedom.
  • This may be because the fundamental swing modes experienced by the free swinging pendulum are not the same as what we measure as pitch, yaw, etc. This could be possible if the wire tension is not the same on both sides. For ITMY, the spectra imply that the funamdental frequencies are actually at some linear combinations of pitch and yaw, swinging about a diagonal axis that results in a much weaker response for some of the OSEMS. Calling these peaks pitch and yaw may be inaccurate. Certainly they do not indicate the true relative sensitivity of the coils.
  • We propose an alternate approach to measuring this sensitivity: drive one dof at a time with awggui, take a spectrum (less resolution is ok because we already know the drive frequency), and measure the sensing matrix values for that dof the same way as before, but using a spectral peak that decribes motion that we know is purely pitch. Repeat this for all 4 dofs that we can actuate on, then compile these results into a sensing matrix and take the inverse.

[Lydia, Teng]

We built matrices for ITMY and ETMY by driving one degree of freedom at a time with awggui, while the damping was on. These have been applied to the damping loops.

• Each segment of data is 1000s long and each dof was driven at 0.25 Hz.
• These matrices are much closer to the ideal matrix and have no wrong signs. We believe they represent the relative sensitivity of the OSEMs to the degrees of freedom much more accurately. This is because the free swinging modes are not actually pitch, yaw, etc, but some linear combination of these. However, the damping actuates on pitch, yaw, etc. So we should isolate the degrees of freedom by driving them one at a time instead of just looking at free swinging peaks.
  • Attachment 1: An example of the dof spectra, calculated using the default input matrix, when ETMY YAW was driven at 0.25 Hz.
  • Attachment 2: The same OSEM sensor data, with the dofs calculated using the matrix found from this data. There is still a significant peak in pitch, but the other dofs are significantly suppressed.
  • Attahcment 3: The same data again, but the dofs are measured with the input matrix calculated by the free swinging data. This achieves much less suppression than the new matrix. Obviously this is not exactly a fair comparison because the new matrix was generated with this data, but the method of measuring OSEM responses by driving peaks has a much close relationship between what it measured (the OSEM response), and how the matrix is used (by damping loops which drive the coils in much the same way as awggui).
• The phase problems seem to be mostly solved. Both Y arm test masses have some phase warnings, but they mostly occur with side. This can happen because the ideal matrix elements are 0, so the real parts are small. If there is no strong coupling then there is no reason to expect the background spectrum to be in phase with the peak. Other phase differences are small; most less than 5 degrees, a couple between 5 and 10 degrees. This may still merit further investiagtion.
• Comparing the damping results for ITMY with the old (based on free swinging data) and new (based on driven data), we see the 1Hz peak suppressed by ~35% and the noise above 1Hz generally suppressed by ~25-30% . There is, however, significantly more movement between 0.5 and 1 Hz, maybe because the fundamental physical modes are not being directly measured and suppressed. Overall this seems like an improvement.

GPS times:

ITMY

Pitch:1158085097 Yaw: 1158086537 Pos: 1158089237 Side: 1158087977

ETMY

Pitch: 1158095897 Yaw: 1158097577 Pos: 1158099377 Side: 1158100817

Today the Y arm was locking fine. The alignment had drifted somewhat so I ran the dither and TRY returned to ~0.8. However, the mode cleaner has been somewhat unstable. It locked many times but usually for only a few minutes. Maybe the alignment or autolocker needs to be adjusted, but I didn't change anything other than playing with the gain sliders (which didn't seem to make it either better or worse).

ITMX is still stuck.

Here's the timeseries plots. I've zoomed in to right after the problem- did you want before? We pretty much know what happened: c1susaux was restarted from the crate but the damping was on, so as soon as the machine came back online the damping loops sent a huge signal to the coils. (Also, it seems to be down again. Now we know what to do first before keying the crate.) It seems like both right side magnets are stuck, and this could probably be fixed by moving the yaw slider. Steve advised that we wait for an experienced hand to do so. 

Rana came by and freed ITMX again. I think it shouldn't be a problem for me to free it if it happens again. 

In hopes of getting better SNR on the free swing spectra, we kicked all optics at around 7pm. The damping should come back on a little after midnight. ITMX did not get stuck after this kick. 

We moved the Acromag and its power supply to the X end, where we connected it to the diagnostic output of the NPRO controller. We renamed the channels to be descriptive of the pin outputs as described in the laser manual. We were able to recover readouts similar to those we found with a multimeter. 

We should figure out how to set up the channels on the front end machines: right now they are accessed through a tmux session running on pianosa. Once we are confident in the operation, we will make a box to contain the Acromag and wire connections and move the setup to connect to the PSL controller. 

This afternoon around 2:45, ITMX started ringing up at ~.9Hz for about a minute and then got stuck again. When I noticed this evening, I tried to free it with the alignment sliders but was unable to see any signal on UL or UR. It also looks like the damping for ITMY was turned off at the same time ITMX got stuck (not at the start of its ring up). SRM also has a spike in its motion at this time, and another one minute later that ended up with the LR OSEM at a much higher level, though the mirror does not appear to be stuck. We didn't see any strange behavior from any of the other optics.

Teng and I were working on diagnosing a problem with the ITMY UL whitening, but by the time we disconnected any applicable cables, the damping for ITMY was already off. Later we unplugged the ITMX PD whitening cables after verifying that the ITMX damping was also already off. This problem may have occured earlier, while Teng, Eric, and I were examining and pushing in the cables at 1X5 without unplugging anything.

We found that the reason for the bad phase on the ITMY free swing data is because the whitening filter for UL is not being properly turned on. We are in the process of investigating the source of this problem. Right now all the cables to the PD whitening boxes in 1X5 are switched between ITMY and ITMX.
 

[Teng, Lydia]

When we plugged in the back cables yesterday on the whitening boxes after switching them, two of the ITMX PDMon channels (UR and LR) got stuck at 0. This caused me to believe ITMX was still stuck even when it was freed. However, it was left in a stuck state overnight and freed again today after this issue was discovered. The alignment sliders have been set to 0 as a safety net to keep ITMX from getting stuck again if c1susaux is restarted again. We switched the cables back and the problem was still there.

The ITMY UL whitening filter problem, which the cables were originally switched to diagnose, was also still there. Ericq suggested we turn off all the whitening filters in order to get diagonalization data that would not show a phase difference between coils. We ran the diagonalization again with all the dewhitening filters off and got much cleaner results, with no visible cross-coupling peaks remaining between the degrees of freedom (see attachemnt 1). We did not apply this matrix to the damping, however, because there are elements which have the wrong sign compared to the ideal matrix. Significant adjustments to the output matrix will probably need to be made if this result is to be used. We also verified that the phase problem had been solved in DTT, where we saw the same sign discrepancies as in the matrix below. 

Damping can be turned back on, using the old, non-diagonalized matrix currently in effect. There is enough free swing data to diagonalize ITMY now, so feel free to mess with it. 

Matrix (wrong signs red, suspiciously small elements orange):

           pit     yaw     pos         side    butt
UL    1.633   0.138   1.224   0.136   0.984  
UR   -0.202  -1.768   1.179   0.132  -1.028  
LR   -2.000   0.094   0.776   0.107   1.001  
LL   -0.165   2.000   0.821   0.111  -0.987  
SD    0.900   1.131  -1.708   1.000  -0.107  

[Lydia, Teng]

Motivated by the strange pitch/yaw coupling behavior we ran into while doing diagonalization, we looked at the oplev pitch and yaw free swing spectra for all 4 test masses (see attachment 1). We saw the same behavior there: At the peak frequencies for the angular degress of freedom, the oplevs saw significant contributions from both pitch and yaw. We also examined the phase between pitch and yaw at these peaks and found that consistently, pitch and yaw were in phase at one of the resonance frequencies and out of phase at the other (ignoring the pos and side peaks). 

This corresponds physically to angular motion about some axis that is diagonal, ie not perfectly vertical or horizontal. If we trust the oplev calibration, and Eric says that we do, then the angle of this axis of rotation with the horizontal (pitch axis) is

Where Y and P are yaw and pitch ASD values. This will always give an angle between 0 and 90 degrees; which quadrant the axis of rotation occupies can be dermined by looking at the phase between pitch and yaw at the same frequencies. 0 phase means that the axis of rotation lies somewhere less than 90 degrees counterclockwise from the horizontal as viewed from the AR face of the optic, and a phase of 180 degrees means the axis is clockwise from horizontal (see attachment 2). Qualitatively, these features show up the same way for segments of data taken at different times. In order to get some quantitative sense of the error in these angles, we found them using spectrogram values with a bandwidth of 0.02 Hz averaged over 4000 seconds. 

Results (all numbers in degrees unless otherwise specified):

ITMY
peak 1 ( 0.692  Hz):
mean: 24.991
std: 1.23576
ptich/yaw phase: -179.181
peak 2 ( 0.736  Hz):
mean: 21.7593
std: 0.575193
pitch/yaw phase: 0.0123677

ITMX
peak 1 ( 0.502  Hz):
mean: 17.4542
std: 0.745867
ptich/yaw phase: -179.471
peak 2 ( 0.688  Hz):
mean: 74.822
std: 0.455678
pitch/yaw phase: -0.43991

ETMX
peak 1 ( 0.73  Hz):
mean: 43.1952
std: 1.54336
ptich/yaw phase: -0.227034
peak 2 ( 0.85  Hz):
mean: 60.7117
std: 0.29474
pitch/yaw phase: -179.856

ETMY
peak 1 ( 0.724  Hz):
mean: 78.2868
std: 2.18966
ptich/yaw phase: 6.03312
peak 2 ( 0.844  Hz):
mean: 26.0415
std: 2.10249
pitch/yaw phase: -176.838

ETMY and ITMX both show a more significant (~4x) contribution from pitch on one peak, and from yaw on the other. This is reflected in the fact that they each have one angle somewhat close to 0 (below 30 degrees) and one close to 90 (above 60 degrees). The other two test masses don't follow this rule, meaning that the 2 angular frequency peaks do not correspond to pitch and yaw straightforwardly. 

Also, besides ITMX, the axes of rotation are at least several degrees away from being perpendicular to each other. 

Summary: At the 40m meeting yesterday, Eric Q. gave the suggestion that we accept the input matrix weirdness and adjust the output matrix by driving each coil individually so that it refers to the same degrees of freedom. After testing this strategy, I don't think it will work. 

Yesterday evening I tested this idea by driving one ITMY coil at a time, and measuring the response of each of the free swing modes at the drive frequency. I followed more or less the same procedure as the standard diagonalization: responses to each of the possible stimuli are compared to build a matrix, which is inverted to describe the responses given the stimuli. For the input matrix, the sensor readings are the responses and the free swing peaks are the stimuli. For the output matrix, the sensors transformed by the diagonalized input matrix as the responses of the dofs which are compared, and the drive frequency peak associated with a coil output is the stimulus. However, the normalization still happens to each dof independently, not to each coil independently. 

The output matrix I got had good agreement with the ITMY input matrix in the previous elog: for each dof/osem the elements had the same sign in both input and output matrices, so there are no positive feedback loops. The relative magnitude of the elements also corresponded well within rows of the input matrix. So the input and output matrices, while radically different from the ideal, were consistent with each other and referred to the same dof basis. So, I applied these new matrices (both input and output) to the damping loops to test whether this approach would work. 

drive-generated output matrix: 

      UL      UR      LR       LL      SD
pit    1.701  -0.188  -2.000  -0.111   0.452  
yaw    0.219  -1.424   0.356   2.000   0.370  
pos    1.260   1.097   0.740   0.903  -0.763  
sid    0.348   0.511   0.416   0.252   1.000  
but    0.988  -1.052   0.978  -0.981   0.060

However, when Gautam attempted to lock the Y arm, we noticed that this change significantly impacted alignment. The alignment biases were adjusted accordingly and the arm was locking. But when the dither was run, the lock was consistently destroyed. This indicates that the dither alignment signals pass through the SUS screen output matrix. If the output matrix pitch and yaw columns refer instead to the free swing eigenmodes, anything that uses the output matrix and attempts to align pitch and yaw will fail. So, the ITMY matrices were restored to their previous values: a close to ideal input matrix and naive output matrix. We could try to change everything that is affected by the output matrices to be independent of a transformation to the free swing dof basis, and then implement this strategy. But to me, that seems like an unneccessary amount of changes with unpredictable consequences in order to fix something that isn't really broken. The damping works fine, maybe even better, when the input matrix is set by the output matrix: we define pitch, for example, to be "The mode of motion produced by a signal to the coils proportional to the pitch row of the naieve output matrix," and the same for the other dofs. Then you can drive one of these "idealized" dofs at a time and measure the sensor responses to find the input matrix. (That is how the input matrix currently in use for ITMY was found, and it seems to work well.) 

[Lydia, Johannes]

Johannes acquired a crate to contain the Acromag setup and wiring, and installed a rail along the bottom panel so that the ADC units will be oriented vertically with the ehternet ports facing up. We briefly talkes about what the layout should be, and are thinking of using 2 rails, one for ADCs and one for DACs. We want to design a generic front panel to accept 25 pin D-Sub inputs and maybe also BNCs, which we can use for all the Acromag crates. 

I got the epics session for the acromag to run on c1iscex and was able to access the channel values using caget on donatella. However, I get the following warning: 

cas warning: Using dynamically assigned TCP port 48154,
cas warning: but now two or more servers share the same UDP port.
cas warning: Depending on your IP kernel this server may not be
cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST)

It seems like there might be a way to assign a port for each unit, if this is a problem. 

Also, c1iscex doens't have tmux; what's the best way to run the modbusApp and then detach? Right now I just left an epics session running in an open terminal. 

Plans:

• Deisgn crate connections and interior layout. Set up front panel to accept desired connections. 
• Set up the crate with the Acromag XT1221 reading the diagnostic info from the X end NPRO in the X end rack.
• Figure out how many of each type we need to replace c1auxex functionality, and order them.
• Generate appropriate EPICS db files for acromag based on slow machine channels.
• Add necessary units to X end Acromag crate and read in the same inputs as c1auxex. 
• Set up everything else to look for c1auxex channels from Acromag instead. (Not sure about nuances of this step: should we name the channels something different at first? How to find everything that relies on c1auxex? Must be careful with SUS channel connections.)
•  Determine number of units needed to replace all slow machines, and order thm. Likewise assemble as many crates as necessary with the right connections. 
• Once we are confident that the replacement is complete and fully functional, disconnect c1auxex and repeat process for other slow machines. 

[ericq, lydia]

Background: 

We believe the optimal OSEM damping would use an input matrix diagonalized to the free swing modes of the optic, and an output matrix which drives the coils appropriately to damp these free swing modes. As was discovered, a free swinging optic does not necessarily have eigenmodes that match up perfectly with pitch and yaw, however in the current state the "TO_COIL"  output matrix that determines the drive signals in response to the diagonlized sensor output also controls the drive signals for the oplevs, LSC/ASC, and alignment biases. So attempts to diagonalize the output matrix to agree with the input matrix have resulted in problems elsewhere. (See previous elog). So, we want to expand the "TO_COIL" matrices to treat the OSEM sensor inputs separately from the others.

Today:

• We modified the ETMX suspension model (c1scx) to use a modified copy of the sus_single_control block (sus_single_control_mod) that has 3 additional input columns. These are for the sensing modes determined by the input matrix, and are labeled "MODAL POS", "MODAL PIT", and "MODAL YAW." 
  • The regular POS, PIT, and YAW columns no longer include the diagonalized OSEM sensor signals for ETMX.
  • The suspension screen now out of date; it doesn't show the new columns under Output Filters and the summed values displayed for each damping loop do not incluse the OSEM damping.
• The new matrix can be acessed at /opt/rtcds/caltech/c1/medm/c1scx/C1SUS_ETMX_TO_COIL.adl (see Attachment 1). For now, it has the naive values in the new columns so the damping behavior is the same. 
• In trying to get a properly generated MEDM screen for the larger matrix, we discovered that the Simulink block for TO_COIL specifies in its description a custom template for the medm autogeneration. We made a new verion of that template with extra columns and new labels, which can be reused for the other suspensions. These templates are in /opt/rtcds/userapps/release/sus/c1/medm/templates, the new one is SUS_TO_COIL_MTRX_EXTRA.adl
• I will be setting the new column values to ones that represent the diagonlized free swing modes given by the input matrix. Hopefully this will improve OSEM damping without getting in the way of anything else. If this works well, the other SUS models can be changed the same way. 

Here are the channels we are planning to switch over from c1auxex to Acromag, and their current pin numbers on the existing VME boards. 

Analog inputs: 

C1:SUS-ETMX_UL_AIOut    #C0 S0
C1:SUS-ETMX_LL_AIOut    #C0 S1
C1:SUS-ETMX_UR_AIOut    #C0 S2
C1:SUS-ETMX_LR_AIOut    #C0 S3
C1:SUS-ETMX_Side_AIOut    #C0 S4
C1:SUS-ETMX_OL_SEG1    #C0 S5
C1:SUS-ETMX_OL_SEG2    #C0 S6
C1:SUS-ETMX_OL_SEG3    #C0 S7
C1:SUS-ETMX_OL_SEG4    #C0 S8
C1:SUS-ETMX_OL_X    #C0 S9
C1:SUS-ETMX_OL_Y    #C0 S10
C1:SUS-ETMX_OL_S    #C0 S11
C1:SUS-ETMX_ULPD    #C0 S12
C1:SUS-ETMX_LLPD    #C0 S13
C1:SUS-ETMX_URPD    #C0 S14
C1:SUS-ETMX_LRPD    #C0 S15
C1:SUS-ETMX_SPD    #C0 S16
C1:SUS-ETMX_ULV    #C0 S17
C1:SUS-ETMX_LLV    #C0 S18
C1:SUS-ETMX_URV    #C0 S19
C1:SUS-ETMX_LRV    #C0 S20
C1:SUS-ETMX_SideV    #C0 S21
C1:SUS-ETMX_ULPD_MEAN    #C0 S12
C1:SUS-ETMX_LLPD_MEAN    #C0 S13
C1:SUS-ETMX_SDPD_MEAN    #C0 S16

Analog Outputs:

C1:ASC-QPDX_S1WhiteGain    #C0 S0
C1:ASC-QPDX_S2WhiteGain    #C0 S1
C1:ASC-QPDX_S3WhiteGain    #C0 S2
C1:ASC-QPDX_S4WhiteGain    #C0 S3
C1:SUS-ETMX_ULBiasAdj    #C0 S4
C1:SUS-ETMX_LLBiasAdj    #C0 S5
C1:SUS-ETMX_URBiasAdj    #C0 S6
C1:SUS-ETMX_LRBiasAdj    #C0 S7
C1:LSC-EX_GREENLASER_TEMP    #C0 S0 This appears to have the same pin as another channel-- is it not being used? 

Binary Outputs:

C1:SUS-ETMX_UL_ENABLE    #C0 S0
C1:SUS-ETMX_LL_ENABLE    #C0 S1
C1:SUS-ETMX_UR_ENABLE    #C0 S2
C1:SUS-ETMX_LR_ENABLE    #C0 S3
C1:SUS-ETMX_SD_ENABLE    #C0 S4
C1:ASC-QPDX_GainSwitch1    #C0 S7
C1:ASC-QPDX_GainSwitch2    #C0 S8
C1:ASC-QPDX_GainSwitch3    #C0 S9
C1:ASC-QPDX_GainSwitch4    #C0 S10
C1:AUX-GREEN_X_Shutter2    #C0 S15

We set up the chassis in 1X7 today. Steve is ordering a longer 25 pin cable to reach. Until then the PSL diagnostic channels will not be usable.

I took data of the ETMX SUSPOS, SUSPIT and SUSYAW channels while driving each of the 4 face coils. I manually turned off all the damping except the side. 

Excitation: I used white noise bandpassed from 0.4 to 5 Hz in order to examine the responses around the resonance frequencies. To avoid ringing things up too much, I started with a very weak drive signal and gradually increased it until it seemed to have an effect on the mirror motion by looking at the oplev signals/sensor RMS values on the SUS screen; it's possible I'll need to do it again with a stronger signal if there's not enough coherence in the data. 

Finding the matrix: The plan is to estimate the transfer function of the coil drive signal with the sensed degrees of freedom (specified by the already diagonalized input matrix). This transfer function can be averaged around the resonance peak for each dof to find the elements of the matrix that converts signals to dof responses, (the "response matrix", which is the inverse of the output matrix). Each column of the response matrix gets normalized so that the degrees of freedom influence the drive signals in the right ratio. 

Other notes: 

• I had some trouble getting the awg python library to work: I had to manually edit a CDLL statement to use the absolute path of an .so file. I wasn't sure what environment variable to set to make it look in the right folder automatically.
• The awg ArbitraryLoop object seems to be affected by cds getdata calls (The EXC signal stopes early and then stop() hangs) so I ended up doing the excitation and data reading in 2 separate scripts. 
• Reminder that the watchdogs must be on "Normal" for the EXC signal to make it to the coils, so the damping must be turned off manually with the watchdogs still on if you want to drive without damping. 

I've attached a schematic for how we will connect the Acromag mosules to the slow channel I/O curently going to c1auxex. The following changes are made:

• We are getting rid of the slow readbacks from the Anti-Image and Oplev boards, as Rana says they are unnnecessary.
• The whitening switching for the QPD is currently done by a Contec "fast" binary I/O module, but can be managed by acromag instead. This alllows CAB_1Y9_34 to  be fed directly into the Acromag box since all of its connections can now be managed slow. 
• There's no need to change the PD whitening scheme around (since the signals never get huge), so we can set those to always be on and then lose those Contec channels. This means all of the necessary pins on CAB_1Y9_10 can go to Acromag. 
• All the other backplane cables go the the fast machines only. 

I looked into converting the QPD whitening switches for the X end to Acromag.

• To test this out and be able to freely toggle filters without messing anything up, I added a temporary dummy cdsFiltCtrl module (ACROMAG_BIO_TEST) to the c1scx model.
• The filters can be toggled from the automatically generated medm screen medm/c1scx/C1SCX_ACROMAG_BIO_TEST.adl
• The control output of the dummy filter bank is sent to a channel named C1:SCX-ACROMAG_SWCTRL.
• I was able to read in the appropriate bits from there and send them to the appropriate acromag channel using a calcout channel.
  • I couldn't get individual bo channels to work. This Acromag module is configured to write to 4 channels at a time, so I set that up with an analog output channel. The calcout channel shifts each relevant bit from C1:SCX-ACROMAG_SWCTRL to the right place for writing to the Acromag. 
• I connected the Acromag XT1111 Binary I/O unit to a temporary power supply and verified that toggling the filters on and off changed the output appropriately. This is a sinking output model so the output pin is connected to the return if the switch is on. 

The plan from here:

• Determine how to configure these outputs to be compatible with the QPD whitening board.
• Modify the SUS PD whitening board to always use the analog filter and remove digital option in models.
• Test DACs 
• Verify that the QPD whitening gain switches aren't doing anything
• Assemble new Acromag box for X end and connect to QPD whitening, SUS PD whitening and SOS driver boards

[Lydia, gautam]

To measure the modulation depth of the 29.5 MHz sideband, we plan to connect a bidirectional coupler between the EOM and the triple resonant circuit box. This will let us measure the power going into the EOM and the power in the reflection. According to the manual for the EOM (Newport 4064), the modulation depth is 13 mrad/V at a wavelength of 1000 nm. Before disconnecting these we will turn off the Marconi.

Hopefully we can be gentle enough that the EOM can be realigned without too much trouble. Before touching anything we'll measure the beam power before and after the EOM so we know what to match after.

If anyone has an objection to this plan, speak now or we will proceed tomorrow morning.

Rebooted c1iscaux, c1auxex and c1auxey which were all not reponding to telnet. The watchdogs for the ETMs were turned off and then I keyed all 3 crates. All slow machines are reponding to telnet now. Both green lasers locked to the arms so I didn't do any burt restore.

[gautam, Lydia]

We set out to measure the 29.5 MHz power going to the EOM today but decided to start by looking at the output of the RF AM stabilizer box first. We wanted to measure the AM noise with a mixer, so we needed to know the power it was giving. We looked at the ouput that goes to the power combiner on the PSL table and found it was putting out only -2.0 dBm (~0.5 Vpp)! This was measured by taking a spectrum with the AG4395 and confirmed by looking on a scope.

To find out if this could be adjusted, we found an old MEDM screen (/opt/rtcds/caltech/c1/medm/c1lsc/master/C1LSC_RFADJUST.adl) and moved the 29.5 MHz EOM Mod Index Adjust slider while measuring the voltage coming in to the MOD CONTOL connection on the front of the AM stabilizer box. Moving the slider from 0 to 10 changes the input voltage linearly from -10 V to 10 V measured with a DMM at the cross-connects as we couldn't find an appropriate adapter for the LEMO cable. The 29.5 MHz modulation only appeared for slider values between 0 and 5, after which it abruptly shuts off. However, changing the slider value between 0 and 5 (Voltage from -10 to 0) does not change the amplitude of the output.

This seems like a problem; further investigation into the AM stabilizer box is neccessary. This DCC document outlines how to test the box, but we can't find a schematic. Since we don't have any mixers that can handle signals as small as -2 dBm, we gave up trying to measure the AM noise and will attempt to measure that and the reflection power from the EOM + resonant circuit once this problem has been diagnosed and fixed.

GV: After some digging, I found the schematic for the RF AM stabilization box (updated wiki and added it to the 40m document tree). According to it, there should be up to +22dBm of RF AM stabilized output to the EOM available, though we measured -2dBm yesterday, and could not vary this level by adjusting the EPICS voltage value. Neglecting losses in the cabling and the power combiner on the PSL, this translates to a paltry 0.178Vrms*0.6*8mard/Vrms ~ 0.85 mrad of modulation depth (gain at 29.5 MHz of the triple resonant circuit taken from this elog)... I think we need to pull this 1U chassis out and debug more thoroughly...

[gautam, Lydia]

We looked at the RF AM stabilizer box to see if we could find out 1) Why the output power is so low, and 2) Why it can't be changed with the DC input "MOD CONT IN." Details to follow, attached is the annotated schematic from DCC document D000037. 

We are not returning the box tonight so the PSL shutter remains closed.