No, not confused on that point. We just will not be testing OS versions at the 40m or running multiple OS's on our workstations. As I've said before, we will only move to so-called 'reference' systems once they've been in use for a long time.

Ubuntu16 is not to my knowledge used for any CDS system anywhere.  I'm not sure how you expect to have better support for that.  There are no pre-compiled packages of any kind available for Ubuntu16.  Good luck, you big smelly doofuses. Nyah, nyah, nyah.

Debian doesn't like EPICS. Or our XY plots of beam spots...Sad!

The problem is not exactly the same as what's described in 7105, but the symptoms are so similar I assumed they must have a similar source.

And sure enough, /frames is completely full:

controls@fb /opt/rtcds/caltech/c1/target/fb 0$ df -h /frames/
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              13T   13T     0 100% /frames
controls@fb /opt/rtcds/caltech/c1/target/fb 0$

So the problem in both cases was that it couldn't write out the frames.  Unfortunately daqd is apparently too stupid to give us a reasonable error message about what's going on.

So why is /frames full?  Apparently the wiper script is either not running, or is failing to do it's job.  My guess is that this is a side effect of the linux1 raid failure we had over xmas.

It actually looks like the wiper script has been running fine.  There is a log from Tuesday morning:

controls@fb ~ 0$ cat /opt/rtcds/caltech/c1/target/fb/wiper.log

Tue Jan  7 06:00:02 PST 2014

Directory disk usage:
/frames/trend/minute_raw 385289132k
/frames/trend/second 100891124k
/frames/full 12269554048k
/frames/trend/minute 1906772k
Combined 12757641076k or 12458633m or 12166Gb

/frames size 13460088620k at 94.78%
/frames is below keep value of 95.00%
Will not delete any files
df reported usage 97.72%
controls@fb ~ 0$

So now I'm wondering if something else has been filling up the frames today.  Has anything changed today that might cause more data than usual to be written to frames?

I'm manually running the wiper script now to clear up some /frames.  Hopefully that will solve the problem temporarily.

The wiper script is done and deleted a whole bunch of stuff to clean up some space:

controls@fb ~ 0$ /opt/rtcds/caltech/c1/target/fb/wiper.pl --delete

Tue Jan  7 23:09:21 PST 2014

Directory disk usage:
/frames/trend/minute_raw 385927520k
/frames/trend/second 125729084k
/frames/full 12552144324k
/frames/trend/minute 2311404k
Combined 13066112332k or 12759875m or 12460Gb

/frames size 13460088620k at 97.07%
/frames above keep value of 95.00%
Frame area size is 12401156668k
/frames/full size 12552144324k keep 11781098835k
/frames/trend/second size 125729084k keep 24802313k
/frames/trend/minute size 2311404k keep 620057k
Deleting some full frames to free 771045488k
- /frames/full/10685/C-R-1068567600-16.gwf
- /frames/full/10685/C-R-1068567616-16.gwf
...
controls@fb ~ 0$ df -h /frames
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              13T   12T  826G  94% /frames
controls@fb ~ 0$

So it cleaned up 826G of space.  It looks like the fb is stabilized for the moment.  On site folks should confirm...

asdfasdfsadf sadf asdf

 Late last night we were getting some problems with DAQD again. Turned out to be /frames getting full again.

I deleted a bunch of old frame files by hand around 3AM to be able to keep locking quickly and then also ran the wiper script (target/fb/wiper.pl).

controls@pianosa|fb> df -h; date

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda1             440G  9.7G  408G   3% /

none                  7.9G  288K  7.9G   1% /dev

none                  7.9G  464K  7.9G   1% /dev/shm

none                  7.9G  144K  7.9G   1% /var/run

none                  7.9G     0  7.9G   0% /var/lock

none                  7.9G     0  7.9G   0% /lib/init/rw

none                  440G  9.7G  408G   3% /var/lib/ureadahead/debugfs

linux1:/home/cds      1.8T  1.4T  325G  82% /cvs/cds

linux1:/ligo           71G   18G   50G  27% /ligo

linux1:/home/cds/rtcds

                      1.8T  1.4T  325G  82% /opt/rtcds

fb:/frames        13T   12T  559G  96% /frames

linux1:/home/cds/caltech/users

                      1.8T  1.4T  325G  82% /users

Tue May 13 17:35:00 PDT 2014

