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.
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 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:
(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 )
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 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:
I have not yet checked if these photodiodes are in working order.
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 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:
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.
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.
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.
[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.
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'.
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.
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.
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.
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.
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.
11MHz modulation source was turned off (disabled) at Marconi at 12:00.
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.
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
# Resonant RF diode front end
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.
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.
[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.
Currently, DC power for amplifiers ZHL-1000LN+ is supplied by Aligent E3620A.
I tried to use power supply from the side of 1X1 rack, but fuse plug(Phoenix Contact ST-SI-UK-4) showed red LED, so I couldn't use it.
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.
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.
what is next?
Atm 3, Ron Drever could not celebrate with us because of health issues.
/home/cds is >98% full - below are some of the usage numbers:
controls@rosalba:/users/OLD 0$ du -h --max-depth=1
controls@rosalba:/opt/rtcds/userapps 0$ du -h --max-depth=1
linux1:cds>nice du -h --max-depth=1
du: `./llo/chans/daq/archive': Permission denied
du: `./llo/chans/daq/old': Permission denied
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.
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:
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
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
1.8T 1.4T 325G 82% /opt/rtcds
fb:/frames 13T 12T 559G 96% /frames
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
The daqd process is segfaulting and restarting itself every 30 seconds or so. It's pretty frustrating.
Just for kicks, I tried an mxstream restart, clearing the testpoints, and restarting the daqd process, but none of things changed anything.
Manasa found an elog from a year ago (elog 7105 and preceding), but I'm not sure that it's a similar / related problem. Jamie, please help us
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:
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.
I was able to bring back svn 1.6 formatting to /cvs/cds/caltech/chans by doing the following on nodus:
svn co https://nodus.ligo.caltech.edu:30889/svn/trunk/chans ./
rm -rf ../chans/.svn
mv ./.svn ../chans/
Note that I used the http address for the repository. The svn repository doesn't live at file:///cvs/cds/caltech/svn anymore; all of our checkouts (e.g. in the scripts directory) use http to get the one true repo location, regardless of where it lives on nodus' filesystem. (I suppose we could also use https://nodus.martian:30889/svn to stick to the local network, but I don't think we're that limited by the caltech network speed)
Presumably, at some point we will want to introduce a newer operating system into the 40m, as ubuntu 12.04 hits end-of-life in April 2017. Ubuntu 16.04 includes svn 1.8, so we'll also hit this issue if we choose that OS.
Aside from the svn issues, this directory (/cvs/cds/caltech/chans) only contains pre-2010 channels. Filters and DAQ ini files currently live in /opt/rtcds/caltech/c1/chans, which is not under version control. It's also not clear to me why summary page configurations should be kept in this /cvs/cds place.
True - its an issue. Koji and I are updating zita into Ubuntu16 LTS. If it looks like its OK with various tools we'll swap over the others into it. Until then I figure we're best off turning allegra back into Ubuntu12 to avoid a repeat of this kind of conflict. Once the workstations in the LLO control room are running smoothly on a new OS for a year, we can transfer into that. I don't think any of us wants to be the CDS beta tester for DV or DTT.
Just to be clear, since there seems to be some confusion, the SVN issue has nothing to do with Debian vs. Ubuntu. SVN made non-backwards compatible changes to their working copy data format that breaks newer checkouts with older clients. You will run into the exact same problem with newer Ubuntu versions.
I recommend the 40m start moving towards the reference operating systems (Debian 8 or SL7) as that's where CDS is moving. By moving to newer Ubuntu versions you're moving away from CDS support, not towards it.
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.