40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 285 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  3852   Wed Nov 3 09:32:00 2010 ranaSummaryCDSEurocard board swapping

When swapping Eurocard boards, it is safest to first turn down the power supplies and then do the swapping.

Otherwise, it is sometimes the case that people plug in the board slowly and/or asymmetrically. This can cause the opamp to see one of the power supply rails without the other (e.g. +15 but not -15).

This can destroy some opamps. The true danger is that there may be damage to the board which you do not notice for several months, thereby leaving a timebomb for the next person.

Don't be an electronics terrorist!

  3856   Wed Nov 3 19:14:00 2010 ranaUpdatePSLPMC mode matching update

I moved the lens just before the PMC to check the mode matching landscape. The PMC trans went up from ~6.5 to ~6.8. That's 5% with ~1 hour of work.

As per the micrometer, this took ~7-8 mm of travel. Since there's so much power left in the HOMs, we we we will have to do a proper mode scan and re-calculate the solution.

The measured transmission is now ~610 mW. The power reflected from the PMC with it unlocked is ~1400 mW.

  3858   Wed Nov 3 23:58:45 2010 ranaUpdateElectronicsCougars

I looked at this web page: http://www.teledyne-cougar.com/Index.asp for the RF company that Rich has recently started using.

There are ~15 amplifiers that they sell which have a NF < 2 dB and work in the 10-100 MHz band. We should call them to find out if they will package some amps for us or at least sell us a few with eval. boards so that we can make our own.

  3872   Fri Nov 5 21:49:12 2010 ranaSummaryCDS40m computer slow down solved

Quote:

Problem:

The 40m computers were responding sluggishly yesterday, to the point of being unusable.

Cause:

The mx_stream code running on c1iscex (the X end suspension control computer) went crazy for some reason.  It was constantly writing to a log file in /cvs/cds/rtcds/caltech/c1/target/fb/192.168.113.80.log.  In the past 24 hours this file had grown to approximatel

The moral of the story is, PUT THINGS IN THE ELOG. This wild process is one of those things where people say 'this won't effect anything', but in fact it wastes several hours of time.

  3873   Fri Nov 5 23:05:43 2010 ranaConfigurationIOOioo.db file changed in c1iool0 to get back MC TRANS

 

We like to have the MC TRANS channels so that we can run all of our old scripts and trends on it. This is the usual BROWN

channel that's on the LockMC screen. Its also the thing that we use for thresholding to activate the MC Autolocker Daemon.

I modified the ioo.db file in the target/c1iool0/ directory so that the MC_TRANS_SUM, _P, and _Y channels are all now just

CALC records of the MC2 OL channels (where the calculation is MC_TRANS_SUM = MC2 OL_SUM + 0.001, etc.). I then

rebooted c1iool0 a few times to get the syntax right. It SEEMS to be working now. I'm sure that this won't effect anything.
I've committed the new file to the SVN repo. Once Suresh is done hacking the QPD circuit, we can set the threshold in the Autolocker.

  3877   Sat Nov 6 16:13:14 2010 ranaSummaryCDS40m computer slow down solved

As part of the effort to debug what was happening with the slow computers, I disabled the auto MEDM snapshots process that Yoichi/Kakeru setup some long time ago:

https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

We have to re-activate it now that the MEDM screen locations have been changed. To do this, we have to modify the crontab on nodus and also the scripts that the cron is calling. I would prefer to run this cron on some linux machine since nodus starts to crawl whenever we run ImageMagick stuff.

Also, we should remember to start moving the old target/ directories into the new area. All of the slow VME controls are still not in opt/rtcds/.

  3914   Sun Nov 14 02:59:31 2010 ranaConfigurationGeneralMEDM snapshots web page

Since Nodus is a Solaris machine it can barely handle doing the ImageMagick commands (such as convert and import). I removed the auto MEDM snapshot routine from it

awhile ago and I think the rate of ELOGD crashes has decreased, although its not definitive.

The snapshots have now been re-actived to run on MAFALDA, after I fixed the absolute pathnames in the scripts and installed (via yum) the packages that mafalda

needed to run this (Xvfb, openmotif, compat, etc.). The snapshots web page is now refreshing by itself and the statScreen/cronjob.sh is running on mafalda 5x per hour.