Looking through the directories by hand it seems that the issue may be due to our FB MXstream instabilities. The wiper looks at the disk usage and tries to delete just enough files to keep us below 95% full for the next 24 hours. If, however, some of the channels are not being written because some front ends are not writing their DAQ channels to frames, then it will misestimate the disk size. In particular, if its currently writing small frames and then we restart the mxstream and the per frame file size goes back up to 80 MB, it can make the disk full.

For now, I have modified the wiper.pl script to try to stay below 93%. As you can see by the above output of 'df', it is already above 96% and it still has files to write until the next run of wiper.pl 7 hours from now at. at 6 AM.

IF we assume that its writing a 75MB file every 16 seconds, then it would write 405 GB of frames every day. There is 559 GB free right now so we are OK for now. With 405 GB of usage per day, we have a lookback of ~12TB/405GB ~ 29 days (ignoring the trend files).

 Script seems to be working now:

nodus:~>df -h | grep frames

fb:/frames              13T    12T   931G    93%    /frames

/home/cds is >98% full - below are some of the usage numbers:

controls@rosalba:/users/OLD 0$ du -h --max-depth=1
42M    ./katrin
1.5M    ./ben
2.4M    ./sanjit
569M    ./waldman
328M    ./sonia
3.6G    ./lsinger
44M    ./dbusby
105M    ./dbarron
21M    ./manuel
709M    ./yaakov
46M    ./rodionov
240M    ./ishwita
2.7G    ./clara
56M    ./gopal
290M    ./mashaB
87M    ./varvella
5.6M    ./Sascha
2.9G    ./ryan
190M    ./nancy
3.5G    ./john
269M    ./elizabeth.davison
165M    ./jweiner
460K    ./mjones
49M    ./stephanie
52M    ./mohana
56M    ./noriyasu
38M    ./mjenson
76M    ./sballmer
224M    ./kirk
812K    ./bonnie
33M    ./janosch
16M    ./kevin
122M    ./dblair
2.6G    ./mirko
389M    ./keenan
195M    ./tf
150M    ./littlezach
193M    ./jmiller
1.8G    ./ting
131M    ./dmalling
842M    ./sharmila
1.4G    ./caryn
12G    ./rward
4.1M    ./jay
443M    ./emintun
184M    ./katharine
76K    ./nick
804K    ./nicole.ing
14M    ./jenny
542M    ./vsanni
45M    ./peter
7.8G    ./miyakawa
4.8M    ./channa
4.0K    ./frank
9.9G    ./razib
35M    ./amin
361M    ./sharon
62M    ./bram
3.9M    ./volodya
7.9M    ./larisa
301M    ./sasha
33M    ./eric.hendries
18M    ./vuk
101M    ./huan
1.8M    ./sonali
453M    ./megan
43M    ./Royal
5.4G    ./ayaka
19M    ./mott
518M    ./justing
501M    ./avi
173M    ./kakeru
3.9G    ./alberto
41M    ./paul.fulda
59M    ./elena
67G    .

controls@rosalba:/opt/rtcds/userapps 0$ du -h --max-depth=1
1.4G    ./tags
13M    ./trunk.bak
40K    ./.svn
3.0G    ./trunk
174M    ./trunk.bak2
4.2G    ./branches
8.7G    .

linux1:cds>nice du -h --max-depth=1
du: `./llo/chans/daq/archive': Permission denied
du: `./llo/chans/daq/old': Permission denied
707M    ./llo
9.7M    ./mit~
752K    ./raidwebFirmware
462M    ./epics
2.1G    ./tmp
1.5G    ./gds
76M    ./project
9.1G    ./ligo
449G    ./rtcds
3.3G    ./apps
20K    ./.kde
512K    ./cdscfg
1.4M    ./.Trash-controls
5.8M    ./scripts
20K    ./.TemporaryItems
964G    ./caltech
71M    ./bin
16K    ./.Trash-1001
4.5G    ./rtapps
564M    ./src
11M    ./vw
3.8M    ./dvSave
460M    ./lho
1.2G    ./data
1.5T    .

One of the reasons that our disk is getting full is due to the scripts_archive directory. A backup script runs on op340m and makes a tar.bz2 file of the scripts directory and puts it in scripts_archive every morning at 6 AM.

On Oct 7, 2011, Koji fixed this script to point at our new scripts directory instead of the old /cvs/cds/caltech/scripts directory. Since then, however, no one has fixed the exclude file to NOT back up the junk that's in that directory. Its a 1.6 GB directory so its full of it.

