||Wed Dec 5 17:49:57 2007
|Attached is a plot of the ISS RIN with a variety of gain settings. |
Unfortunately the dark noise is huge now--a result of the new cables & wiring?
|Attachment 1: rin.pdf
||Wed Dec 5 18:22:03 2007
||tobin||Update||PSL||ISS dark noise|
|Attached is a plot of the dark noise spectrum of the ISS photodiodes (1) before fooling with them, (2) after replacing the 4151's with 4131's (improvement!), and (3) after replacing the cables and changing the wiring (disaster!).|
|Attachment 1: sense_noise.pdf
||Wed Dec 5 20:32:51 2007
||tobin||Update||PSL||ISS dark noise|
|The ISS dark noise is not coming from the PD heads; the spectrum is essentially unchanged when the PD is unplugged from the ISS. Did the input opamps both get semi-fried in the same way? (They worked so well when they were first installed.) What else changed? I'm baffled. |
||Thu Dec 6 19:30:43 2007
||tobin||Update||PSL||ISS dark noise - 60 Hz!|
|A higher resolution spectrum [attached] shows that nearly all of the excess dark noise on the ISS is in 60 Hz harmonics (with some 256 Hz harmonics too--are these from the DAQ?).|
With the loop closed and the slider at 5dB, the laser light coming out has a noise floor of 10^-7 RIN or better from 40 Hz to 8 kHz.
Now to figure out why all this 60 Hz is getting in... (I tried turning off all the lights and the HEPA, and moving the SR785 further away, none of which did anything.)
|Attachment 1: iss.pdf
||Fri Dec 7 18:28:30 2007
||tobin||Update||Computer Scripts / Programs||compiled matlab hoses itself|
|Andrey pointed out to me that some matlab functions in the Signal Processing Toolbox were dying with errors. Looking into the .m file (identified using the "which" command), I was surprised to see binary garbage rather than glistening, clear Matlab prose. Then I noticed the directory in which it was finding the .m file:|
>> which decimate
/cvs/cds/caltech/apps/mDV/extra/linetrack_c_mcr/toolbox/signal/signal/decimate.mSee that "linetrack_c_mcr" directory? This is what is generated when a "compiled" (grumble) Matlab program is run--it decompresses itself into a subdirectory containing weird semi-compiled binary .m files. Unfortunately this is somehow getting incorporated into the matlab path. (I assume there is something in mDV that says "put all subdirectories into the path.")
I hate the Matlab compiler.
||Fri Dec 7 18:31:30 2007
||tobin||Update||Computer Scripts / Programs||compiled matlab hoses itself|
|Addendnum. The reason the linemon_mcr command was in the path was because of the user issuing the command "addpath(genpath(pwd))" where genpath(D) "returns a path string starting in D, plus, recursively, all the subdirectories of D."|
The Matlab compiler is still bad, however.
||Fri Dec 7 19:14:30 2007
||tobin||Update||PSL||ISS dark noise - ground loop enlightenment|
|My alleged 60 Hz harmonics were all from a ground loop created by connecting the SR785 ground to the ISS circuit ground; they disappeared when I set the SR785 input to "floating ground." doh!|
I modified the ISS PD's to have a 100 ohm resistor in series with the output (in place of 20 ohms). The diodes are again in place on the table, ready for action.
||Mon Dec 10 18:42:20 2007
||tobin||Update||PSL||ISS RIN script|
|I wrote a script to measure the ISS RIN. The script uses the "labca" interface (described in an earlier entry) to read and twiddle EPICS settings and mDV to get DAQ data. The script measures open loop RIN, closed loop RIN at each of several gain slider settings, and dark noise. The dark noise is obtained by misaligning (unlocking) the PMC. The script also compares the whitened and unwhitened spectra for an open loop measurement and performs a fit of a simple pole to find the dewhitening filter.|
This is all very exciting, but I don't quite believe the results, since the closed loop RIN seems to bottom out at 2e-7/rtHz regardless of the gain slider setting.
Sample output attached. The script may be found at scripts/PSL/ISS/rin.m.
|Attachment 1: rin-20071210-1831.pdf
||Mon Dec 10 19:08:03 2007
|The MZ seems finicky today--it keeps unlocking and relocking.|
I've temporarily blocked one of the MZ arms while I work on the ISS.
||Mon Dec 10 20:35:59 2007
||tobin||Configuration||Computer Scripts / Programs||autolocking scripts|
|I added this tidbit of csh code to the MZ autolocker to prevent multiple copies from running (on one computer):|
if (`pgrep lockMZ | wc -l` > 1) then
echo lockMZ is already running!
endifSimilarly, here's some bash code that does something similar; I'll add it to the other autolocker scripts:
pgrep `basename $0` | grep -v $$ > /dev/null
echo Another copy of this program is already running. Exiting!
fiThis code searches for all processes with the same name as this script ($0) and then use grep to exclude (-v) the current process ID ($$).
||Wed Dec 12 22:24:48 2007
|I poked at the weather station briefly this evening.|
* There's almost nothing in the elog about it.
* It exists. It is located on the North wall, just north of the beam splitter.
* It seems to be displaying reasonable data for the indoors, but nothing for the outdoor sensors.
* c1pem didn't seem to be starting up (couldn't telnet into it, etc). I altered its startup file and reset it several times, and eventually it came to life.
* the weather station has a serial cable that goes all the way to c1pem. I plugged it in.
* however, the Weather.st program complains "NO COMM"--it gets no data from the weather station
* The next thing to do is to plug in a laptop to that serial cable and see if the weather station can be convinced to talk.
||Tue Dec 18 16:50:35 2007
||tobin||Update||SAFETY||uvex laser safety glasses defective|
|A few days ago we noticed what appeared to be a blotched, speckled fracturing of the coating of the "UVEX" laser safety glasses. These are the glasses with "transparent" (reflective to 1064nm) lenses and white frames that we keep in a box on top of a filing cabinet in the control room. Today Steve measured the transmission of these glasses and found 80% transmission of 1064nm in several cases.|
Do not use the white, transparent "uvex" laser safety glasses until further notice. Steve has hidden them away so that you won't be tempted.
Below is attached a photo of a bad lens.
|Attachment 1: bad-glasses.jpg
|Attachment 2: bad-glasses-zoom.jpg
||Tue Dec 18 21:31:31 2007
|My measurements of the ISS RIN via the SR785 and via the DAQ disagree considerably. The spectral shapes are very similar, however, so I expect that a constant factor is creeping in somewhere. Measurements taken at the PD DC monitor points using the SR785 attached. There is a lot of excess noise in the 300 Hz - 1 kHz region.|
|Attachment 1: iss-rin.pdf
||Fri Dec 21 20:32:25 2007
|I couldn't resist any longer: I plugged in the Prosilica GC 750 GigE camera and took it for a spin. This is the little CMOS camera which sends out video over gigabit ethernet.|
There were no difficulties at all in getting it running. I just plugged in the power, plugged in ethernet, and put on a lens from Steve's collection. I downloaded the "Sample Viewer" from the Prosilica website and it worked immediately.
It turns out that "Kirk's" computer has not only a gigabit ethernet card, but a little gigabit ethernet switch. I plugged the camera into this switch. The frame rate is amazing. With the camera under fluorescent lights I thought I saw some wacky automatic gain control, but I think this ~10Hz flicker is aliasing of the 60 Hz room lighting.
I put the camera on the PSL table briefly and tried viewing the image from a laptop over the (54mbs) wireless network. This didn't work so well: you could get a couple frames out of the camera, but then the client software would complain that it had lost communications. It appeared that scattered 1064nm light did show up brightly on the camera image. There is a green ethernet cable currently stashed on the roof of the PSL that appears unused. We can try mounting the gigE CMOS cable in place of one of the CCD video cameras.
I did not try the Linux software.
The camera is currently set up at Kirk's desk, using the cool little tripod Rana got from CyberGuys.
This camera looks very promising! Also, in the test image attached below, a very unusual condition has been documented.
|Attachment 1: robs_desk.png
||Sat Dec 22 00:52:57 2007
|In an attempt to quell oscillations in the (unused) outer loop portion of the ISS, I shorted the "PD+" and "PD-" signals from the (nonexistent) outer-loop diodes, and soldered in 47pf compensation capacitors in C92 and C220. This seems to have eliminated oscillations seen at TP41 and TP42. There's still something amiss at TP30 and maybe TP20. Otherwise, the ISS seems happy. I can turn the gain slider to +15dB without saturation (with the HEPA off), though there seems to be less light on the diode (~3.9V) than a week or two ago.|
||Sat Dec 22 15:32:11 2007
|Ants are everywhere: on the PSL table, on the circuit board I'm soldering... |
I believe I have discovered their energy source.
|Attachment 1: DSC_0361.JPG
||Wed Jan 2 11:38:56 2008
||tobin||Summary||WIKI-40M Update||wiki spam|
|Our wiki keeps getting spammed. It turns out that you can upload attachments without a password, which is a bug. I'll ask David Barker whether there's a fix for this.|
||Thu Jan 10 00:12:01 2008
|[John, Tobin, Rana]|
1. We found SUS_BS_SENSOR_UL to have a ratty signal and low DC value. Twiddling the cables at the BS satellite amplifier and vacuum feedthrough brought the signal back (to 0.667V), but it is still spiky, spiking up to a couple times per second. Rana suggested that these spikes might be scattered YAG laser light (as hypothesized in August). The spikes go away when we misalign the PRM or either ITM, and when we unlock the mode cleaner, lending credance to this theory. SUS_BS_SENSOR_UR also spikes, but much less frequently. We turned off C1:SUS-BS_ULSEN_SW2 and continued.
2. After dither alignment the oplev beams were centred and we were able to lock DRM plus either arm reliably (however locking in this state broke ./drstep_bang at the first ``Going DD''). We ran scripts/DRFPMI/bang/nospring/drdown_bang and were subsequently able to lock DRFPMI (i.e., full IFO) a couple times.
3. To do: Debug ./drstep_bang with just the DRM (no arms).
||Mon Jan 14 23:11:26 2008
|John and I removed the fiber that ran from the SP table to the cleanroom. We plan to build a MZ interferometer with this fiber inserted into one of the arms, for the purpose of measuring its phase noise.|
||Tue Jan 15 13:15:27 2008
||tobin||Update||Environment||lots of noise|
|They're throwing concrete around at the construction site.|
||Wed Jan 16 19:57:49 2008
|Here's a photo of the ISCT_EX table, for the purpose of planning our auxiliary laser arm locking scheme. Note the (undumped!) beam from the beamsplitter before QPDX (the leftmost gold-colored box); perhaps we could inject there.|
|Attachment 1: trx-annotated-small.jpg
||Thu Jan 17 20:50:55 2008
|Sam, John, and I matched the beam from an NPRO into a fiber on the SP table today. In doing so we used our GigE camera for a physics application for perhaps the first time, viewing the transmitted mode from the fiber during initial alignment. (I used my laptop running Windows and a 100 megabit switch.)|
||Fri Jan 18 20:53:56 2008
|I monkeyed around with the ETMY oplev, adding a folding mirror and moving the HeNe so that John, Sam, and I have more room for our auxiliary laser setup. (The ISCT-EY has more room than ISCT-EX; the latter has an extra photodiode for IP ANG.) I believe I successfully recommissioned the oplev, though it might not be up to the SV standard. I verified that wiggling the ETMY alignment sliders showed corresponding wiggles in the oplev signals. However, it seems poorly diagonalized.|
Our current plan is to have an NPRO, EOM, and fiber coupler on the SP table. This fiber will take light to ISCT-EY where we'll have a mode-matching telescope and inject light to the Y arm via a polarized beamsplitter. This auxiliary beam will have polarization orthogonal to the beam from the PSL.
||Tue Jan 22 13:11:03 2008
||tobin||Update||ASC||ETMY oplev recentered|
|The light wasn't even on the diode.|
||Sun Jan 27 13:13:21 2008
|It's been grand. Thanks for having me!|
GWAVES IN '08!
Sugar napoleons may be forwarded to T. F., c/o LLO, P.O. Box 940, Livingston, LA 70754-0940.
||Sun May 25 21:14:14 2008
||tobin||Configuration||Computers||EPICS proxy server|
|I set up an EPICS gateway server on Nodus so that we can look at 40m MEDM screens from off-site.|
The gateway is set up to allow read access to all channels and write access to none of them.
The executable is /cvs/cds/epics/extensions/gateway; it was already installed. A script to start
up the gateway is in target/epics-gateway. For the time being, I haven't set it up to start itself
on boot or anything like that.
To make it work, you have to set the environment variable EPICS_CA_ADDR_LIST to the IP address of
Nodus. For instance, something like this should work:
setenv EPICS_CA_ADDR_LIST 184.108.40.206
On Windows you can set up environment variables in the "System" Control Panel. On one of the tabs
there's a button that lets you set up environment variables that will be visible to all programs.
On Andrey's machine I installed the Windows EPICS extensions, i.e. MEDM and its friends. I also
installed the cool Tortoise SVN client which lets you interact with SVN repositories through
the windows explorer shell. (The right-click menu now contains SVN options.) I checked out
the MEDM directory from the 40m SVN onto the desktop. You should be able to just right-click in
that window and choose "SVN Update" to get all the newest screens that have been contributed to
SVN; however, there are currently some problems with the 40m SVN that make that not go smoothly.
At the moment on Andrey's (Windows) machine you can go into the MEDM folder and double-click on
any screen and it will just work, with the exception that not all the screens are installed
due to SVN difficulties.
||Tue May 27 16:24:54 2008
||tobin||Configuration||Computer Scripts / Programs||ndsproxy|
|The NDS Proxy is a program that accepts NDS (LIGO Network Data Server) connections from the internet and relays them to|
our internal frame-builder, so that you can get DAQ and test-point channel data from off-site.
I stopped the ndsproxy that was running on rana and started it on nodus, its new home. This will be
documented in the wiki.
So far I haven't found a mechanism by which the ndsproxy was restarted automatically on rana. Has it just been
restarted by hand?
The ndsproxy stuff lives in target/ndsproxy. Restarting it seems to be just a matter of running "start_ndsproxy" in
||Fri May 30 21:30:15 2008
||tobin||Configuration||Computers||svn on solaris|
I installed svn on op440m. This involved installing the following packages from sunfreeware:
apache-2.2.6-sol9-sparc-local libiconv-1.11-sol9-sparc-local subversion-1.4.5-sol9-sparc-local
db-4.2.52.NC-sol9-sparc-local libxml2-2.6.31-sol9-sparc-local swig-1.3.29-sol9-sparc-local
expat-2.0.1-sol9-sparc-local neon-0.25.5-sol9-sparc-local zlib-1.2.3-sol9-sparc-local
The packages are located in /cvs/cds/caltech/apps/solaris/packages. The command line to install
a package is "pkgadd -d " followed by the package name. This can be repeated on nodus to get
svn over there. (Kind of egregious to require an apache installation for the svn _client_, I
||Sun Jun 1 19:39:35 2008
Phil Ehrens gave me a DVD of the 40m elog, apache, and (Jamie's) SVN archive.
I copied it to nodus:/home/controls/dvd-from-ehrens. Once we get the elog
running on nodus, we can copy the datafile over again from dziban (so that
we don't lose any elog entries) and switch over.
||Tue Jun 3 10:19:45 2008
|Several of us transported the big new awesome Sun box from Bridge over to |
the 40m last week. If I recall correctly, it's a SunFire X4600 with
something like sixteen 64-bit AMD processor cores at 2.8 GHz. It sounds
like a jet engine when it starts up (before the cooling fans are throttled
back) and has four power supplies (each with its own connection
to the wall). It has slick removable hard disks and fan units too. Our
working name for it is "megatron".
Anyway. It came with two hard disks, one with Solaris 10 installed. I took
the other hard disk over to Alex, who copied a Realtime Linux installation
onto it. Alex says it boots and runs fine.
It remains for you guys to install the machine onto rails and install the
whole thing into a rack. Before it goes into service as a realtime control
machine, you might as well install Matlab on it and do some heavy-duty
||Tue Jun 3 10:40:27 2008
|Alex let me know the secret location of the latest dataviewer executable for Linux. It is:|
If your linux dataviewer on linux2 has the "year field not filled in" bug, you should download this into /usr/local/bin/dc3 (after making a backup of that file).
It looks like there's no dataviewer installed on rosalba yet. We should figure out a better directory layout for the linux machines; currently dataviewer is installed locally on linux2. It should be in /cvs/cds/caltech/apps/linux/something so that all the linux machines see the same installation.
||Sun Jul 6 16:17:40 2008
I was able to check out the 40m SVN here in Livingston using this command:
svn co svn+ssh://firstname.lastname@example.org/cvs/cds/caltech/svn/trunk/medm
As you might guess, this uses ssh in place of the web server (which we don't have yet).
||Tue Nov 6 14:51:03 2007
||tobin, rob||Update||IOO||Mode cleaner length|
|Using the Ward-Fricke variant* of the Sigg-Frolov method, we found the length of the mode cleaner to be 27.0934020183 meters, a difference of -2.7mm from Andrey,
Keita, and Rana's measurement on August 30th. |
The updated RF frequencies are:
3 fsr = 33 195 439 Hz
12 fsr = 132 781 756 Hz
15 fsr = 165 977 195 Hz
18 fsr = 199 172 634 Hz* We did the usual scheme of connecting a 20mVpp, 2 kHz sinusoid into MC AO. Instead of scanning the RF frequency by turning the dial on the 166 MHz signal generator ("marconi"), we connected a DAC channel into its external modulation port (set to 5000 Hz/volt FM deviation). We then scanned the RF frequency from the control room, minimizing the height of the 2 kHz line in LSC-PD11. In principle one could write a little dither servo to lock onto the 15fsr, but in practice simply cursoring the slider bar around while watching a dtt display worked just fine.
||Fri Jun 4 17:46:25 2021
||unYehonathan||Update||CDS||Opto-isolator for c1auxey|
I mounted the optoisolator on the DIN rail and connected the 3 first channels
to the optoisolator inputs 1,3,4 respectively. I connected the +15V input voltage into the input(+) of the optoisolator.
The outputs were connected to DB9F-2 where those channels were connected before.
I added DB9F-1 to the front panel to accept channels from the RTS. I connected the fast channels to connectors 1,2,3 from DB9F-1 to DB9F-2 according to the wiring diagram. The GND from DB9F-1 was connected to both connector 5 of DB9F-2 and the output (-).
I tested the channels: I connected a DB9 breakout board to DB9F-2. I measured the resistance between the RTS GND and the isolated channels while switching them on and off. In the beginning, when I turned on the binary channels the resistance was behaving weird - oscillating between low resistance and open circuit. I pulled up the channels through a 100Kohm resistor to observe whether the voltage behavior is reasonable or not. Indeed I observed that in the LOW state the voltage between the isolated channel and slow GND is 15V and 0.03V in the HIGH state. Then I disconnected the pull up from the channels and measured the resistance again. It showed ~ stable 170ohm in the HIGH state and an open circuit in the LOW state. I was not able to reproduce the weird initial behavior. Maybe the optoisolator needs some warmup of some sort.
We still need to wire the rest of the fast channels to DBF9-3 and isolate the channels in DBF9-4. For that, we need another optoisolator.
There is still an open issue with the BI channels not read by EPICS. They can still be read by the Windows machine though.
|Attachment 1: 20210604_173420.jpg
||Wed Jun 2 18:36:20 2010
||valera||DAQ||CDS||Noise generators in LSP|
Alex wrote a new code to implement LSP noise generator. The code is based on 64 bit random number generator from Numerical Recipes 3rd ed ch 7.1 (p 343).
Joe made two instances in the LSP model.
The attached plot shows the spectra and coherence of two generators. The incoherence is ~1/Navg - statistically consistent with no coherence.
|Attachment 1: noisegenerators.pdf
||Thu Jun 3 22:33:31 2010
||valera||Summary||CDS||simulated plant work|
I put matlab files and a summary into the 40m wiki for the fitting of the 40m Optickle transfer functions and generating digital filters for the simulated plant:
The filters are not loaded yet. Joe and Alex will make a rcg code to make a matrix of filters (currently 5x15=75 elements) which will enable the simulated plant tf's.
Joe and I tried to put a signal through the DARM loop but the signal was not going through the memory location in the scx part of the simulated plant.
Edit by Joe:
I was able to track it down to the spx model not running properly. It needed the Burt Restore flag set to 1. I hadn't done that since the last rebuild, so it wasn't actually calculating anything until I flipped that flag. The data is now circulating all the way around. If I turn on the final input (the same one with the initial 1.0 offset), the data circulates completely around and starts integrating up. So the loop has been closed, just without all the correct filters in.
||Fri Jun 11 22:09:58 2010
It appears that foton does not like the unstable poles, which we need to model the transfer functions.
But one can try to load the filters into the front end by generating the filter file e.g.:
# MODULES DARM_ASDC
### DARM_ASDC ###
# SAMPLING DARM_ASDC 16384
# DESIGN DARM_ASDC
DARM_ASDC 0 21 6 0 0 darm 1014223594.005454063416 -1.95554205062071 0.94952075557861 0.06176931505784 -0.93823068494216
-2.05077577179611 1.05077843532639 -2.05854170261687 1.05854477394411
-1.85353637553024 0.86042048250739 -1.99996540107622 0.99996542454814
-1.93464836371852 0.94008893626414 -1.89722830906561 0.90024221050918
-2.04422931770060 1.04652211283968 -2.01120153956052 1.01152717233685
-1.99996545575365 0.99996548582538 -1.99996545573320 0.99996548582538
Unfortunately if you open and later save this file with foton it will strip the lhp poles.
||Sun Jun 13 08:28:44 2010
||valera||Update||Locking||40m Upgrade Optickle Model|
In my calculation of the digital filters of the optical transfer functions the carrier light is resonant in coupled cavities and the sidebands are resonant in recycling cavities (provided that macroscopic lengths are chosen correctly which I assumed).
||Sat Sep 11 22:42:07 2010
- The PMC REFL PD was moved from the temporary location to the one called for by the PSL layout (picture attached). The leakage beams were dumped.
- The FSS reference cavity was aligned using temporary periscope and scanned using NPRO temperature sweep. The amplitude of the sweep (sine wave 0.03 Hz) was set such that the PMC control voltage was going about 100 V p-p with. With rough alignment the visibility was as high as 50% - it will be better when the cavity is locked and better aligned but not better than 80% expected from the mode astigmatism that Tara and I measured on Thursday. The astigmatism appear to come from the FSS AOM as it depends on the AOM drive. We reduced the drive control voltage from 5 V to 4V beyond that the diffraction efficiency went below 50%. The FSS REFL PD was set up for this measurement as shown in the attached picture. There is also a camera in transmission not shown in the picture.
|Attachment 1: DSC_2502.JPG
|Attachment 2: DSC_2505.JPG
||Sun Sep 12 23:02:53 2010
||valera||Update|| ||PMC mode matching|
Kiwamu and I found that the first lens in the PMC mode matching telescope was mislabeled. It is supposed to be PLCX-25.4-77.3-C and was labeled as such but in fact it was PLCX-25.4-103.0-C. This is why the PMC mode matching was bad. We swapped the lens for the correct one and got the PMC visibility of 82%. The attached plot shows the beam scans before and after the PMC. The data were taken with the wrong lens. The ABCD model shown in the plot uses the lens that was there at the time - PLCX-25.4-103.0-C. The model for the PMC is just the waist of 0.371 mm at the nominal location. The snap shot of the ABCD file is attached. The calculation includes the KTP for FI and LiNb for EOM with 4 cm length. The distances are as measured on the table.
|Attachment 1: pmc.pdf
|Attachment 2: pmc-abcd.tiff
||Sun Sep 12 23:16:52 2010
||valera||Update|| ||FSS mode matching|
The attached plot shows the beam scans of the beam leaking from the back mirror of the PMC to the BS cube that first turns the S-pol beam 90 deg to the AOM and then transmits the AOM double passed and polarization rotated P-pol beam to the reference cavity. The beam from the PMC is mode matched to the AOM using a single lens f=229 mm. The ABCD file is attached. The data were taken with VCO control voltage at 5 V. We then reduced the voltage to 4 V to reduce the astigmatism. Tara has the data for the beam scan in this configuration in his notebook.
The beam from AOM is mode matched to the reference cavity using a single lens f=286.5 mm. The ABCD file is attached.
|Attachment 1: fss.pdf
|Attachment 2: fssaom-abcd.tiff
|Attachment 3: fssrc-abcd.tiff
||Wed Sep 15 01:58:28 2010
The RefCav is locked and aligned. I changed the fast gain sign by changing the jumper setting on the TTFSS board. The RefCav visibility is 70%. The FSS loop ugf is about 80 kHz (plot attached. there is 10 dB gain in the test point path. this is why the ugf is at 10 dB when measured using in1 and in2 spigots on the front of the board.) with FSS common gain max out at 30 dB. There is about 250 mW coming out of the laser and 1 mW going to RefCav out of the back of the PMC. So the ugf can be made higher at full power. I have not made any changes to account for the PMC pole (the FSS is after the PMC now). The FSS fast gain was also maxed out at 30 dB to account for the factor of 5 smaller PZT actuation coefficient - it used to be 16 dB according to the (previous) snap shot. The RefCav TRANS PD and camera are aligned. I tuned up the phase of the error signal by putting cables in the LO and PD paths. The maximum response of the mixer output to the fast actuator sweep of the fringe was with about 2 feet of extra cable in the PD leg.
I am leaving the FSS unlocked for the night in case it will start oscillating as the phase margin is not good at this ugf.
|Attachment 1: DSC_2510.JPG
||Wed Sep 15 19:29:13 2010
||valera||Summary|| ||PSL power budget|
|| Power (mW)
| NPRO - after HWP
| Rejected by input FI polarizer
| After output FI polarizer
| Into PMC
| PMC reflected
| PMC transmitted
| PMC leakage
| After PMC TRANS PD/Camera BS
| After RefCav EOM
| Into RefCav
- NPRO injection current 1.0 A
- PMC losses ~32%
- FSS AOM diffraction efficiency ~52%
||Fri Sep 17 01:36:14 2010
||valera||Update|| ||PMC line width|
The attached plots show the PMC cavity line width measurement with 1 mW and 160 mW into the PMC. The two curves on each plot are the PMC transmitted power and the ramp of the fast input of the NPRO. The two measurements are consistent within errors - a few %. The PMC line width 3.5 ms (FWHM) x 4 V / 20 ms (slope of the ramp) x 1.1 MHz / V (NPRO fast actuator calibration from Innolight spec sheet) = 0.77 MHz.
Here is the output of the calculation using Malik Rakhmanov code:
modematching = 8.4121e-01
transmission1 = 2.4341e-03
transmission2 = 2.4341e-03
transmission3 = 5.1280e-05
averageLosses = 6.1963e-04
visibility = 7.7439e-01
Here are the inputs for the calculation in the param.m:
fw = 0.77e6; % width of resonance (FWHM) in Hz
Plas = 0.164; % power into the PMC in W
% the following number refer to the in-lock cavity state
Pref = 0.037; % reflected power in W
Ptr = 0.0712; % transmitted power in W
Pleak = 0.0015; % power leaking from back of PMC in W
|Attachment 1: TEK00009.PNG
|Attachment 2: TEK00010.PNG
||Thu Nov 11 18:05:55 2010
||valera||Update||PSL||PMC mode matching at full laser power|
The PMC mode matching was initially done at low power ~150 mW. It was expected and found that at full power ~2 W (injection current 2.1 A) the mode matching got much worse:
the visibility degraded from 80% to 50% (1 - refl locked/refl unlocked) . The thermal lensing could be in the laser, EOM, or FI.
The first attached plot shows the scan of the beam after the EOM at low and full laser power. At full power the waist position is 10 mm after the turning mirror after the EOM and the waist size is 310 um.
The second plot shows the ABCD calculation for the mode matching solution.
I removed the MM lens PLCX-25.4-77.3-C and placed the PLCX-25.4-180.3-UV about 20 mm after the first PMC periscope mirror (the second mirror after the EOM).
The PMC visibility improved to 94% and the power through the PMC, as measured by the PMC transmission PD, went up by a factor of 2.
|Attachment 1: scan.pdf
|Attachment 2: pmc2-abcd.png
||Sat Nov 13 16:57:21 2010
||valera||Configuration||Electronics||PRM Side OSEM transimpedance change|
Now that we have increased the range of the AA to +/- 10 V I have increased the PRM side OSEM transimpedance from 29 kV/A to 161 kV/A by changing the R64 in the satellite box. The first attached plot shows the ADC input spectrum before and after the change with analog whitening turned off. The PD voltage readback went up from 0.75 to 4.2 V. The second attached plot shows the sensor, ADC, and projected shot noise with analog whitening turned on and compensated digitally. The ADC calibration is 20 V/ 32768 cts. The PRM damping loops are currently disabled.
I checked for oscillation by looking at the monitor point at the whitening board. There was no obvious oscillation on a scope - the signal was 20 mV p-p on 1 us scale which was very similar to the LL channel.
|Attachment 1: PRM-SD-ADC.pdf
|Attachment 2: PRM-SD-Current.pdf
||Sun Nov 14 11:56:59 2010
||valera||Update||CDS||Test of ADC noise|
We missed a factor of 2 in the ADC calibration: the differential 16 bit ADC with +/-10 V input has 20 V per 32768 counts (1 bit is for the sign). I confirmed this calibration by directly measuring ADC counts per V.
So the ADC input voltage noise with +/-10V range around 100 Hz is 6.5e-3 cts/rtHz x 20V/32768cts = 4.0 uV/rtHz. Bummer.
The ADC quantization noise limit is 1/sqrt(12 fs/2)=1.6e-3 cts/rtHz. Where the ADC internal sampling frequency is fs=64 kHz. If this would be the limiting digitization noise source then the equivalent ADC input voltage noise would be 1 uV/rtHz with +/-10 V range.
||Tue Nov 16 15:32:18 2010
||valera||Update||Electronics||OSEM noise at the output of the satellite box|
I measured the SRM OSEM (no magnets at the moment) noise out of the satellite box with a SRS785 spectrum analyzer. I inserted a break out board into the cable going from the satellite box to the whitening board. The transimpedances of the SRM OSEMs are still 29.2 kOhm. The DC voltages out of the SRM satellite box are about 1.7 V. The signal was AC coupled using SR560 with two poles at 0.03 Hz and a gain of 10.
The noise is consistent with the one measured by the ADC except for the 3 Hz peak which does not show up in the ADC spectrum from Sunday. The peak appears in several channels I looked at. The instrument noise floor was measured by terminating the SR560 with 50 Ohm.
I recommend to change all OSEM transimpedance gains from 29 to 161 kV/A. Beyond this gain one will rail the AA filter module when the magnet is fully out of the OSEM.
The OSEM noise at 1 Hz is about factor of 10 above the shot noise. The damping loops impress this noise on the optics around the pendulum resonance frequency. Also the total contribution to the MC cavity length is sqrt(12) time the single sensor as there are 12 OSEMs contributing to MC length. The ADC noise is currently close but never the less not limiting the OSEM noise below 100 Hz. It can be further reduced by getting an extra factor of 2-3 in whitening gain above ~0.3 Hz. The rms of the ADC input of the modified PRM SD (R64 = 161 kOhm) channel is 10-20 cts during the day with damping loop off and whitening on.
The transimpedance amplifier LT1125CS is also not supposed to be limiting the noise. At 1 Hz the 1/f part of the noise: In<1pA/rtHz and Vn<20nV/rtHz.
|Attachment 1: osemnoise.pdf
||Tue Feb 22 00:18:47 2011
||valera||Configuration|| ||c1ioo and c1ass work and related fb crashes/restarts|
I have been editing and reloading the c1ioo model last two days. I have restarted the frame builder several times. After one of the restarts on Sunday evening the fb started having problems which initially showed up as dtt reporting synchronization error. This morning Kiwamu and I tried to restart the fb again and it stopped working all together. We called Joe and he fixed the fb problem by fixing the time stamps (Joe will add details to describe the fix when he sees this elog).
The following changes were made to c1ioo model:
- The angular dither lockins were added for each optics to do the beam spot centering on MC mirrors. The MCL signal is demodulated digitally at 3 pitch and 3 yaw frequencies. (The MCL signal was reconnected to the first input of the ADC interface board).
- The outputs of the lockins go through the sensing matrix, DOF filters, and control matrix to the MC1,2,3 SUS-MC1(2,3)_ASCPIT(YAW) filter inputs where they sum with dither signals (CLOCK output of the oscillators).
- The MCL_TEST_FILT was removed
The arm cavity dither alignment (c1ass) status:
- The demodulated signals were minimized by moving the ETMX/ITMX optic biases and simultaneously keeping the arm buildup (TRX) high by using the BS and PZT2. The minimization of the TRX demodulated signals has not been successful for some reason.
- The next step is to close the servo loops REFL11I demodulated signals -> TMs and TRX demodulated signals -> combination of BS and PZTs.
The MC dither alignment (c1ioo) status:
- The demodulated signals were obtained and sensing matrix (MCs -> lockin outputs) was measured for pitch dof.
- The inversion of the matrix is in progress.
- The additional c1ass and c1ioo medm screens and up and down scripts are being made.
||Tue Feb 22 23:11:42 2011
||valera||Update|| ||new medm screens: C1ASS.adl and C1MCASS.adl|
|Attachment 1: C1MCASS.jpeg
|Attachment 2: C1ASS.jpeg