https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

  3918   Mon Nov 15 04:57:10 2010 ranaUpdateElectronicsSRM side OSEM noise with no magnet

IF I believe this calibration and IF I believe that the noise is the same with no magnet in there, then its almost 1 nm/rHz @ 1 Hz.

I am guessing that Jenne's calculation will show that this is an unacceptably high level of OSEM sensor noise, OAF-wise.

  3935   Tue Nov 16 21:42:31 2010 ranaUpdateCDSScreen Time Fix
I learned today that the following python code will do a find/replace to fix the TIME string on any MEDM screen which has a whited out time field.
Previously, this field was sourced from the c1dscepics of c1losepics process. Now we have to get it from the IOO or SUS front ends

Here's the python code:

import re
o = open("output.adl","w")
data = open("test.adl").read()
o.write( re.sub("C0:TIM-PACIFIC_STRING","C1:FEC-34_TIME_STRING",data)  )
o.close()

Where 'output.adl' could be the same name as 'test.adl' if you want to
replace the existing file. Also FEC-34 just refers to which FE you're running.
It could, in principle, be any one of them.
 

The next step is to figure out how to apply this to all the files in a directory.

  3939   Wed Nov 17 15:49:53 2010 ranaUpdateDAQOle Channel Names

The following channels should be named as below to keep in line with their names pre-upgrade rather than use _DAQ in the name.

C1:SUS-{OPT}_{POS,PIT,YAW}

SUS{POS,PIT,YAW}_IN1
C1:SUS-{OPT}_OPLEV_{P,Y}ERROR

OL{PIT,YAW}_IN1

C1:SUS-{OPT}_SENSOR_{UL,UR,LL,LR,SIDE}
{UL,UR,LL,LR,SD}SEN_OUT
C1:SUS-{OPT}_OPLEV_{P,Y}OUT
OL{PIT,YAW}_OUT
C1:IOO-MC_TRANSPD
MC2_OLSUM_IN1

 

  3951   Thu Nov 18 23:45:18 2010 ranaConfigurationPSLPMC Refl Cam