I've deleted a bunch of junk from the scripts directory: this directory is for scripts, not for your personal home movies or junk data files. Put those in your USER directory. Put temporary data files in /tmp/. I've also added a few more patterns to the exclude file so that less .mpg, .png, .pdf, .dat, etc get stored every day. The new daily .tar.bz2 file wil be ~25 MB instead of 770 MB.

(also fixed the backup script to use 'env' to setup the perl environment and removed the hard-coded path to tar)

 OUr disk was getting full again. Turned out my "fix" to 25 MB was only a fix to 250 MB. Since we were getting disk full warnings on our Ubuntu workstations, I deleted some COMSOL.dmg files from users/zach/ and then started deleting every other tarball from the scripts_archive directory. ~221 GB are now free. Still need to fix the exclude file for scripts better.

   Beautifully Done

   Chirp

  what is next?

Atm 3, Ron Drever could not celebrate with us because of health issues.

I think we can try to damp 1 Hz resonance more. In September it was not seen because of the digital noise. After we've figured it out, 1 Hz resonance began to be more clear (blue line).

Now applying oaf we reduce the effect of the stack and the 1 Hz resonance is even more clear:

Static filter was adjusted to filter 1 Hz resonance in MCL and it could do it. Stack is not great in this experiment due to the phase mismatch. I'll fix it.

 Yuta, Jenne

We fixed things so that we are now using regular fused rack power for these amplifiers.  The fuse no longer had a red LED, but it measured open when we checked the resistance.  Although, somehow (magic?) 13.73V were getting to the other side of the fuse. 

Anyhow, replacing the fuse with a new one fixed the problem right up.

[Jenne, Kyung Ha]

We made some good progress on suspending the Tip Tilt ECDs today.  We finished one whole set, plus another half.  The half is because one of the screw holes on the lower right ECD somehow got cross threaded.  The ECD and screws in question were separately wrapped in foil to mark them as iffy.  We'll redo that second half tomorrow.  This makes a total of 2.5 (including yesterday's work) ECD backplanes suspended.  The only thing left for these ones is to trim up the excess wire.

We also (with Koji) took a look at the jig used for suspending the mirror holder.  It looks like it was designed for so many Tip Tilt generations ago as to be basically useless for the 40m TTs.  The only really useful thing we'll get out of it is the distance between the suspension block and the mirror holder clamps.  Other than that we'll have to make do by holding the mirror and block at the correct distance apart, utilizing a ruler, calipers, or similar.  Rana pointed out that we should slightly bend the blade springs up a bit, so that when they are holding the load of the mirror holder, they sit flat. 

Attached below are 2 different pictures of one of the ECD backplane sets that has been suspended.  One with black background to illustrate the general structure, and one with foil background to emphasize the wires.

I noticed that we have not been saving the 1/sqrt(TRX) and 1/sqrt(TRY) data, so I modified the c1lsc model and added them to the DAQ channels block.  I restarted the c1lsc model, and the _DQ channels are now archived.

1064 nm Semiconductor Laser Fiber Distribution System and Mirror Tomography

Below threshold these Semiconductor Fabry-Perot lasers have an axial mode structure with a spacing of about a THz. As you turn up the current to above threshold the first mode to oscillate saturates the gain down on all the modes and only it oscillates.  The laser I have here in my office (a backup for the one you have at the 40 meter) has a wavelength of 1064.9 nm at 70 Degrees C.  We should be able to temperature tune it down to 1064.3 nm although this could be a bit tedious the first time we do it. The specifications claim a "spectrum width" of 1.097 nm which I believe is the temperature tuning range.  I don’t know what the line width is but it will be single frequency and we shouldn’t have mode hoping problems.  So we should be able to use it in the “Mirror Tomography” experiment.  You might want to use some sort of polarization diversity to avoid the problems of fiber polarization drift.

There have been 2 student projects on using the fiber distributed PD frequency response at1064 nm laser.

“Automated Photodiode Frequency Response Measurement System,” Alexander Cole - T1300618

“Final Report: Automated Photodiode Frequency Response Measurement System for Caltech 40m lab,” Nichin Sreekantaswamy - P140021

I’ll look up a few more references and add include them in the next elog.

Eric

This is a simple representation of the schematic:

          gnd
