40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 78 of 330 Not logged in
ID Date Author Type Category Subject
12722   Mon Jan 16 18:54:01 2017 ranaUpdateSUSBS: whitening re-engaged

Found that the BS whitening was off. Gautam says that "it has always been that way" and "there's nothing in the elog about this" and "I have no special relationship with Putin".

I looked at DV and DTT while turning the OSEM whitening back on. As expected, the sensor noise improved by 10x above 10 Hz. The time series shows no problems - its just less fuzzy now.

All OSEM spectra after the switch show on upper panel of plot. Lower panel shows comparison of BS UL before/after. To rotate the DTT PDF landscape output I typed this:

pdftk BS-white.pdf cat 1N output BSwhite.pdf

"if you see something, do something"

Attachment 1: BSwhite.pdf
12721   Mon Jan 16 12:49:06 2017 ranaConfigurationComputersMegatron update

The "apt-get update" was failing on some machines because it couldn't find the 'Debian squeeze' repos, so I made some changes so that Megatron could be upgraded.

I think Jamie set this up for us a long time ago, but now the LSC has stopped supporting these versions of the software. We're running Ubuntu12 and 'squeeze' is meant to support Ubuntu10. Ubuntu12 (which is what LLO is running) corresponds to 'Debian-wheezy' and Ubuntu14 to 'Debian-Jessie' and Ubuntu16 to 'debian-stretch'.

We should consider upgrading a few of our workstations to Ubuntu 14 LTS to see how painful it is to run our scripts and DTT and DV. Better to upgrade a bit before we are forced to by circumstance.