Valera and Haixing and I installed a PMC REFL camera today. We stole the camera control box from the MC2 trans area (because I don't know why we need a camera there).

We installed it such that it is looking at the leak through of the last turning mirror before the PMC REFL RFPD. This beam was previously going into a Thorlabs razor blade dump.

There is no steering mirror to align into this camera; we just positioned the camera such that the REFL beam fills up the monitor. WE cable tied the cable to the table and the

output of the camera control box is piped into the control room correctly as PMCR. The "IMCR" quadrant is actually the PMCT beam. JoonHo is going to fix this promptly.

Also, I noticed how beautiful  the MC2 Simulink diagram is so I post it here for your viewing pleasure. We should take this as a reference and not produce any new diagrams which are less useful or beautiful or easy to understand.

Attachment 1: mc2_simulink.png
mc2_simulink.png
  3983   Tue Nov 23 23:52:49 2010 ranaUpdateCDSUpdated apps

Wow. I typed DTT on rossa and it actually worked! No complaints about testpoints, etc. I was also able to use its new 'NDS2' function to get data off of the CIT cluster (L1:DARM_ERR from February). You have to use the kinit/kdestroy stuff to use NDS2 as usual (look up NDS2 in DASWG if you don't know what I mean).

  4005   Thu Dec 2 00:34:32 2010 ranaHowToLSCHow Does Cavity Locking Work (answered by Nikon)

https://nodus.ligo.caltech.edu:30889/gw.swf

Dr. Koji Arai and Nikon
  4008   Fri Dec 3 14:34:23 2010 ranaUpdateCDSfooling around in the FB rack

This morning (~0100) I started to redo some of the wiring in the rack with the FB in it. This was in an effort to activate the new Megatron (Sun Fire 4600) which we got from Rolf.

Its sitting right above the Frame Builder (FB). The fibers in there are a rats nest. Someone needs to team up with Joe to neaten up the cabling in that rack - its a mini-disaster.

While fooling around in there I most probably disturbed something, leading to the FB troubles today.

  4011   Sun Dec 5 22:28:39 2010 ranaSummaryall down cond.power outage

Looks like there was a power outage. The control room workstations were all off (except for op440m). Rosalba and the projector's computer came back, but rossa and allegra are not lighting up their monitors.

linux1 and nodus and fb all appear to be on and answering their pings.

I'm going to leave it like this for the morning crew. If it

  4051   Tue Dec 14 04:14:53 2010 ranaUpdateElectronicsRF Photodiode Characterizations

This is looking better, but the fit data for the TF should be plotted along with the data. The data should be made up of points and the fit a line.

For the fit, we should have the Q of the main resonance as well as the peak height of the main resonance and the values of the gain at the notch frequencies.

Also the peak as well as the notches should have the frequencies fit for and labeled. In principle, you can make the plot on the wiki have all of the data. Then in the end we can print the plot in a small size and glue it to the PD's backside.

  4069   Fri Dec 17 03:37:47 2010 ranaUpdateSUSITMY / SRM / BS / PRM OPLEVs aligned

Quote:

The sole thing that has been deviated from the optical layout was that the SRM returning beam had to be reroute
as the SRM has better reflectivity on the AR surface in stead of the HR one.

 I suppose that if we were really clever we would intentionally choose either the AR or HR surface so as to minimize the effect of the thermal lensing and/or thermal expansion from the locked interferometer absorption.

  4071   Sat Dec 18 06:24:49 2010 ranaUpdateelogrestarted

The process was taking up 100% of the CPU and not responding via web. The .log file showed the last action was somebody reading/editing one of Jenne's entries from August regarding TT ECD. The restart script didn't work, so I had to do a 'kill -9' to get it to die.

  4074   Sun Dec 19 22:45:28 2010 ranaUpdateelogrestarted

I deleted the yellow box which showed up by default when making an elog entry. Would be nice if we could make it so that you have to click a button to 'opt-in' for the yellow box rather than get it by default.

I added a 'robots.txt' file to the /users/public_html/ area using Google's instructions (it only works with robot compliant crawlers), but am not sure how to put robots.txt into the elog port.

  4081   Tue Dec 21 08:26:08 2010 ranaUpdateelogelogd is getting killed by Suresh

Suresh killed the elogd again from India. This was the log file:

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Referer: http://www.ligo.caltech.edu/~ajw/40m_upgrade.html
Cookie: elmode=threaded; __utma=65601905.411937803.1291369887.1291369887.1291369887.1; __utmz=65601905.1291369887.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); SITESERVER=ID=4981c5fd42ae53c9c9e0980f2072be4f
Via: 1.1 sfire5.du.ac.in:3128 (squid/2.6.STABLE6)
X-Forwarded-For: 10.11.1.120
Cache-Control: max-age=259200
Connection: keep-alive

Stop killing our elog!

  4085   Wed Dec 22 06:50:19 2010 ranaUpdateelogelogd is getting killed by Suresh

After another elog crash, I've blacklisted the domain that Suresh is using by editing the apache httpd.conf. Let's see what happens now.

  4095   Thu Dec 23 18:51:37 2010 ranaUpdateGreen Lockinginstalled doubling oven base at PSL table

This is not such a bad base design, but remember that we have to get a couple of parts with the purple anodize to see if there is a difference between black and purple in terms of the 532 nm reflectivity.

  4098   Wed Dec 29 18:53:11 2010 ranaSummaryelogfound hung - restarted

This was the error today:

GET /40m/ HTTP/1.1
Host: nodus.ligo.caltech.edu:8080
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.ligo.caltech.edu/~ajw/40m_upgrade.html
Cookie: elmode=threaded; __utma=65601905.411937803.1291369887.1291369887.1291369887.1; __utmz=65601905.1291369887.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); SITESERVER=ID=4981c5fd42ae53c9c9e0980f2072be4f

  4099   Fri Dec 31 12:41:02 2010 ranaUpdateGeneralIR flashes

I came in today to check up on the StripTool and burn the Ubuntu LTS (new CDS OS) DVD. I was pretty excited to see the PRM flashes on Mon1.

I waggled the PRM/BS alignments and got a good contrast MICH and then bright flashes in the PRM that totally overload Mon1's CCD.

Now I can see flashes of some IR junk in the X Arm; its way off on the left edge of the mirror, but there's a beam.