#          |
#          Cw2
#          |
#          n23
#          |
#          Lw2
#          |
#           n22
#          |
#          Rw2                 
#                 |                   |\             
#           n2- - - C2 - n3 -  - -  - |  \           
#            |    |      |   |        |4106>-- n5 - Rs -- no
# iinput    Rd   L1     L2 R24    n6- |  /     |           |
#      nin - |    |      |   |    |   |/       |         Rload     
#           Cd   n7     R22 gnd   |            |           |           
#            |    |      |        | - - - R8 - -          gnd               
#           gnd  R1     gnd      R7  
#                 |               |
#         gnd               gnd
#                  
#
#

I chose the values of the components in a realistic way, that is using part available from Coilcraft or Digikey.

Using LISO I simulated the Tranfer Function and the noise of the circuit.

I'm attaching the results.

I'll post the 55MHz rfpd later.

oops, forgotten the third attachment...

here it is

 Absolutely hokey. What are our requirements for this RFPD? What are the power levels and SNR that we want (I seem to remember that its for 22 as well as 110 MHz)? Perhaps we can test an aLIGO one if Rich has one sitting around, or if the aLIGO idea is to use a broadband PD I guess we can just keep using what we have.

11MHz modulation source was turned off (disabled) at Marconi at 12:00.

As I see it, we have a few options for getting the 110 MHz LO to both the POP110 and AS110 demod boards.  

The current situation is described by Kiwamu in elog 5746.  The 55 MHz signal comes into the box, and is split 4 ways, with each path having 19.7 dBm.  One of these 4 is for 110.  It has a 2dB attenuator (giving us ~17.7 dBm), and then it goes to an MK-2 frequency multiplier.  I'm a little lost on why we're giving the MK-2 17 dBm, since it says that it can handle an input power between 1 - 15 dBm.  It has ~16 dB conversion loss, so the 110 output of the distribution board has (according to the drawing) 1.9 dBm.  The demod boards have a 10 dB attenuator as the first element on the LO path, so we're giving the ERA-5 -8 dBm. 

We can either amplify the 110 leaving the distribution box, split it, and then attenuate it to the appropriate level for the demod boards, or we can change the attenuators on the POP110 and AS110 demod boards. 

Since we seem to be over driving the 2x frequency multiplier, I think I should change the 2dB attenuator to a 5dB attenuator, so we're giving the 2x multiplier ~15 dBm.  The conversion loss of ~16 dB means we'll have -1 dBm of 110 MHz.  I want to amplify that by ~10 dB, to give 9 dBm.  Attenuate by 5 dB to get to 4 dBm, then split into 2, giving me 2 110 MHz spigots, each of ~1 dBm.  Since the demod boards expect between 0-2 dBm for the LO's, this should be just fine.

Thoughts, before I start scrounging parts, and pulling the RF distribution box?

- Do we have an appropriate amplifier?

- True challenge could be to find a feedthrough for the new port. (or to find a space for the amplifier in the box)

- PDXXX channels is on the DC whitening filter module. There could be some modification on this module (like diabling the whitening gain selector).

- We don't have AS11 and AS165, and so far it is unlikely to use AS11. i.e. The feedthrough, the slot on the crate, the whitening, and the channels can be trasnsition from 11 to 110.

Manasa and Steve,

Is this what you want?  Dashed lines are dark.

BS and PRM oplevs are blocked for this measurement. I will restore to normal operation at 4pm today.
 

It doesn't work with the lens in there, but it seems pretty close. Please leave it as is and I'll play with it after 5 today.

To test what the inherent angular noise of the HeNe 1103P laser is, we're testing it on a table pointing into the BS OL QPD with only a few steering mirrors.

From the setup that I found today, I've removed the lens nearest to the laser (which was used for the BS and PRM) as well as the ND filter (what was this for?) and the lens placed just before the BS QPD.

With the ND filter removed, the quadrant signals are now ~15000 if we misalign it and ~9000 each with the beam centered.

In order to calibrate the OLPIT_IN1 and OLYAW_IN1 signals into mm of beam motion, I misaligned the mirror just before the QPD. The knobs on there actuate the 100 TPI screws and the knurling on the knob itself has 10 ridges, so that's 36 deg per bump.

PIT cal ~ 1.55 (knob deg / count) -->> 10 microns / count --->>> 10 urad / count

YAW cal ~ 1 (knob deg / count)  -->> 6.5 microns / count --->>> 6.5 urad / count

Distance from the 45 deg turning mirror to the QPD silicon surface is 23 cm. Distance between knob tip and fixed pivot point is ~4 cm. 1 knob turn = 0.01" = 0.254 mm = 0.254/40 radians of mirror angle.

