Now some pedestals, mirrors and lenses are left on the PSL table, since we are on the middle way to construct a PLL setup which employs two NPROs instead of use of PSL laser.

So Please Don't steal any of them.

 Can I please get the network analyzer back?

[Yaakov, Eric, Jenne, Yuta]

Two of our surfs, Yaakov and Eric, pulled two unused RG-405/SMA cables that had been running from 1X2 to (mysteriously) 1Y2 racks.  They left the 1X2 end where it was and pulled the 1Y2 end and rerouted it to the control room.  We labeled both ends appropriately.

The end at 1X2 is now plugged into a splitter that is combining the RF input monitor outputs for the X and Y beatbox channels, so that we can watch the beat signals with the HP8591 in the control room.

According to the measurement done by Aidan and me, there are two beat-note state.

One gave us a small beat signal and the other gave us a bigger signal by approximately 20 dB.

 A possible reason for this phenomenon is that the end laser is operating at a special temperature that somehow drives the laser with two different modes at the same time.

So that it permits the laser sometimes locked with one of the two modes and sometimes with the other mode.

For the first step we will change the temperature such that the laser can run with a single stable mode.

Then for investigating it we will put a scanning cavity on the X end table to see if it really exhibits a two modes or not.

 Quick post of plots and data; I'll fill in more detail tonight. 

TL;DR: I pulled both green PDH boxes and made LISO models, compared TFs and noise levels. 

Pictures of X and Y boards, respectively

TF comparison to LISO. (Normalized to coincide at 1Hz)

Noise comparison to LISO

To Do:

• Figure out why TFs were made differently. Check PM response curves of PZTs to see if they are fine, or need tweaking.
• Make boosts useful. Both are currently integrators with corners under 10Hz, which is already pretty suppressed. 
• I just noticed that the X board is missing C25, which should be a 1uF cap on the positive power pin of the primary TF stage opamp. This should be inserted. 

All data, EAGLE schematics, LISO source and plots in the attached zip. 

I had noticed in the past, that the digital control signal monitor for the X end would saturate well before the ADC should saturate (C1:ALS-X_SLOW_SERVO_IN1, which is from the "output mon" BNC on the box). It turns out that there is some odd saturation happening inside the box itself.

In this scope trace, the servo input is being driven with a 0.02Vpp, 0.1Hz sine wave, gain knob at 1.0. This is bad. 

Evan and I poked around the board, and discover that for some reason currently unknown to us, the variable gain amplifier (AD8336) can't reach its negative rail, despite the +-12V arriving safely at its power supply pins. 

I also realized that the LF356 in the integrator stage in this box had been replaced with a LT1792 by Kiwamu in ELOG 4373. I've updated my schematic, and will upload both boxes' schematics to the DCC page Jenne created for them. (D1400293 and D1400294)

 I've been having trouble locking the X - green for the past few hours. Has there been some configuration change down there that anyone knows about?

I'm thinking that perhaps I need to replace the SHG crystal or perhaps remove the PZT alignment mirrors perhaps. Another possibility is that the NPRO down there is going bad. I'll start swapping the Y-end NPRO for the X-end one and see if that makes things better.

I had pulled out both X and Y servo boxes for inspection, put the Y box back, soldered in a missing op amp power capacitor on the X end box, and had not yet put back the X end box yet because of the saturation issue I was looking into. Otherwise nothing was changed at the ends; I didn't open the tables at all, or touch laser/SHG settings, just unplugged the servo boxes. 

I narrowed down the saturation point in the X green PDH box to the preamp inside the AD8336, but there is still no clear answer as to why it's happening. 

As per Jenne's request, I put the X end PDH box back for tonight's work. It locks, but we have an artificially low actuation range. With SR785, I confirmed a PDH UGF around 5k. Higher than that, and I couldn't reliably measure the UGF due to SR560 saturations. The analyzer is not currently in the loop. 

Both arms lock to green, but I haven't looked at beatnotes today. 

What monitor point is being plotted here? Or is it a scope probe output?