For the short term, we can hook up the IO PZTs to some old EPICS channels (like one of the AUX guys in the LSC area), but eventually it has to get hooked up to the new ASC or ASS. We have to bug Joe to see where this shows up in his master diagram.

**Note: if you get lost sometimes when doing the alignments, remember that you can use time_machine_conlog.

Ex:

rossa:general>./time_machine_conlog 2010/12/31,11:00:00 PDT C1:SUS-ITMX_PIT_COMM
Issuing the conlog command:
/cvs/cds/caltech/conlog/bin/conlog +epics -interp at 2010/12/31,11:00:00 PDT "C1:SUS-ITMX_PIT_COMM"


Conlog Replied:

LIGO controls: values at 2010 12/31 11:00:00 pst
 __Epics_Channel_Name______   __value_____
 C1:SUS-ITMX_PIT_COMM         0.406100



Restoring now...

Restoration Successful

Attached is the last 8 days of Vacuum Pressure trend which includes the pumpdown.

Attachment 1: Untitled.png
Untitled.png
  4100   Sat Jan 1 16:36:16 2011 ranaConfigurationSUSrampdown.pl was not running

The crontab for op340m which runs various IFO maintenance activities has been set to the wrong path for the watchdog rampdown script since the CDS changeover.

This is a dangerous situation. With the watchdog thresholds set as high as 1000, the magnets can be broken if the new CDS has some mental problems. This kind of thing happened before at LHO (which is why Stan invented the watchdogs). Please try to make sure that the watchdog thresholds are not set that way - its our only defense against bad CDS.

I've now corrected the crontab. The watchdog thresholds are being stepped down every 30 minutes as before.

However, out test points are gone again, so who knows how things are behaving.

  4101   Sat Jan 1 19:13:40 2011 ranaUpdateCDSc1pem now recording data

 I found that there was no PEM data nor any other data (no SUS or otherwise. No testpoints, no DAQ).

I went through the procedure that Jenne has detailed in the Wiki but it didn't work.

1) Firstly, the 'telnet fb 8088' step doesn't work. It says "Connected to fb.martian" but then just hangs. To replicate the effect of this step I tried ssh'ing to fb and doing a 'pkill daqd'. That works to restart the daqd process.

2) The wiki instructions had a problem. In the GUI step, it should say 'Save' after the Acquire bit has been set to 1. Even so, this works to get the .ini file right and the DTT can see the correct channel list, but none of the channels are available. There are just 'Unable to obtain measurement data'.

3) I tried running 'startc1pem', but no luck. I also tried rebooting c1sus from the command line. That worked so far as to come back up with all the right processes running, but still no data. The actual /frames directory shows that there are frames, but we just can't see the data. I also tried to get data usind the DTT-NDS2 method, but still no luck. (*** ITMX and ITMY both came back with all their filters off; worth checking if their BURTs are working correctly.)

Using DataViewer, however, I AM able to see the data (although the channel name is RED). In fact, I am able to see the trend data ever since I changed the Acquire bit to 1. Plot attached as evidence. Why does DTT not work anymore???

Attachment 1: Untitled.png
Untitled.png
  4109   Wed Jan 5 00:23:30 2011 ranaSummaryDAQFrameBuilder fails in a new way

Since Leo was trying to demo his LIGO Data Listener code, he noticed that there was and NDS2 issue. The NDS2 guy (JZ) noticed that the FrameBuilder had an issue.

We investigated. At 4PM on Dec 31, the GPS timestamp of the frame file names started to be recorded wrong. In fact, it started to give it a file name matching the correct time from 1 year in the past.

So that's our version of the Y2011 bug. Here's the 'ls' of /frames/full:

drwxr-xr-x 2 controls controls 252K Dec 26 03:59 9773
drwxr-xr-x 2 controls controls 260K Dec 27 07:46 9774
drwxr-xr-x 2 controls controls 256K Dec 28 11:33 9775
drwxr-xr-x 2 controls controls 252K Dec 29 15:19 9776
drwxr-xr-x 2 controls controls 244K Dec 30 19:06 9777
drwxr-xr-x 2 controls controls 188K Dec 31 16:00 9778
drwxr-xr-x 2 controls controls 148K Jan  1 08:53 9463
drwxr-xr-x 2 controls controls 260K Jan  2 12:39 9464
drwxr-xr-x 2 controls controls 252K Jan  3 16:26 9465
drwxr-xr-x 2 controls controls 248K Jan  4 20:13 9466
drwxr-xr-x 2 controls controls  36K Jan  5 00:22 9467
controls@fb /frames/full $