So 360 deg of knob gives 2*0.254/40 = 0.012 radians of beam angle = 0.012 * 230 mm ~2.3 mm of beam spot motion. Or 6.4 microns of translation / deg of knob.

The distance from the face of the laser to the QPD is 96 cm.

The punchline is that the laser shows a level of noise which has a similar shape to what's seen at LLO, but 10x lower.

The noise at 0.05 - 0.2 Hz is ~2-3x worse than the PR3 at LLO. Not sure if this is inherent to the HeNe or the wind in our setup.

After a power outage, a Marconi comes back to it's defaults.  It needed to be reset to the values in elog 5530.  I'm putting a label on the Marconi so we don't have to look it up next time.

Before fixing the Marconi, POY11, AS11 and AS55 all looked like noise, no real signals, even though the arm is flashing.  Now they all look PDH-y, so things are better.

I read a few datasheets of the C30642GH photodiode that we're going to use for the 11 and 55 MHz. Considering the  values listed for the resistance and the capacitance in what they define "typical conditions" (that is, specific values of bias voltage and DC photocurrent) I fixed Rd=25Ohms and Cd=175pF.

Then I picked the tunable components in the circuit so that we could adjust for the variability of those parameters.

Finally with LISO I simulated transfer functions and noise curves for both the 11 and the 55MHz photodiodes.

I'm attaching the results and the LISO source files.

Use 10 Ohms for the resistance - I have never seen a diode with 25 Ohms.

p.s. PDFs can be joined together using the joinPDF command or a few command line options of 'gs'.

[Rana, Koji, Kiwamu]

 Moreover the amplitude of the I and Q signals are highly unbalanced, depending on the LO power again.

This implies the coil for a 90 degree splitting won't work at 11 MHz since the coil is home made and used to be designed for a specific frequency (i.g. 24.5 MHz).

We decided to use a Mini circuit 90 deg splitter instead. Steve will order few of them soon and we will test it out.

One way to avoid some of the bad stuff in there is to take the 1 dBm input and amplify it to ~21 dBm before splitting and sending in to the Level 17 mixers.

One way to do this is by using the A3CP6025 from Teledyne-Cougar. Its an SMA connectorized amp which can put out 25 dBm and has a gain of 24 dB. We can just glue it onto the demod boards. Then we can remove the ERA-5 amplifiers and just use the broadband splitter as Kiwamu mentioned.

During checking the 11MHz demod boards I found that the I-Q relative phase showed funny LO power dependence.

It is now under investigation.

 In the plot above the green curve represents the I-Q phase of a 11MHz demod board (see here).

It showed a strong dependence on the LO power and it changes from -60 deg to -130 deg as the LO power changes.

This is not a good situation because any power modulation on the LO will cause a phase jitter.

For a comparison I also took I-Q relative phase of a 33MHz demod board, which hasn't been modified recently.

 It shows a nice flat curve up to 5 dBm although it looks like my rough measurement adds a systematic error of about -5 deg.

 - to do -

* check RF power in every point of LO path on the circuit

* check if there is saturation by looking at wave forms.

Riju hasn't been in the lab in a long time to do any measurements, so I put the signals back to how they should be. 

I turned off / confirmed off the things which were sending signal to the EOM:  the network analyzer, the RF generator box, and the Marconi which supplies the 11MHz. 

I removed the cavity scanning cable, and terminated it, and put the regular 11MHz cable back on the splitter.

I then turned on the RF gen box and the Marconi.  The Marconi had been off, so we were not getting any 11MHz or 55MHz out of the RF gen. box.  This is why I couldn't lock any cavities last night (duh). 

On to locking!

----------------- In other news,

While swapping out the EOM cable, I noticed that the DC power supply sitting under the POX table was supplying a weird value, 17 point something volts.  I checked on the table to remind myself why that power supply is there...it's powering an RF amplifier right after the commercial PD that is acting as POP22.  The amplifier wants +15 and GND, so I reset the power supply to 15V.  We should add this to the list of things to fix, because it's dumb.  Either we need to put in the real POP22 (long term goal), or we need to get this guy some rack power, and do the same for any amplifiers for the Beat setup.  It's a little hoakey to have power supplies littering the lab.

I have configured one of the spare Supermicro X8DTU-F chassis as a dual-CPU, 12-core CDS front end machine.  This is meant to be a replacement for c1sus.  The extra cores are so we can split up c1rfm and reduce the over-cycle problems we've been seeing related to RFM IPC delays.