If this saturation is in the uPDH-X but not in the uPDH-Y, then just replace the VGA chip. Because these things have fixed attenuation inside, they often can't go the rails even when the chip is new.

In any case, we need to make a fix to get this box on the air in a fixed state before tomorrow evening.

The traces were from the front panel output BNCs, but the VGA preamp exhibited this asymmetric saturation at its output.  

In any case, I tried to replace the Xend box's AD8336 with a new one, and in doing so, did some irreparable damage to the traces on the board  I was not able to get a new AD8336 into the board. There are some ATF ELOGs where Zach found the AD8336 noise to be bad at low frequencies (link), and its form factor is totally unsuitable for any design that may involve hand modification, since it doesn't even have legs, just tiny little pads. I suggest we never use it for anything in the future. 

Instead, I've hacked on a little daughter board with an OP27 as an inverting op-amp with the gain resistor on the front panel as its feedback resistor, which can swing from 0 to x20 gain (the old gain setting was around 15dB=~x6). I've checked out the TF and output noise, and they look ok. The board can output both rails as well. 

I don't really like this as a long term solution, but I didn't want to leave things in a totally broken state when I left for dinner. 

I installed awgstream-2.16.14 in /ligo/apps/ubuntu12.  As with all the ubuntu12 "packages", you need to source the ubuntu12 ligoapps environment script:

controls@pianosa|~ > . /ligo/apps/ubuntu12/ligoapps-user-env.sh
controls@pianosa|~ > which awgstream
/ligo/apps/ubuntu12/awgstream-2.16.14/bin/awgstream
controls@pianosa|~ > 

I tested it on the SRM LSC filter bank.  In one terminal I opened the following camonitor on C1:SUS-SRM_LSC_OUTMON.  In another terminal I ran the following:

controls@pianosa|~ > seq 0 .1 16384  | awgstream C1:SUS-SRM_LSC_EXC 16384 -
Channel = C1:SUS-SRM_LSC_EXC
File    = -
Scale   =          1.000000
Start   = 1092790384.000000
controls@pianosa|~ > 

The camonitor output was:

controls@pianosa|~ > camonitor C1:SUS-SRM_LSC_OUTMON
C1:SUS-SRM_LSC_OUTMON          2014-08-22 17:44:50.997418 0  
C1:SUS-SRM_LSC_OUTMON          2014-08-22 17:52:49.155525 218.8  
C1:SUS-SRM_LSC_OUTMON          2014-08-22 17:52:49.393404 628.4  
C1:SUS-SRM_LSC_OUTMON          2014-08-22 17:52:49.629822 935.6  
...
C1:SUS-SRM_LSC_OUTMON          2014-08-22 17:52:58.210810 15066.8  
C1:SUS-SRM_LSC_OUTMON          2014-08-22 17:52:58.489501 15476.4  
C1:SUS-SRM_LSC_OUTMON          2014-08-22 17:52:58.747095 15886  
C1:SUS-SRM_LSC_OUTMON          2014-08-22 17:52:59.011415 0 

In other words, it seems to work.

Rana wanted the latest GDS installed (for newest DTT), so I made an ubuntu 12 install directory into which I installed

• gds-2.16.3.2
• root_v5.34.03

I installed this stuff in

/ligo/apps/ubuntu12

which is the "official" location for stuff compiled specifically for ubuntu12.

Given that the workstations are diverging in OS (some ubuntu10, some ubuntu12), we're going to have to start supporting different software packages for the different versions, thus the new ubuntu12 directory.  This will be a pain in the butt, and will certainly lead to different versions of things for different machines, different features, etc.  We should really try to keep things at the same OS.

In any event, if you want to enable the GDS on an ubuntu 12 machine, source the ubuntu12 ligoapps-user-env.sh file:

controls@ottavia|~ > . /ligo/apps/ubuntu12/ligoapps-user-env.sh