The culprit is the directory who's name starts out as 9463 whereas it should be 9779.

 

  4115   Wed Jan 5 22:14:41 2011 ranaSummaryDAQFrameBuilder fails in a new way

Just a proof that the DAQ is working - ran DTT on nodus from 3 hours ago.

Attachment 1: Screen_shot_2011-01-05_at_10.13.21_PM.png
Screen_shot_2011-01-05_at_10.13.21_PM.png
  4117   Wed Jan 5 23:37:12 2011 ranaUpdateCamerasAligned the Xarm, no big deal

Pretty fancy work actually...I wouldn't have guessed that you need to look at the back of the ETM. Does this mean that we can't see the flashes from inside the arm cavity? If so, its a pretty remarkeable statement about the wide angle scatter of the new mirrors. Do we really have 1W going into the MC?

  4126   Sat Jan 8 21:12:12 2011 ranaUpdateCDSMegatron is back

 I started reverting Megatron into a standard Ubuntu workstation after Joe/Osamu's attempt to steal it for their real time mumbo jumbo.

First, I installed a hard drive that was sitting around on top of it. That whole area is still a mess; I'm not surprised that we have so many CDS problems in such a chaotic state. There's another drive sitting around there called 'RT Linux' which I didn't use yet.

Second, I removed the ethernet cables and installed a monitor/keyboard/mouse on it.

Then I popped in the Ubuntu 10.04 LTS DVD, wiped the existing CentOS install and started the standard graphical installation of Ubuntu.

megatron.jpg

Megatron's specs attached: 

Attachment 2: sysinfo.text
  4127   Sat Jan 8 23:18:03 2011 ranaUpdateComputersnetwork table

There's, as usual, a disconnect between the real martian host table and the one displayed on the Wiki. Basically, the point is: DO NOT TRUST THE WIKI, because people who update the actual host table only randomly update the wiki table.

The only thing worth trusting is the file

/var/named/chroot/var/named/martian.zone
on linux 1.

You will need to have 'root' or 'sudo' to get into that directory to read the file.

  4128   Sun Jan 9 15:50:55 2011 ranaHowToPSLSetting the PMC gain

Untitled.png

I ramped the PMC gain slider to find where it oscillates. It starts going bad at ~13 dB, so the new default gain is 7 dB to give us some margin for alignment improvements, etc.


I also fixed the TIME field in our MEDM screens by adding the following text to the C1IFO_STATE.db file which runs on c1iscaux:
grecord(stringin, "C0:TIM-PACIFIC_STRING")
{
    field(DESC, "Current time and date")
    field(DTYP, "EPICS IOC VAR")
    field(SCAN, "1 second")
    field(INP, "C1:FEC-34_TIME_STRING")
}

grecord(stringin, "C0:IFO-TIME_PACIFIC")
{
    field(DESC, "Current time and date")
    field(DTYP, "EPICS IOC VAR")
    field(SCAN, "1 second")
    field(INP, "C1:FEC-34_TIME_STRING")
}

This gets the time info from the c1ioo processor via channel access and gives it these mroe reasonable names. The first record is for backwards compatibility. The second record is a better name and we should use it in the future for all new screens. I had to reboot c1iscaux several times to figure out the right syntax, but its OK now. You have to reopen stale screens to get the field to refresh.

This avoids the previous idea of changing all of the MEDM screens.

  4149   Thu Jan 13 12:56:57 2011 ranaUpdateIOOWFS shenanigans

Actually, I just found out that there are different flavors of 'YAG-444'.

There's a YAG-444AH and also a YAG-444-4AH. I'm not sure which one we have or even which is better. The diode's internal resistance is not listed.

They also say explicitly that he 'YAG Enhancement' is just using thicker Silicon. Since the absorption of 1064 nm light in Silicon is very small, most of the light just goes in and then comes back out without depositing much of the power.