I followed the instructions from software.ligo.org (https://wiki.ligo.org/DASWG/DebianWheezy) and put the recommended lines into the /etc/apt/sources.list.d/lsc-debian.list file.

but I still got 1 error (previously there were ~7 errors):

W: Failed to fetch http://software.ligo.org/lscsoft/debian/dists/wheezy/Release  Unable to find expected entry 'contrib/binary-i386/Packages' in Release file (Wrong sources.list entry or malformed file)

Restarting now to see if things work. If its OK, we ought to change our squeeze lines into wheezy for all workstations so that our LSC software can be upgraded.

12720   Sat Jan 14 22:39:30 2017 ranaSummarySUSITMY is drifting ?

https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20170114/sus/susdrift/

ITMY is not like the others. Real or just OSEM madness?

12719   Sat Jan 14 12:36:57 2017 ericqUpdateDAQminute trends missing

Yes, writing minute trends causes hourly FB crashes in the current state of things. The "raw" minute trending is turned on, but I think that these are unknown to nds.

12718   Sat Jan 14 12:12:03 2017 ranaUpdateDAQminute trends missing

Did we turn off minute trend writing in one of the recent FrameBuilder debug sessions? Seems we only have second trends in 2016. Maybe this explains why its so slow to get minute trends? Dataviewer has to rebuild it from second trend.

controls@nodus|frames > l total 64 drwx------   2 root     root     16384 Jun  8  2009 lost+found/ drwxr-xr-x   2 controls controls  4096 Jul 14  2015 tmp/ -rw-r--r--   1 controls controls     0 Jul 14  2015 test-file drwxr-xr-x   5 controls controls  4096 Apr  7  2016 trend/ drwxr-xr-x   4 root     root      4096 Apr 11  2016 archive/ drwxr-xr-x 789 controls controls 36864 Jan 13 19:34 full/ controls@nodus|frames > cd trend controls@nodus|trend > l total 3340 drwxr-xr-x 258 controls controls 3342336 Jul  6  2015 minute_raw/ drwxr-xr-x 387 controls controls   36864 Nov  5  2015 minute/ drwxr-xr-x 969 controls controls   36864 Jan 13 19:49 second/

12717   Sat Jan 14 00:53:05 2017 ranaHowToDAQGet 40m data using NDS2 and Python

Minute trend data seems not available using the NDS2 server. Its super slow using dataviewer from the control room.

Did some digging into the NDS2 config on megatron. It hasn't been updated in 2 years.

All of the stuff is run by the user 'nds2mgr'. The CronTab for this user was running all the channel name updates and server restarts at 3 AM each day; I've moved it to 5:05 AM. I don't know the password for this user, so I just did 'sudo su nds2mgr' to become him.

On megatron, in /home/nds2mgr/nds2-megatron/ there is a list of channels and configs. The file for the minute trend (C-M-ChanList.txt), hasn't been updated since Nov-2015. ???

12716   Fri Jan 13 23:39:46 2017 gautamUpdateGeneralETMX suspension electronics problems?

[Koji,gautam]

After Koji's leap second fix, we were playing around with the X arm locking. In particular, we were playing around with the limit value on the X arm LSC filter bank - the nominal value is 4000, we wanted to see if we could increase this without kicking the optic while acquiring arm lock. We initially increased it to 8000, and then turned it off altogether. Then we rapidly turned the output of the servo ON/OFF, and looked at the arm transmission to see if it came back to the level before unlocking, as an indication of whether the optic was kicked.

These trials suggested a value of 8000 for the limiter was OK, so we left the LSC mode on with the limiter set to 8000. But just as we were about to leave for the night, I noticed on the wall Striptool that the X arm was unlocked. Investigating, we found that the green wasn't even locking to a HOM. Further investigation of the Oplev spot showed that ETMX had received a large kick (both pitch and law errors were ~200urad). ITMX was unaffected.

We initially tried lowering the LSC limit value back to 4000, then used first the Oplev spot and then the green to align the arm. But turning on LSC misaligned the arm after acquiring lock. So we decided to leave LSC off, thinking that the notorious ETMX suspension problems have resurfaced. As a diagnostic, we figured we'd leave the watchdog tripped, and use the Oplev to see if the optic was getting kicked. But the act of turning the watchdog off kicked the optic again (WHY?!).

Looking at the ETMX sus screen, turning off all the damping and LSC (but watchdog on) still leaves a non-zero offset in the "Vmon" field, between 0.02-0.05V depending on the coil. Turning the watchdog OFF takes all these to 0.009V, although I can see the LR value fluctuating between 0.004V and 0.009V. I went to the Xend and squished all the cables on the Sat. Box, but the problem persisted.

At this time, I can't think of any explanation, so I am giving up for the night. To avoid unnecessarily kicking the optic, I am going to unplug the suspension from the Sat. Box and leave one of our tester boxes plugged in, lets see if that sheds any light on the situation...

Notes:

1. The +/-20V sorensens at this end were "tripped" for a few days after the power glitch until they were reset and turned back on yesterday. But this should not affect Vmon, as these Sorensens only supply the DC voltage for the coil bias, which is a slow machine channel?
2. The X arm was staying locked and well aligned for hours on end earlier this afternon - in fact it was locked for about 2 hours 6-8 hours ago, I can still see the trace on the wall StripTool....
12715   Fri Jan 13 21:41:23 2017 KojiUpdateCDSDC errors

I think I fixed the DC error issue

1. I added the leap second (leapsecond ?) entry for 2016/12/31, 23:60:00 UTC to daqdrc

[OLD]
set gps_leaps = 820108813 914803214 1119744016;
[NEW]
set gps_leaps = 820108813 914803214 1119744016 1167264018;

2. Restarted FB and all realtime models

Now I don't see any RED light.

12714   Fri Jan 13 21:32:49 2017 ranaHowToDAQGet 40m data using NDS2 and Python

The attached file is a python notebook that you can use to get data. Minimal syntax.

Attachment 1: get40mData.ipynb
{
"cells": [
{
"cell_type": "markdown",
"source": [
"## Get some 40m data using NDS"
]
},
{

... 137 more lines ...
12713   Fri Jan 13 14:33:00 2017 MAX (not Rana)UpdateSummary PagesDecember outage

PEM config file was also lacking a section named "summary", which is necessary for all parent tabs; this has now been solved. I have deactivated the MEDM pages because Praful's screencap script seemed to be broken (I should have logged this, I apologize).

 Quote: Pages still not working: PEM and MEDM blank. Committed existing MEDM grabbing scripts to SVN. Ran the cron job on megatron by hand. It grabs PNG files, but somehow its not getting into the summary pages. Changed the MEDM grabbing scripts to use '/usr/bin/env'. GW summary log files were numbering in the many thousands, so I moved everything over 320 days old into the OLD/ sub-directory using 'find . -type f -mtime +320 -exec mv {} OLD/ \;' (the semi-colon is needed) Did apt-get upgrade on Megatron. pinged Max Stared at GWsumm docs to see if there's a clue about what (if anything) is wrong with the .ini file.

12712   Fri Jan 13 14:18:28 2017 SteveUpdatePEMair condition fixed

The old control room AC  has been stick in heating mode for about 2 months. It's thermostate and fan belt  was finally replaced. It was calibrated and set to 71 F ( just behind 1X6 on west wall ) around 1pm.

at 4 pm Rana cried

It must be too tight.

Attachment 1: PEM_120d.png
12711   Fri Jan 13 10:53:03 2017 SteveUpdatePEMdoors are fixed

Control room to outside door was realigned.

It is self closing now.

Control room to IFO door lock optimized to soft closing.

All other doors lubricated by Alex of the key shop.

12710   Fri Jan 13 08:54:32 2017 JohannesUpdateGeneralDC PD installed

I installed a DC PD (Thorlabs PDA 520) in the beam path to AS55. I placed a 2" 90/10 BS on a flip mount that picks of enough light for the PD to spit out ~8V when the port is bright. Single arm continuous signal will be ~2V. While most of the light still continues towards AS55, the displacement from the BS moves the beam off AS55, so I used the flip mount in case anyone needs to use AS55. The current configuration is UP.

When we're done with loss investigations the flip mount should be removed from the bench.

I hooked the PD up to an ethernet-enabled scope and started scripting the loss map measurement (scope can receive commands via http so we can automate the data acquisition). The scope that was present at the bench and had been used for the MC ringdown measurements had a 'scrambled' screen that I couldn't fix so I had to retrieve another scope ("scope1"). I'll try to find out what's wrong with it but we may have to send it in for repair.

12709   Thu Jan 12 23:22:34 2017 ranaUpdateSummary PagesDecember outage

Pages still not working: PEM and MEDM blank.

• Committed existing MEDM grabbing scripts to SVN. Ran the cron job on megatron by hand. It grabs PNG files, but somehow its not getting into the summary pages.
• Changed the MEDM grabbing scripts to use '/usr/bin/env'.
• GW summary log files were numbering in the many thousands, so I moved everything over 320 days old into the OLD/ sub-directory using 'find . -type f -mtime +320 -exec mv {} OLD/ \;' (the semi-colon is needed)
• Did apt-get upgrade on Megatron.
• pinged Max
• Stared at GWsumm docs to see if there's a clue about what (if anything) is wrong with the .ini file.
12708   Thu Jan 12 17:31:51 2017 gautamUpdateCDSDC errors

The IFO is more or less back to an operational state. Some details:

1. The IMC mirror excess motion alluded to in the previous elog was due to some timing issues on c1sus. The "DAC" and "DK" blocks in the c1x02 diag word were red instead of green. Restarting all the models on c1sus fixed the problem
2. When c1ioo was restarted, all of Koji's changes (digital) to the MC WFS servo where lost as they were not committed to the SDF. Eric suggested that I could just restore them from burt snapshots, which is what I did. I used the c1iooepics.snap file from 12:19PM PST on 26 December 2016, which was a time when the WFS servo was working well as per this elog by Koji. I have also committed all the changes to the SDF. IMC alignment has been stable for the last 4 hours.
3. Johannes aligned and locked the arms today. There was a large DC offset on POX11, which was zeroed out by closing the PSL shutter and running LSC offsets. Both arms lock and stay aligned now.
4. The doubling oven controller at the Y end was switched off. Johannes turned it on.
5. Eric and I started a data consistency check on the RAID array yesterday, it has completed today and indicated no issues
6. NDS2 is now running again on megatron so channel access from outside should(???) be possible again.

One error persists - the "DC" indicator (data concentrator?) on the CDS medm screen for the various models spontaneously go red and return to green often. Is this a known issue with an easy fix?

12707   Thu Jan 12 13:45:58 2017 SteveHowTosafetyclosing a door

It was requested this morning.

 Quote: This is one of those unsolved door lock acquisition problems. Its been happening for years. Please ask facilities to increase the strength of the door tensioner so that it closes with more force.

12706   Thu Jan 12 13:43:02 2017 ranaHowTosafetyclosing a door

This is one of those unsolved door lock acquisition problems. Its been happening for years.

Please ask facilities to increase the strength of the door tensioner so that it closes with more force.

12705   Thu Jan 12 10:14:49 2017 SteveHowTosafetyclosing a door

The door was not locked this morning.

Please do not use this door if you can not close it!

Last person leaving the lab should check that the latch is cut by the strike plate.

Attachment 1: odc.jpg
12704   Thu Jan 12 02:45:53 2017 JohannesUpdateGeneralNext armloss steps

As stated in elog 12618, using an oscilloscope to average the reflected powers and thus circumventing all filtering yielded much better results than before:

XARM: 21 +/- 35 ppm
YARM: 69 +/- 45 ppm

We can probably decrease the measurement uncertainty further by using a larger photodiode that is more suited for DC measurements. It will be placed in the AS pathtemporarily. If we get below 10 ppm systematic errors will begin to matter. To get those under control I will have to re-determine the visibility in the arm cavities and the modulation indices. The numbers to match from an estimate via the power recycing gain are <= 50 ppm arm average from elog 12586. Once the measurement scheme is up and running, we can proceed to generate ETM lossmaps. ITM will still be tricky but let's see what we can do.

Following Yutaro's approach, we can move the beams on the optcs in a deterministic way by several mm on the ETMs. Moving the beam is achieved by introducing offsets into the ASS auto alignment. As an example, the Yaw dither for ETMY is shown:

Each of the 8 test mass rotational degrees of freedom is driven by a particular frequency, and 2 signals are digitally demodulated in the real-time system: The arm transmission ("T") and the LSC arm length feedback signal to the ETM (L). The T signal feeds back to the input pointing, aka Tip Tilts and BS. This maximizes the transmission for a given test mass orientation. The L feedback controls the beam position on the mirrors in the arms. It minimizes the coupling of the dither to the length feedback, which is achieved when the beam goes through the axis of the rotational motion. This is where we introduce the offset:

The signal C1:ASS-YARM_ETM_YAW_L_DEMOD_I_OFFSET (for this example) moves the locking point of the dither-to-length coupling and thus moves the beam around on the ETM. This is true for the PIT and YAW of all test masses except ITMX. In the current configuration the TTs optimize the alignment into the YARM, and for the X we only have the BS, which is why the beam spot on ITMX cannot be independently controlled as-is. We could, however, for the sake of this measurement, temporarily temporarily give TT authority to the XARM feedback to control the ITMX beam position. I imagine something like dither-aligning with ASS the normal way, and then run a customized script in which the XARM is treated as the YARM, feecback to the BS is cut, and the YAW signals are inverted due to the reflection on BS.

Knowing the angle of the offset gives us a way to calculate the beam spot displacement with the cavity geometry. For best results I want to make sure our OpLev calibration is still good (laser power decay, although last time this was done was only about a year ago), which would be analogous to elog 11831.

As for ITM beam position, this scheme only works partially, because it would require the beam to steer further off its axis than in the ETM case. This is problematic because of the spacing between tip tilts and ITMs. I summarize:

1. Place larger DCPD in AS path
2. Confirm mode-matching and mod-indices
3. Assess loss in center with zero offsets
4. Uncertainty low enough? If not get better.
5. Calibrate OpLevs
6. Introduce calibrated offsets in dither alignment
7. Wander beam on test masses, recording arm losses
8. ???
9. Profit
Attachment 1: ass_illustration.pdf
12703   Wed Jan 11 19:20:23 2017 Max IsiUpdateSummary PagesDecember outage

The summary pages were not successfully generated for a long period of time at the end of 2016 due to syntax errors in the PEM and Weather configuration files.

These errors caused the INI parser to crash and brought down the whole gwsumm system. It seems that changes in the configuration of the Condor daemon at the CIT clusters may have made our infrastructure less robust against these kinds of problems (which would explain why there wasn't a better error message/alert), but this requires further investigation.

In any case, the solution was as simple as correcting the typos in the config side (on the nodus side) and restarting the cron jobs (on the cluster side, by doing condor_rm 40m && condor_submit DetectorChar/condor/gw_daily_summary.sub). Producing pages for the missing days will take some time (how to do so for a particular day is explained in the wiki https://wiki-40m.ligo.caltech.edu/DailySummaryHelp).

RXA: later, Max sent us this secret note:

However, I realize it might not be clear from the page which are the key steps. These are just running:

1) ./DetectorChar/bin/gw_daily_summary --day YYYYMMDD --file-tag some_custom_tag To create pages for day YYYYMMDD (the file-tag option is not strictly necessary but will prevent conflict with other instances of the code running simultaneously).

2) sync those days back to nodus by doing, eg: ./DetectorChar/bin/pushnodus 20160701 20160702

This must all be done from the cluster using the 40m shared account.
12702   Wed Jan 11 16:35:03 2017 gautamUpdateCDSpower glitch - recovery progress

[lydia, ericq, gautam]

We set about following the instructions linked in the previous elog. A few notes/remarks:

1. It is important to run the ntpdate commands before restarting the models. Sometimes, multiple restarts of the models were required to turn all the indicator blocks on the MEDM screen green.
2. There was also an issue of multiple ntpd processes running on the same machine, which obviously caused all sorts of timing havoc. EricQ helped us diagnose and fix these. At the moment, all the lights are green on the CDS status MEDM screen
3. On the hardware side, apart from the usual suspects of frontends/megatron/optimus/fb needing to be rebooted, I noticed that the ETMX OSEM lights were off on the control room monitors. Investigation pointed to the 2 20V sorensens at the X end outputting 0V, 0A after the power glitch. We turned down both dials, and then gradually ramped them up again. Both Sorensens now read +/-20V, 0.3A, which is in agreement with the label stuck onto them.
4. Restarted MC autolocker and FSS Slow scripts on megatron. I have not yet looked at the status of the nds2 server on megatron.
5. 11 MHz Marconi has yet to be restarted - but I am unable to get even the IMC locked at the moment. For some reason, the RMS of the MC1 and MC3 coils are way higher than what I am used to seeing (~5mV rms as compared to the <1mV rms I am used to seeing for a damped optic). I will investigate further. Leaving MC autolocker disabled for now.
12701   Tue Jan 10 22:55:43 2017 gautamUpdateCDSpower glitch - recovery steps

Here is a link to an elog with the steps I had to follow the last time there was a similar power glitch.

The RAID array restart was also done not too long ago, we should also do a data consistency check as detailed here, if not already..

If someone hasn't found the time to do this, I can take care of it tomorrow afternoon after I am back.

Quote:

Does "done" mean they are OK or they are somehow damaged? Do you mean the workstations or the front end machines?

 The computers are all done.

megatron and optimus are not responding to ping commands or ssh -- please power them up if they are off; we need them to get data remotely

12700   Tue Jan 10 21:47:00 2017 ranaUpdateCDSpower glitch

Does "done" mean they are OK or they are somehow damaged? Do you mean the workstations or the front end machines?

 The computers are all done.

megatron and optimus are not responding to ping commands or ssh -- please power them up if they are off; we need them to get data remotely

12699   Tue Jan 10 16:20:11 2017 SteveUpdateCDSpower glitch......Raid is rebuilding

Jamie started the fm40m Raid rebuilding. It has been beeping since the power outage.

Summary pages have no reading since power glitch.

Attachment 1: rebuilding_in_progress.png
12698   Tue Jan 10 14:24:09 2017 SteveUpdateVACRGA scan at day 82

Valve configuration: vacuum normal

Vacuum envelope: 23C

Attachment 1: pd80VNd82.png
12697   Mon Jan 9 16:12:30 2017 SteveUpdateGeneralOptical Layout in DCC

Caltech Facilities promissed to email the 40m facility drawings in Cad format.

I organized the old of optical , vacuum and facility layout drawings on paper in the old cabinet.

 Quote: Manasa pointed me to the CAD drawings in the 40m SVN and I've now uploaded them to the 40m DCC Tree so that EricG and SteveV can convert them into SolidWorks.

Attachment 1: drawings_on_paper.jpg
12696   Mon Jan 9 09:18:47 2017 SteveUpdatePEMpower glitch

There was a power glitch last night around 1:15am

The vacuum was not effected.

PSL laser turned on, PMC locked, PSL shutter opened and MC locked.

IR lasers at the ends turned on.

East arm air cond turned on.

The computers are all done.

The last power glitch was at Nov 3, 2016

Attachment 1: MondayMorning.png
12695   Sun Jan 8 12:47:06 2017 ranaUpdateGeneralOptical Layout in DCC

Manasa pointed me to the CAD drawings in the 40m SVN and I've now uploaded them to the 40m DCC Tree so that EricG and SteveV can convert them into SolidWorks.

12694   Fri Jan 6 17:00:26 2017 ranaFrogsTreasureVideo of Lab Tour

In this video: https://youtu.be/iphcyNWFD10, the comments focus on the orange crocs, my wrinkled shirt, and the first aid kit.

12693   Thu Jan 5 21:43:16 2017 ranaUpdateDetCharsummary pages dead again

Max tells us that soem conf files were bad and that he did something and now some pages are being made. But the PEM and MEDM pages are bank. Also the ASC tab looks bogus to me.

12692   Fri Dec 30 10:27:46 2016 ranaUpdateDetCharsummary pages dead again

Dead again. No outputs for the past month. We really need a cron job to check this out rather than wait for someone to look at the web page.

12691   Thu Dec 29 21:48:32 2016 ranaUpdateIOOMC AutoLocker hung because c1iool0 asleep again

MC unlocked, Autolocker waiting for c1iool0 EPICS channels to respond. c1iool0 was responding to ping, but not to telnet. Keyed the crate and its coming back now.

There's many mentions of c1iool0 in the recent past, so it seems like its demise must be imminent. Good thing we have an Acromag team on top of things!

Also, the beam on WFS2 is too high and the autolocker is tickling the Input switch on the servo board too much: this is redundant / conflicting with the MC2 tickler.

12690   Thu Dec 29 21:35:30 2016 ranaSummaryIOOIMC WFS tuning

The WFS gains are supposedly maximized already. If we remotely try to increase the gain, the two MAX4106 chips in the RF path will oscillate with each other.

We should insert a bi-directional coupler (if we can find some LEMO to SMA converters) and find out how much actual RF is getting into the demod board.

Attachment 1: Screen_Shot_2017-01-03_at_5.55.13_PM.png
12689   Thu Dec 29 16:52:51 2016 KojiSummaryIOOIMC WFS tuning

Koji responding to Rana

> For the rough calibration below 10 Hz, we can use the SUS OSEM cal: the SUSPIT and SUSYAW error signals are in units of micro-radians.

I can believe the calibration for the individual OSEMs. But the input matrix looked pretty random, and I was not sure how it was normalized.
If we accept errors by a factor of 2~3, I can just naively believe the calibration factors.

> If the RF signals at the demod input are low enough, we can consider either increasing the light power on the WFS or increasing the IMC mod. depth.

The demod chip has the conversion factor of about the unity. We increased the gains of the AF stages in the demod and whitening boards. However, we only have the RMS of 1~20 counts. This means that we have really small RF signals. We should check what's happening at the RF outputs of the WFS units. Do we have any attenuators in the RF chain? Can we skip them without making the WFS units unstable?

12688   Thu Dec 29 13:22:21 2016 ranaSummaryIOOIMC WFS tuning
• For the rough calibration below 10 Hz, we can use the SUS OSEM cal: the SUSPIT and SUSYAW error signals are in units of micro-radians.
• It seems from the noise plots that the demod board is now dominating over the whitening board noise.
• If the RF signals at the demod input are low enough, we can consider either increasing the light power on the WFS or increasing the IMC mod. depth.
• We should look at the out-of-lock light power on the WFS and re-examine what the 'safe' level is. We used to do this based on the dissipated electrical power (bias voltage x photocurrent).

At Hanford, there is this issue with laser jitter turning into an IMC error point noise injection. I wonder if we can try out taking the acoustic band WFS signal and adding it to the MC error point as a digital FF. We could then look at the single arm error signal to see if this makes any improvement. There might be too much digital delay in the WFS signals if the clock rate in the model is too low.

12687   Thu Dec 29 10:24:56 2016 SteveUpdatePEMEQ5.7mHawthorn NV

Sus damping restored.

Attachment 1: eq5.7HawthorneNV.png
12686   Mon Dec 26 12:45:31 2016 KojiSummaryIOOIMC WFS tuning

It didn't go crazy at least for the past 24hours.

Attachment 1: IMC_REFL_TRANS_26hrs.png
Attachment 2: IMC_TRANS_P_Y_26hrs.png
12685   Sun Dec 25 14:39:59 2016 KojiSummaryIOOIMC WFS tuning

Now, the output matrices in the previous entry were implemented.
The WFS servo loops have been engaged for several hours.
So far the REFL and TRANS look straight. Let's see how it goes.

12684   Fri Dec 23 21:05:56 2016 KojiSummaryIOOIMC WFS tuning

Signal transfer function measurements

C1:SUS-MC*_ASCPIT_EXC channels were excited for swept sine measurements.

The TFs to WFS1-I1~4, Q1~4, WFS1/2_PIT/YAW, MC2TRANS_PIT/YAW signals were recorded.

The MC1 and MC3 actuation seems to have ~30Hz elliptic LPF somewhere in the electronics chain.
This effect was compensated by subtracting the approximated time delay of 0.022sec.

The TFs were devided by freq^2 to make the response flat and averaged between 7Hz to 15Hz.
The results have been summarized in Attachment 3&4.

Attachment 4 has the signal sensing matrix. Note that this matrix was measured with the input gain of 0.1.

Input matrix for diagonalizing the actuation/sensor response

Pitch

$\begin{pmatrix} -1.58983 & -0.901533 & -5592.53 \\ 0.961632 & -0.569662 & 1715.12 \\ 0.424609 & 1.60783 & -5157.38 \end{pmatrix}$

e.g. To produce pure WFS1P reaction, => -1.59 MC1P + 0.962 MC2P + 0.425 MC3P

Yaw

$\begin{pmatrix} 1.461 & -0.895191 & -4647.9 \\ 0.0797164 & 0.0127339 & -1684.11 \\ 0.223054 & -1.31518 & -4101.14 \end{pmatrix}$

Attachment 1: IMC_WFS_segment_TF.pdf
Attachment 2: IMC_WFS_channels_TF.pdf
Attachment 3: IMC_WFS_161221_table1.pdf
Attachment 4: IMC_WFS_161221_table2.pdf
Attachment 5: IMC_WFS_161221.xlsx.zip
12683   Fri Dec 23 20:53:44 2016 KojiSummaryIOOIMC WFS tuning

WFS1 / WFS2 demod phases and WFS signal matrix

Attachment 1: DSC_0144.JPG
Attachment 2: DSC_0145.JPG
12682   Thu Dec 22 18:39:09 2016 KojiSummaryIOOIMC WFS tuning

Noise analysis of the WFS error signals.

Attachment 1: All error signals compared with the noise contribution measured with the RF inputs or the whitening inputs terminated.

Attachment 2: Same plot for all the 16 channels. The first plot (WFS1 I1) shows the comparison of the current noise contributions and the original noise level measured with the RF terminated with the gain adjusted along with the circuit modification for the fair comparison. This plot is telling us that the electronics noise was really close to the error signal.

I wonder if we have the calibration of the IMC suspensions somewhere so that I can convert these plots in to rad/sqrtHz...?

Attachment 1: WFS_error_noise.pdf
Attachment 2: WFS_error_noise_chans.pdf
12681   Thu Dec 22 09:37:20 2016 SteveUpdateVACRGA scan at day 63

Valve configuration: vacuum normal

Vac envelope temp: 23 C

Attachment 1: pd80-d63.png
Attachment 2: pd80-580Hz-d63.png
12680   Wed Dec 21 21:03:06 2016 KojiSummaryIOOIMC WFS tuning

- Updated the circuit diagrams:

IMC WFS Demodulator Board, Rev. 40m https://dcc.ligo.org/LIGO-D1600503

IMC WFS Whitening Board, Rev. 40m https://dcc.ligo.org/LIGO-D1600504

- Measured the noise levels of the whitening board, demodboard, and nominal free running WFS signals.

- IMC WFS demod phases for 8ch adjusted

Injected an IMC PDH error point offset (@1kHz, 10mV, 10dB gain) and adjusted the phase to have no signal in the Q phase signals.

- The WFS2 PITCH/YAW matrix was fixed

It was found that the WFS heads were rotated by 45 deg (->OK) in CW and CCW for WFS1 and 2, respectively (oh!), while the input matrices were identical! This made the pitch and yaw swapped for WFS2. (See attachment)

- Measured the TFs MC1/2/3 P/Y actuation to the error signals

Attachment 1: DSC_0142.JPG
12679   Mon Dec 19 22:05:09 2016 KojiSummaryIOOPMC, IMC aligned. The ringdown PD/Lens removed.

PMC and IMC were aligned on Friday (16th) and Today (19th).

The PD and lens for the ringdown experiment were removed as they were blocking the WFS.

12678   Thu Dec 15 03:46:19 2016 ranaUpdateIOOIMC WFS whitening filter investigation

https://dcc.ligo.org/LIGO-D1400414

As it turns out, its not so old as I thought. Jenne and I reworked these in 2014-2015. The QPD whitening is the same as the IMC WFS whitening so we can just repeat those fixes here for the IMC.

 Quote: Rana pointed out that this modification (removal of 900Ohm) leave the input impedance as low as 100Ohm. As OP284 can drive up to 10mA, the input can span only +/-1V with some nonlinearity. Rather than reinstalling the 900Ohms, Rana will investigate the old-days fix for the whitening filter that may involve the removal of AD602s. Until the solution is supplied, the IMC WFS project is suspended.

12677   Wed Dec 14 19:16:57 2016 LydiaUpdateCDSAcromag Binary I/O testing

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
12676   Tue Dec 13 17:26:42 2016 KojiUpdateIOOIMC WFS whitening filter investigation

Rana pointed out that this modification (removal of 900Ohm) leave the input impedance as low as 100Ohm.
As OP284 can drive up to 10mA, the input can span only +/-1V with some nonlinearity.

Rather than reinstalling the 900Ohms, Rana will investigate the old-days fix for the whitening filter that may involve the removal of AD602s.
Until the solution is supplied, the IMC WFS project is suspended.

12675   Thu Dec 8 19:01:21 2016 ranaUpdateIMCPartial IMC ringdowns

Mach Zucker on howto do Ringdowns:  https://dcc.ligo.org/LIGO-T900007

12674   Thu Dec 8 10:13:43 2016 SteveUpdateLSCglitching ITMY_UL has a history

Attachment 1: glitching__ITMY-UL_2007.png
12673   Thu Dec 8 07:56:05 2016 SteveUpdatePEMEQ6.5m Northen CA

No damage. ITMY is glitching, so it has not been damped.

Attachment 1: eq6.5FerndaleCA.png
Attachment 2: 16d_glitching-_trend.png
Attachment 3: EQ6.5_&4.7mFerndaleCa.png
ELOG V3.1.3-