Last week Rana and I struggled to figure out how to un-full-screen windows on the Ubuntu workstations that appeared to be stuck in some sort of full screen mode such that the "Titlebar" was not on the screen.  Nothing seemed to work.  We were in despair.

Well, there is now hope: it appears that this really is a "fullscreen" mode that can be activated by hitting F11.  It can therefore easily be undone by hitting F11 again.

Today I tried some things, but basically, lowering the input gain by 10 made the thing stable. In the attached screenshotstrip, you can see what happens with the gain at 1. After a few cycles of oscillation, I turned the gain back to 0.1.

There still is an uncontrolled DoF, but I that's just the way it is since we only have one mirror (the BS) to steer into the x arm once the yarm pointing is fixed.

Along the way, I also changed the phase for POX, just in case that was an issue. I changed it from +86 to +101 deg. The attached spectra shows how that lowered the POX_Q noise.

I also changed the frequencies for ETM_P/Y dither from ~14/18 Hz to 11.31/14.13 Hz. This seemed to make no difference, but since the TR and PO signals were quieter there I left it like that.

This is probably OK for now and we can tune up the matrix by measuring some sensing matrix stuff again later.

Thank you both.

I have updated the .snap file, so that it'll use these parameters, as Rana left them.  Also, so that the "unfreeze" script works without changes (since it wants to make the overall gain 1), I have changed the Xarm input matrix elements from 1 to 0.1, for all of them.  This should be equivalent to the overall gain being 0.1.

 I'm working on similar shelf at ETMY.  Precondition: NPRO in bypass mode, heater for doubling in bypass........since power outage?  Optical level servo turned off.......

U-channel based shelf in place.  Oplev servo is back on at 11:15am    The table may moved.  The oplev return is missing the quad by a few milimeter.

I added an U channel based bottom shelf at the south end today.

We were stymied early in the evening by a surreptitiously placed, verbo-visually obfuscated command in the drstep script. 

IFO pressure 2 Torr,    PSL  shutter closed.  I'm pumping down with 2 roughing pumps with ion pump gate valves open and annulosses at atm.

The vacuum envelope was vented to 17 Torr while I was replacing the USP battery stack. More about this later.....

Do not plan on using the interferrometer tonight.  I will complete the pumpdown tomorrow morning.

Pumpdown stopped for over night  at ~  1 Torr

The roughing line disconnected.  Valves condition indicator  "moving " means that it is closed and it's cable disconnected so it can not move.

The RGA is off and VM1 is stuck.

pd80b has reached Vac Normal. IFO pressure 0.5 mTorr

We need our vauum channels back in dataviewer.

Jamie reported that:

The logs (/var/log/daemon.log) on fb1 are filling with this line:

Jan 03 14:11:51 fb1 dhcpd[1152]: DHCPDISCOVER from 3c:ec:ef:c8:44:78 via enp3s0: network 10.0.113.0/24: no free leases

It seems that some machine on the network is trying to get an IP address but can't

• The MAC address 3c:ec:ef:xx:xx:xx indicates this is one of the supermicro units.
• The IP address indicates this is on the DAQ network which fb1 is spanning.
• There is a switch for this DAQ network. 
• There are 8 machines connected to the switch. fb1 is via optical, and the other 7 have yellow ethernet cables (Attachment 1).
• fb1 and other 6 RT machines already have 10.0.113.x assigned.
• The rest is c1shimmer. I can't ssh into it from martian. KVM on rack 1X7 shows a black screen assuming 1-7 is c1shimmer. I wonder what's the status of this machine, but left untouched so far.

The dhcpd error on the log file stopped when the yellow (DAQ) ethernet cable was removed. With Chris's permission I left it unconnected (Attachment 1).

Chris pinted that the IPMI on c1shimmer is supposed to be exposed to 192.168.113. net rather than DAQ net.

From dhcpd.conf on chiara:

host c1shimmer-ipmi {
  hardware ethernet 3c:ec:ef:c8:44:78;
  fixed-address 192.168.113.37;
}

So the ethernet connections of c1shimmer is still questionable. The next person to work with c1shimmer needs to check them.