Attachment 1: PerkinElmerQPDs.pdf
PerkinElmerQPDs.pdf PerkinElmerQPDs.pdf
  4160   Fri Jan 14 20:39:20 2011 ranaUpdateCDSUpdated some DAQ channel names

I like this activateDAQ script, but someone (Jenne with Joe's help) still needs to add the PEM channels - we still cannot see any seismic trends.

  4162   Mon Jan 17 04:10:10 2011 ranaConfigurationComputersNTPD restarted on c1dcuepics (to fix the MEDM screen times)

I installed NTPD on Megatron (its Ubuntu, so different from the CentOS workstations). Here's the terminal cap to show that its actually working:

megatron:/etc>sudo /etc/init.d/ntp restart
 * Stopping NTP server ntpd                                              [ OK ]
 * Starting NTP server ntpd                                              [ OK ]
megatron:/etc>/etc/init.d/ntp status
 * NTP server is running
megatron:/etc>ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 nodus.martian   204.123.2.72     2 u    7   64    1    0.217    3.833   0.001
 europium.canoni 193.79.237.14    2 u    6   64    1  155.354    3.241   0.001
megatron:/etc>date
Mon Jan 17 04:07:08 PST 2011

Along the way, I also updated the /etc/inet/ntp.conf file for nodus. It was using the USNO as a NTP server and I've pointed it to the Caltech NTP server as per the IMSS NTP page.

  4164   Mon Jan 17 20:13:38 2011 ranaUpdateElectronicsPOX_11 Optical TF

I used 50 mA to drive the laser diode. The light is split 50/50 between the DUT (Device Under Test) and the New Focus 1611 (1 GHz BW) diode used as the reference.

This measurement is the TF of DUT/(New Focus). The resonances are there, but clearly there's an issue with instability around 200 MHz. The setup is still powered up, so please be careful around the RFPD testing table (don't stomp around yank the cables out of the power supplies).

I looked at the RF Photodiode wiki that Alberto has started - most of the TF features are replicated there. Todo:

* Update the 'schematic' with a real schematic instead of the cartoon.
* Change the circuit to remove the resistor in the RF path.
* Add compensation to avoid the 200 MHz instability.
* Make sure to include opamp current noise in the noise model (it is the dominant noise source but has been left out in the noise estimation plot).
* Make the output into a true 50 Ohms.
Attachment 1: A.TIF
A.TIF
  4180   Thu Jan 20 22:17:12 2011 ranaSummaryLSCFPMI Displacement Noise

I found this old plot in an old elog entry of Osamu's (original link).

It gives us the differential displacement noise of the arms. This was made several months after we discovered how the STACIS made the low frequency noise bad, so I believe it is useful to use this to estimate the displacement noise of the arm cavity today. There are no significant seismic changes. The change of the suspension and the damping electronics may produce some changes around 1 Hz, but these will be dwarfed by the non-stationarity of the seismic noise.

Attachment 1: osamu-1140657006.pdf
osamu-1140657006.pdf
  4185   Fri Jan 21 23:17:54 2011 ranaHowToDAQDAQ Wiki Failure

The DAQ Wiki pages say to use port 8088 for restarting the Frame Builder. I tried this to no avail.

op440m:daq>telnet fb 8088
Trying 192.168.113.202...
Connected to fb.martian.
Escape character is '^]'.
^]
telnet> quit
Connection to fb.martian closed.
op440m:daq>telnet fb 8087
Trying 192.168.113.202...
Connected to fb.martian.
Escape character is '^]'.
daqd> shutdown
OK
Connection to fb.martian closed by foreign host.

Apparently, 8087 is the right port. Various elog entries from Joe and Kiwamu say 8087 or 8088. Not sure what's going on here.

After figuring this out, I activated the C1:GCV-XARM_COARSE_OUT_DAQ and C1:GCV-XARM_FINE_OUT_DAQ and set both of them to be recorded at 2048 Hz. We are loading filters and setting gains into these filter modules such that the OUT signals will be calibrated into Hz (that's why we used the OUT instead of the IN1 as there was last night).

  4186   Fri Jan 21 23:55:25 2011 ranaConfigurationLSCPhase Noise Measurement filter

We've set up a beat note measurement between the VCO driver and the Marconi (see Suresh's elog).

Here's the 'unWhiten' filter for compensating the SR560 TF.