I pulled the machine fresh out of the box, and installed the second CPU and additional memory that Steve purchased.  The machine seems to be working fine.  After assigning it a temporary IP address, I can boot it from the front-end boot server on the martian network.  It comes up cleanly with both CPUs recognized, and /proc/cpustat showing all 12 cores, and free showing 12 GB memory.

The plan is:

1. pull the old c1sus machine from the rack
2. pull OneStop, Dolphin, RFM cards from c1sus chassis
3. installed OneStop, Dolphin, RFM cards into new c1sus
4. install new c1sus back in rack
5. power everything on and have it start back up with no problems

Obviously the when of all this needs to be done when it won't interfere with locking work.  fwiw, I am around tomorrow (Tuesday, 2/11), but will likely be leaving for LHO on Wednesday.

I did a quick calculation to determine the amount of sideband transmission through the FP cavity.

The modulation frequency of the end PDH is 216kHz. The FSR of the cavity is about 3.9MHz. So the sidebands pick up about 0.17 radians extra phase on one round trip in the cavity compared to the carrier.

The ITM reflectance is r_ITM^2 = 98.5% of power, the ETM reflection is r_ETM^2 = 95%.

So the percentage of sideband power reflected from the cavity is R_SB = r_ITM*r_ETM*(exp(i*0.17) - 1)^2 / (1 - r_ETM*r_ITM exp(i*0.17) )^2 = 0.85 = 85%

So about 15% of the sideband power is transmitted through the cavity. The ratio of the sideband and carrier amplitudes at the ETM is 0.05

So, on the vertex PD, the power of the 80MHz +/-200kHz sidebands should be around sqrt(0.15)*0.05 = 0.02 = 2% of the 80MHz beatnote.

Once we get the green and IR locked to the arm again, we're going to look for the sidebands around the beatnote.

I looked through the lab area to do a fast photodiode inventory check, as we may need to buy some for the higher order mode spectroscopy SURF project. I looked on the following optical tables: ETMY, ITMY, BS, AS, PSL, SP, ITMX, Jenne laser table, and ETMX, as well as the photodiode cabinet, and could only find two 1611s. Here is a summary of the inventory: 

• Power supply 0901: 2x in photodiode cabinet (E6 along the Y arm), 1x on Jenne laser table
• Newfocus 1611 S/N 7284-WX, labelled "REF DET" on ITMY optical table, currently unused
• Newfocus 1611 S/N 57109 on Jenne laser table

I have not yet checked if these photodiodes are in working order.

I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.

I'm doing a couple of measurement and I'll put it back in as soon as I'm done.

 These are the losses I measured on a RG-174 cable for the two frequencies that we're planning to use in the Upgrade:

@11MHz Loss=0.22dBm/meter

@55MHz Loss=0.41dBm/meter

(The cable was 2.07m long. The input signal was +10dBm and the output voltages at the oscilloscope where: Vpk-pk(11MHz)=1.90V, Vpk-pk(11MHz)=1.82V )

They must not be dBm, must be dB

I apologize for the lack of correctness on the units in yesterday's elog entry, but I wasn't very sharp last night.

I repeated the measurement today, this time also making sure that I had a 50ohm input impedance set in the scope. These the results for the losses.

 I also measured the losses in the Heliax cable going from the 166 MHz LO to the LSC rack:

 Seems like very strange cable loss numbers. The Heliax is lossier than the RG-174? I wonder how these compare with the specs in the cable catalog?

I did the measurement on a 4.33 meter long cable with SMA connectors at the ends.

I replaced the SMA end connector for the 166 MHZ Local Oscillator signal that goes to the back of the flange in the 1Y2 rack. The connector had got damaged after it twisted when I was tigheting the N connector of the Heliax cable on the front panel.

I turned off the modulation at 166MHZ becasue I don't need it if I'm only locking the PRC.

It was introducing extra amplitude modulations of the beam which interfered with the AbsL's PLL photodiode.

I'm going to turn it back on later on.

 I turned back on the 166MHz modulation just a bit. I set the slider at 4.156.

When it was totally off the MZ seemd quite unhappy.

 You can turn the 166 off if you want. MZ is unhappy after its turned off, but that's just the thermal transient from removing the RF heat. After a several minutes, the heat goes away and the MZ can be relocked.

One of these days we should evaluate the beam distortion we get in EOMs because of the RF heat induced dn/dT. Beam steering, beam size, etc.