This would also be related?
https://lanforge.wordpress.com/2015/11/10/turning-off-ipmi-dhcp/

fb has been loading a 'symmetricom' kernel module, presumably because it was once being used to help with timing.  It's no longer needed, so I unloaded it and commented out the lines that loaded it in /etc/conf.d/local.start.

It seems that the MC3 problem is intermittent (one-day trend attached).  I tried to take advantage of a "clean MC3" night, but the watch script would usually fail at the transition to DC CARM and DARM.  It got past this twice and then failed later, during powering up.   I need to check the handoff.

Moved the unstick.py code to the ifotest repository here. It now handles signals like those generated by Ctrl-C and so forth. It can still be run as python unstick.py <machine1> <machine2> etc.

I cleaned up the south Electronics bench today.

The other two, as well as several of the desks are in some chaotic state of degradation. Please clean up your areas and put away projects which do not need to remain staged for several months. Try to eliminate "that's not mine" and "I don't know who's that is" from your vocabulary.  Fight back against entropy!

Sometimes ago I reported that there have been a kind of upconversion noise when PRM was excited (#6211).

This time I found another one, which showed up when BS was excited.

Assuming this is related to some kind of scattering process and also assuming this is from the same scattering body as that for the PRM driven case,

we may be able to localize and perhaps identify the scattering body.

(Measurement Condition)

(Noise spectrum)

Over the last couple nights we got the beam into the FSS path and all the way to the IMC and out onto the AP table.

Tara and Valera have calculated a mode-matching solution for the reference cavity. It utilizes only a single lens between the AOM and the reference cavity. Valera and Steve will move the reference cavity into place in the morning.

We noticed that the layout was too tight on the end going into the MC and so we adjusted the angle of the final zig-zag. This will put the final mode-matching lens in between the final steering mirrors (which is generally undesirable) but the lens in this case is only f=400 mm. In addition, this lens may provide some more decoupling between the steering mirrors.

The whole layout has to be a little adjusted because of a calculation mistake I made in the mode-matching. I used only the nominal focal lengths from the CVI catalog and not the effective one. For the UV-grade fused silica lenses, the effective focal length is actually 20-30% longer. Today we measured that the "f=200 mm" lens we got is actually f = 238 mm. The BK7 lenses are much closer to the nominal.

We also replaced the Klinger mount ahead of the PMC with a Polanski style so that we could get the PMC REFL beam out without hitting the mount. Valera will continue to refine this section on the weekend.

Tomorrow, we will lock the MC using feedback only to the NPRO. The 0-150 V piezo driver is on the PSL table ready for action.

I also got a LCD video monitor from Frank and hooked it up on the PSL table. If we like this kind of thing, we can get many of them. They are pretty cheap. It would be handy to have 3-4 of them on the PSL and one on every of the ISC tables. They take the standard video for input and need +12V for power. Right now the one in there is looking at the PMC transmission.

The Omnigraffle layout as of tonight is attached.

I put some green stuff on the layout drawing.

I continue to refine the positions of these stuff.

Notes :

 1. I flipped the reference cavity. So now the cavity is sitting on the left hand side of the layout.

  2. I removed the ISS stuf. We should think about where ISS should be.

I tried SRMI. The glitch rate wasn't as high as that of PRMI but it happened once per 10 sec or so.

[Keiko / Kiwamu]

 Some updates on the locking activity:

• Started summarizing the data of the Michelson lock in a wiki page:
  • https://wiki-40m.ligo.caltech.edu/Interferometer_Characterization/Michelson_Noise_Budget
  • Some careful analysis of the OSA signals are missing
    • Besides the analysis we need to work on the mode matching to get a better resolution as Mirko achieved.
• Gradually moving on to the PRMI lock
  • The lock stays for reasonably a long time (~20 min or more)
  • POP22/110 demod signals seemed just ADC noise.
  • A first noise budget is in process
    • The glitches make the noise level worse above 40 Hz or so in both the MICH and PRCL budgets.
  • Sensing matrix will be measured tomorrow
  • The data will be also summarized in a wiki page

We tried to measure the sensing matrix for MICH and PRCL last night. They look too much mixed as we expect... the matrix may be posted later. We suspect the IX and IY of the MICH excitation is not balanced very well, although Kiwamu adjusted that about two weeks ago, and it is mixing the dof. We'll try to balance it again, ans see the matrix. 

Keiko, Kiwamu

ITMX and ITMY balance for the MICH excitation (lockin) is adjusted again. Now it's ITMx = -0.992, ITMy = 1 for MICH (lockin output matrix values).

RA: what were the old values? Does this change make any difference for the signal mixing noticed before?

The vent is still going on. At this moment the pressure inside of the chambers is about 630 Torr.

Koji and I have replaced the 2nd instrument grade compressed air cylinder by the 3rd cylinder around 9 pm.

So far the vent speed has been nicely kept at about 1 Torr / min.

I wanted to use locate to find some files today, but found that it doesn't index any of our NFS mounted files (i.e. the whole /cvs/cds/ and /opt/rtcds/ ).

So I went into /etc/updatedb.conf and edited it like so, so that it no longer ignores NFS type file systems:

controls@rossa:/etc 0$ diff updatedb.conf updatedb.conf~
4c4
< PRUNEFS="nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs ecryptfs fusesmb devtmpfs"
---
> PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs ecryptfs fusesmb devtmpfs"

The CRON.daily on ROSSA only should run each morning at 6:25 (under the ionice class 3 protocol as usual). If this seems OK after a week or so, we can do the same for the other CDS workstations (remembering to adjust their cron.daily times so that not every one hammers the NFS at the same time).

I modified /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini to include the C1:LSC-DegreeOfFreedom_TRIG_MON channels.  These are the same channel that cause the LSC screen trigger indicators to light up. 

I vaguely followed Koji's directions in elog 5991, although I didn't add new grecords, since these channels are already included in the .db file as a result of EpicsOut blocks in the simulink model.  So really, I only did Step 2.  I still need to restart the framebuilder, but locking (attempt at locking) is happening.

The idea here is that we should be able to search through this channel, and when we get a trigger, we can go back and plot useful signals (PDs, error signals, cotrol signals,....), and try to figure out why we're losing lock. 

Rana tells me that this is similar to an old LockAcq script that would run DTT and get data.

EDIT:  I restarted the daqd on the fb, and I now see the channel in dataviewer, but I can only get live data, no past data, even though it says that it is (16,float).  Here's what Dataviewer is telling me:

Connecting to NDS Server fb (TCP port 8088)
Connecting.... done
read(); errno=0
LONG: DataRead = -1
No data found

read(); errno=9
read(); errno=9
T0=13-03-29-08-59-43; Length=432010 (s)
No data output.


I seem to be able to retrieve these channels ok from the past:

controls@pianosa:/opt/rtcds/caltech/c1/scripts 0$ tconvert 1049050000
Apr 03 2013 18:46:24 UTC
controls@pianosa:/opt/rtcds/caltech/c1/scripts 0$ ./general/getdata -s 1049050000 -d 10 --noplot C1:LSC-PRCL_TRIG_MON
Connecting to server fb:8088 ...
nds_logging_init: Entrynds_logging_init: Exit
fetching... 1049050000.0
Hit any key to exit: 
controls@pianosa:/opt/rtcds/caltech/c1/scripts 0$ 

Maybe DTT just needed to be reloaded/restarted?

apt install source-highlight

then modified bashrc to point to /usr/share instead of /usr/bin

Below are new alamode calculations of the PRC and SRC g-factors and arm mode matchings.  These include fixes to the ABCD matrices for the flipped folding mirrors that properly (hopefully) take into account the focusing effect of passing through the optic substrates.

I've used nominal curvatures of -600 m for the G&H PR2/SR2 optics, and -700 m for the Laseroptik PR3/SR3 dichroics.

An interesting and slightly disappointing note is that it looks like it actually would have been better to flip PR3 instead of PR2, although the difference isn't too big.  We should considering flipping SR3 instead or SR2 when dealing with the SRC.  I'll take responsibility for messing up the calculation for the flipped TTs.

PRC

SRC

RXA: maybe nominal, but we don't actually have measurements of the installed optics' curvatures, so there could be ~10-15% errors in the RoC. Which translates into a 1-2% error in the g-factor.

I think we like the idea of flipping SR2 better than SR3 for the same ghost beam reasons as PR2 is better than PR3.  There isn't very much free space in the BS chamber, and if we flip PR/SR3, we have to deal with green ghosts as well as IR.

The flipping SR2 case seems okay to me - flipping either one of the SR folding mirrors gives us a slightly better g-factor than the design with infinite curvatures, and flipping SR2 gives us slightly better mode matching to the arm than the flipped SR3 case, but more importantly, there are fewer ghosts to deal with.  I vote we flip SR2, not SR3.

 Updated laser inventory and operator list. They are posted in the 40m wiki and entry doors of the 40m IFO room.

Let me know if this list needs correction.

Lightwave  M126N-1064-700 NPRO sn 337 in the PSL enclosure got connected to local emergency shut off switch. This is a LIGO operational safety requirement.

In an attempt to clean up the medm situation, I did a bunch of further rearrangement and cleanup.  Instead of having c1ifo, I moved a bunch of stuff into a MISC directory, including all of the CDS, IFO, and VIDEO screens:

controls@rossa:~ 0$ ls -1 /opt/rtcds/caltech/c1/medm/MISC | grep -v _BAK
CDS_BIO_STATUS.adl
CDS_FE_STATUS.adl
CDS_IPC_ERR.adl
help
ifoalign
IFO_ALIGN.adl
ifoalign.orig
IFO_CONFIGURE.adl
IFO_CONFIGURE.txt
IFO_OVERVIEW.adl
IFO_OVERVIEW_AIDAN.adl
IFO_STATE.adl
snap
VIDEO.adl
controls@rossa:~ 0$

I updated the sitemap and the relevant screens accordingly.

I also updated the IFO_ALIGN script infrastructure a bit.  The new IFO ALIGN location is /opt/rtcds/caltech/c1/medm/MISC/ifoalign.  The scripts are now called simply:

/opt/rtcds/caltech/c1/medm/MISC/ifoalign/misalign_soft.csh
/opt/rtcds/caltech/c1/medm/MISC/ifoalign/restore_soft.csh
/opt/rtcds/caltech/c1/medm/MISC/ifoalign/save_soft.csh

These run Jenne's new soft restore stuff, and store burt snapshots for optic alignment in /opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt.

This has all been checked into the svn.

I updated the getdata script so that it can now handle downloading long stretches of data.

  /opt/rtcds/caltech/c1/scripts/general/getdata

It now writes the data to disk incrementally while it's downloading from the server, so it doesn't fill up memory.

I also added a couple new options:

* --append allows for appending to existing data files

* --noplot suppresses plotting during download

I updated the peakFit routines to make them a bit more user friendly:

• modified so that any subset of optics can be processed at a time, instead of just all
• broke out tweakable fit parameters into a separate parameters.m file
• added a README that describes use

These changes were committed to the 40m svn.

I was working with the git repo in the SnapPy_pypylon folder (/cvs/cds/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon) and needed to create a branch. To avoid any confusion, I modified the PS1 variable and that alone in the bashrc file to reflect the git branch so that the prompt now displays the git branch if you enter a repository. This is just an update.

After poking at the new configuration more, it also started to show instability.  I couldn't figure out how to make test points or excitations available in this configuration, and adding in the full set of test point channels, and trying to do simple things like plotting channels with dtt, the frame writer (fw) would fall over, apparetnly unable to keep up with the broadcast from the dc.

I've revered everything back to the old semi-working fb configuration, and will be kicking this to the CDS group to deal with.