It has poles = 1 mHz, 5 kHz, 5 kHz

and  zeros = 30 mHz, 1 kHz

The gain is set to be ~0.001 in the 1-100 Hz band to compensate the G=1000 of the SR560.

Attachment 1: a.gif
a.gif
  4192   Mon Jan 24 09:33:08 2011 ranaUpdateGreen LockingX arm locked !

Very cool.

But the PLL seems very fishy to me. The ZP-3MH needs 13 dBm to operate correctly. You should change the MODLEVEL input of the VCO so as to make the LO input of the mixer go up to 13 dBm. Then the input from the PD should be ~0 dBm.

Also, the PLL diagram seems to show that you have a 1/f^2 loop: 1/f from the SR560 and 1/f from the Hz->rad conversion ??

  4216   Thu Jan 27 23:21:50 2011 ranaSummaryGreen LockingDigital Frequency Discriminator

That's some pretty fast work! I thought we would be taking up to a week to get that happening. I wonder what's the right way to measure the inherent frequency noise of this thing?

Also, should the comparator part have some hysteresis (ala Schmidt trigger) or is it best to just let it twirl as is? Is it sensitive to DC offsets on the input or is there a high pass filter? What's the correct low pass filter to use here so that we can have a low phase lag feedback to the ETM?

  4226   Sat Jan 29 03:13:44 2011 ranaUpdateWienerFilteringImprovement in H1 Wiener FF prediction by using weights and taps

(Jenne, Rana)

Tonight we noticed that there were significant improvements to be had in the predicted DARM Wiener filtering FF performance by using weighting filters and more taps in the FIR filter.

The plots below tell the story:

The first one shows the improvement in the residual (black & blue) by applying a weighting filter. The weight filter tilts the spectrum up at HF and applies and all real pole BP from 10-20 Hz.

The second plot shows the improvement gotten by using 3000 instead of 2000 taps for the Wiener filter. With the larger number of taps we not only get the big improvement at LF, but also some beefy reduction in the higher frequency stack modes and the LOS roll mode.

I'm not sure why we haven't run across this before; the weighting filter was arrived at today by just iterating by hand on the placement of poles and zeros until the trace looked nice.

Jenne is going to run this new filter on the S5-month that we have been using for stationarity testing.

* Some notes:

** this Wiener stuff is faster, by far, on rossa than either megatron or rosalba or my laptop. More than a factor of 3.

*** there is a bug with Macports/Matlab - if you get fftw3 with Macports, it sets itself as the right version to use. This confuses matlab in some cases.

     if you get the error about libfftw3.dylib, whe trying fft in matlab after installing macports, then you can fix it by setting the Matlab lib/ path with the fftw libraries to be ahead of /opt/local/lib in the LD_LIBRARY_PATH in your .cshrc.

Attachment 1: darmweight.png
darmweight.png
Attachment 2: darm3000.png
darm3000.png
  4252   Fri Feb 4 18:58:19 2011 ranaUpdateComputersTemporarily removed cronjob for rsync.backup

Quote:

I removed the rsync backup from nodus' crontab temporarily so as to not have multiple backup jobs running.  The job I started from yesterday was still running.  Hopefully the backup will finish by Monday.

The line I removed was:

0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup

Actually, this is not true. Joe actually killed the currently running backup and set it to start tomorrow morning at 6AM. Its taking forever since its not an incremental backup but a new one due to the change in the setup.

  4255   Sun Feb 6 02:29:28 2011 ranaUpdateElectronicsAnalog MFD: longer cable

I swapped over to a 3x longer cable (old 65 ft. Pasternak cable from ancient 40m days). The old one was 6m, the new one is 18.2 m. It was already coiled up so I put it into a tupperware box to shield it somewhat from the HVAC wind.

The noise went down nearly proportional to the length (after I recalibrated the DAQ channel for the ~3x higher phase->voltage gain). With this length, the peak-peak mixer range is 5.5 MHz, so still enough to go an FSR here.

mfd18.png

I give credit to the low frequency improvement entirely to Tupperware for their excellent containers. The current noise limit is most likely the SR560.

  4258   Mon Feb 7 21:23:11 2011 ranaConfigurationPSLPSL FSS Temperature Sensor Interface box removed

I noticed that the RMTEMP channel was spiking myteriously when Kiwamu opened the PSL door. We found out that the LEMO connectors would intermittently short to the case and cause ~1 deg steps in the temeprature.

We have removed the case and examined it. Not only were the connections to the box intermittent, there was a cold solder joint inside on an unsecured flying add-on opamp. The whole thing is a giant hack.

PK was the last person to work on this box, but I'm sure that he wouldn't have left it in this state. Must be gremlins.

P2070555-1.JPG

The LEMO connectors on the front are the ones touching. The LT1021 is the badly soldered part.

  4276   Sat Feb 12 23:22:21 2011 ranaUpdateElectronicsREFL11 Photodiode replaced

375 mW is way too much light. We must never put more than 100 mW on any of these diodes. We don't want to blow up more diodes like we did with the WFS. The InGaAs diodes often show an excess dark noise before they finally let go and completely fail. This one may show excess during the shot noise testing.

We should ensure that the beam paths are engineered so that none of these new detectors ever sees such high light levels.

The DC path should be made to let us see a 10V from the differential EPICS readout when there is 100 mA of photocurrent (i.e. an effective 100 Ohms transimpedance):

0.1 A  * 10 V/A * 5 V/V * 2V/V

The last factor of 2 is from the single to differential conversion.

If we really only get 15 mV from 375 mW, then this diode or the circuit is broken.

  4282   Mon Feb 14 01:19:18 2011 ranaUpdateCDSToday's CDS problems

This is just a listing of  CDS problems I still notice today:

  1. MC2-MCL button was left ON due to BURT failure. This, of course, screws up our Green locking investigations because of the unintended feedback. Please fix the BURT/button issue.

  2. The GCV - FB0 status is RED. I guess this means there's something wrong? Its really a bad idea to have a bunch of whited out or falsely red indicators. No one will ever use these or trust these in the future.
  3. MC1/2/3 Lockins are all white. Also, the MODE switches for the dewhitening are all white.
  4. Is the MC SIDE coil dewhitening filter synced with anything? It doesn't seem to switch anything. Maybe the dewhite indicators at the top right of the SUS screens can be made to show the state of the binary output instead of just the digital filter
  5. MC WFS is all still broken. We need a volunteer to take this on - align beams, replace diodes, fix code/screens.
  4292   Mon Feb 14 21:59:35 2011 ranaUpdateCDSUpdated some DAQ channel names

Although Joe and Kiwamu claim that they have inserted the correct DAQ names for the OPLEVs (e.g. PERROR and YERROR) back in Jan. 11, when I look today, I see that these channels are missing!

I want my PERROR/YERRORs back!

 

  4293   Mon Feb 14 23:29:04 2011 ranaSummarySUSETMX Fitlers moved around

All of the SUS used to have only 1 filter module for SIDE. They now have 3 filter modules for SIDE just like the other DOFs.

Today I moved the filters around so that the sensor filters are in SDSEN, the servo filters are in SUSSIDE, and the dewhitening for the coil is in SDCOIL.

I noticed along the way that the bounce/roll mode notches for all of the suspensions are still set for the frequencies of the previous suspensions. Suresh has 'volunteered' to find the new frequencies and make the new bandstop filters by looking up the seminal work on this by Dan Busby / Sam Waldman.

  4304   Tue Feb 15 21:45:08 2011 ranaUpdateIOOThe MC TRANS Story

I forgot to elog that last night I touched up the MC2_TRANS QPD setup. I was perplexed by it always going out of alignment so I investigated.

I found that the fork clamp for the steering mirror for the QPD was not tightened. Shame. The beam diameter was equal to the aperture of the QPD and was clipping. Double shame.

I added a lens and tightened the mounts and centered the beam at ~9 PM yesterday. You can see in the attached trend that the measured power went up by ~10%.

Later, there's a big gap where Valera and Steve change out the PMC. You can see that the MC REFL voltage goes from 4.5 V to 5 V (10% increase in the power delivered to the MC).

There's essentially no change in the total transmission - this indicates that although the PMC transmission is now higher by ~10%, the matching to the IMC has been degraded by an equivalent fraction.

Needs some mode matching work.

Attachment 1: a.png
a.png
ELOG V3.1.3-