ID |
Date |
Author |
Type |
Category |
Subject |
13053
|
Thu Jun 8 12:43:42 2017 |
Dhruva | Update | Optical Levers | Beam Profiling Results |
Quote: |
Updates in the He-Ne beam profiling experiment.
|
New and improved plots for the He-Ne profiling experiment
Font size has been increased to 30.
The plots are maximum size (Following Rana's advice, I saved the plots as eps files(maximized) and converted them to pdf later).
There is a shaded region around the trendline that represents the parameter error.
Function that I fit my data to (should have mentioned this in my earlier elog entries)
![P = \dfrac{P_0}{2}\Bigg[1+erf\Big(\dfrac{\sqrt2(X-X_0)}{w}\Big) \Bigg]](https://latex.codecogs.com/gif.latex?P%20%3D%20%5Cdfrac%7BP_0%7D%7B2%7D%5CBigg%5B1+erf%5CBig%28%5Cdfrac%7B%5Csqrt2%28X-X_0%29%7D%7Bw%7D%5CBig%29%20%5CBigg%5D)
Description of my error analysis -
1. I have assumed a 20% deviation from markings in the micrometer error.
2. Using the error in the micrometer, I have calculated the propogated error in the beam power :

I added this error to the stastistical error due to the fluctuation of the oscilloscope reading to obtain the total error in power.
3. I found the Fisher Matrix by numerically differentiating the function at different data points with respect to the parameters and .
 
I then found the covariance matrix by inverting the Fisher Matrix and found the error in spot size estimation.
EDIT : Residuals added to plots and all axes made equal |
229
|
Wed Jan 9 20:29:47 2008 |
Dmass | AoG | TMI | Coffee Carafe | If you have been using the coffee machine in the 40m, you may have noticed small brown flecks in your coffee mug. The carafe in the 40m has accumulated a layer of what is presumed to be old dried up coffee. When a small amount of water is swirled around in the bottom, flecks of the brown layer come off. Pictures below are of the inside of the carafe.
But does it provide adequate protection from 1064 light? |
279
|
Mon Jan 28 12:42:48 2008 |
Dmass | Bureaucracy | TMI | Coffee | There is tea in the coffee carafe @ the 40m. It is sitting as though it were fresh coffee. There is also nothing on the post it. |
382
|
Fri Mar 14 16:56:03 2008 |
Dmass | Bureaucracy | Computers | New 40m control machine. | I priced out a new control machine from Dell and had Steve buy it.
GigE cards (jumbo packet capable) will be coming seperately.
Specs:
Quad core (2+GHz)
4 Gigs @ 800MHz RAM
24" LCD
low end video card (Nvidia 8300 - analog + digital output for dual head config)
No floppy drive on this one (yet?) |
792
|
Mon Aug 4 16:20:20 2008 |
Dmass | Configuration | Photos | ITMX magnet position relative to OSEMS | We have vented, and taken the following pics of the magnets to document their position before we ruin everything. |
1589
|
Fri May 15 14:05:14 2009 |
Dmass | HowTo | Computers | How To: Crash the Elog | The Elog started crashing last night. It turns out I was the culprit, and whenever I tried to upload a certain 500kb .png picture, it would die. It has happened both when choosing "upload" of a picture, and when choosing "submit" after successfully uploading a picture. Both culprits were ~500kb .png files. |
1724
|
Wed Jul 8 18:46:56 2009 |
Dmass | AoG | Electronics | Beam Scan Funky | The beam scan (which has been living in the bridge subbasement for a bit now) is in a state of imperfection.
I noticed that:
- The waist reading seems to change by not insignificant amounts as you move the spot across the head, even for just small perturbations about the center.
- None of the features which require two slits seem to be working (unsure if this is software or hardware related)
I took some pictures to try and illuminate the situation - The inverted images are included to make it easier to see the flecks (?) in the slits
I am not sure how to figure out if any bit of the scan is/has been fried.
Pending further investigation, enjoy large error bars in your scan measurements!
PICTURES OF BOTH SLITS ON THE BEAMSCAN HEAD: |
1766
|
Tue Jul 21 01:11:30 2009 |
Dmass | AoG | Computers | Alarms going off | I came into the 40m to sign things out briefly then swiftly return them, and the alarms were going off on op540m at 1am.
The cat and donkey? were making much noise. |
3118
|
Fri Jun 25 01:28:33 2010 |
Dmass | HowTo | SVN | SVN woes | I am trying to get an actual complete install of the 40m svn on my machine. It keeps stopping at the same point:
I do a
svn checkout --username svn40m https://nodus.ligo.caltech.edu:30889/svn /Users/dmass/svn
A blah blah blah many files
...
A /Users/dmass/svn/trunk/medm/c1/lsc/C1LSC_ComMode.adl.28oct06
svn: In directory '/Users/dmass/svn/trunk/medm/c1/lsc'
svn: Can't copy '/Users/dmass/svn/trunk/medm/c1/lsc/.svn/tmp/text-base/C1LSC_MENU.adl.svn-base' to '/Users/dmass/svn/trunk/medm/c1/lsc/.svn/tmp/C1LSC_MENU.adl.tmp.tmp': No such file or directory
I believe I have always had this error come up when trying to do a full svn install. Any illumination is welcome.
|
3194
|
Mon Jul 12 12:16:50 2010 |
Dmass | HowTo | COMSOL Tips | Intrusions (Negative Extrusions) | An entry on the 40m wiki page might serve you better, and be easier to sift through once all is said and done |
3204
|
Tue Jul 13 11:20:07 2010 |
Dmass | Update | Green Locking | SHG on PSL table : optimum temeprature |
It seems like you might inherit an offset by using step (3) b/c of the temperature gradient between the crystal and the sensing point. Depending on how large this gradient is you could increase the linear coupling from temperature to intensity noise from zero to a significant number. Phase noise should not be effected.
SInce these things (ovens) are so low time constant, shouldn't we
- Lock to a temperature
- Let the oven equilibrate for however long - a few tau maybe - my oven has a time constant of 60 sec, don't know if this is fast or slow compared to that
- Measure P_532/P_1064
- Change the setpoint
- Go back to step 1
|
3225
|
Wed Jul 14 20:15:04 2010 |
Dmass | Bureaucracy | Cameras | IR Olympus | I borrowed the Olympus and forgot to leave a note - I should have it for at most a day. dmassey@ligo if you need it urgently |
3262
|
Wed Jul 21 19:11:18 2010 |
Dmass | Update | Green Locking | locked | What did you use to filter the 2f components from your error signal? A homemade low pass or what?
Kiwamu:
I am using a homemade low pass filter.
It's just a RC passive LPF with the input impedance of 50 Ohm. |
3325
|
Thu Jul 29 21:13:39 2010 |
Dmass | Update | Green Locking | waist positon of Gaussian beam in PPKTP crystals |
Quote: |
The mode profile of Gaussian beams in our PPKTP crystals was calculated.
I confirmed that the Rayleigh range of the incoming beam (1064 nm) and that of the outgoing beam (532 nm) is the same.
And it turned out that the waist postion for the incoming beam and the outgoing beam should be different by 13.4 mm toward the direction of propagation.
These facts will help us making optical layouts precisely for our green locking.
(detail)
The result is shown in the attached figure, which is essentially the same as the previous one (see the entry).
The horizontal axis is the length of the propagation direction, the vertical axis is the waist size of Gaussian beams.
Here I put x=0 as the entering surface of the crystal, and x=30 mm as the other surface.
The red and green solid curve represent the incoming beam and the outgoing beam respectively. They are supposed to propagate in free space.
And the dashed curve represents the beams inside the crystal.
A trick in this calculation is that: we can assume that the waist size of 532 nm is equal to that of 1064 nm divided by sqrt(2) .
If you want to know about this treatment in detail, you can find some descriptions in this paper;
"Third-harmonic generation by use of focused Gaussian beams in an optical super lattice" J.Opt.Soc.Am.B 20,360 (2003)"
|
If I understand your elog, you are just calculating the the offset in position space that you get by having a refractive index.
Did you end up changing the mode matching so that the rayleigh range (which changes with refractive index) was confocally focused inside the crystal (e.g. Zr = 15 mm?
|
3328
|
Fri Jul 30 00:02:15 2010 |
Dmass | Update | Green Locking | waist positon of Gaussian beam in PPKTP crystals |
Quote: |
- As you said, I just calculated the waist position in the crystal because the speed of light changes in a medium and eventually the waist position also changes.
- Yes, I did. Once you get a beam with the right waist size, you just put your crystal at the waist position with the offset.
In fact you don't have to think about the rayleigh range inside of the crystal because what we care is the waist size and it doesn't change.
Quote: |
If I understand your elog, you are just calculating the the offset in position space that you get by having a refractive index.
Did you end up changing the mode matching so that the rayleigh range (which changes with refractive index) was confocally focused inside the crystal (e.g. Zr = 15 mm?
|
|
I thought we cared about satisfying the confocal focusing parameter, that is to say we want to set Zr = 2L_crystal. If Zr changes inside the crystal, this is the number we care about..isn't it NOT the waist size, but the rayleigh range we care about? I am not entirely sure what youre response is saying you did...
- Calculate Zr = pi * wo^2/(lamba/n)
- Do mode matching to get this wo in free space
- Calculate the offset you need to move the oven by using n
- Move hte ovens
OR
- Calculate Zr = pi*wo^2/(lamba)
- Do mode matching to get this in free space
- Calculate the offset you need to move your ovens using n
- Move your ovens
I guess the waist size would also let me know - are you using 69 um or 53 um waist size? |
3384
|
Sat Aug 7 21:09:59 2010 |
Dmass | Configuration | Computer Scripts / Programs | eLog changes | I made some changes to the elog on nodus:
- Made a backup of /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg called elogd.cfg.bk.20100407 in the same directory
- Added a folder: /cvs/cds/caltech/elog/elog-2.7.5/logbooks/EAGER_Lab
- Restarted the elog daemon via the start-elog-nodus script in the elog-2.7.5 directory
I saw that the current version of the elog seems to be in the svn, so tried to svn the changes from nodus via ssh, but got this message:
"svn: This client is too old to work with working copy '/cvs/cds/caltech/elog/elog-2.7.5'; please get a newer Subversion client."
I feel I should svn this but don't want to *&#@ the svn/elog up.
For now I will leave it alone and ask a question: Is the folder /cvs/cds/caltech/elog/elog-2.7.5/ under SVN control? Is it also under CVS control?
TL;DR: New tab added to elog.
|
3420
|
Fri Aug 13 13:11:30 2010 |
Dmass | Update | elog | restarted |
Quote: |
More of the same.
Who is putting weird figures into the elog?!?! I haven't checked lately, but this is what usually crashes the elog. It's been happening a lot lately, and it might be the .pdf's.
Let's play a new game. We'll call this game "Everyone only use .png files for the next week" Ready? GO!
|
Do we know what causes the crashes for definite? Let's give the whole knowledge gathering a shot. Surfs welcome to post. Please follow the format and keep it brief. P.S. if the elog stops responding or hangs while you're trying to edit a post or write a post, you may have crashed it.
Person
Dmass
- I have crashed the elog with downsized jpegs (~300-900kB).
- I see jpegs on the front page of the 40m (which seem to have not crashed it?)
- I have posted pdf's with and without png thumbnails (associated automatically via the Mac program preview) without problem.
Edit this post to add your own experience using the above format |
3533
|
Tue Sep 7 14:42:02 2010 |
Dmass | Configuration | elog | elog restarted | elog crashed on an upload. restarted and it worked fine with the same file. |
3538
|
Tue Sep 7 22:21:47 2010 |
Dmass | Configuration | elog | elog restarted |
Quote: |
elog crashed on an upload. restarted and it worked fine with the same file.
|
Again. Resubmitted an old entry with just text changes. Elog hung for 5 min +. |
3740
|
Tue Oct 19 00:24:07 2010 |
Dmass | Omnistructure | Electronics | Massive restocking of the 40m | I had a number of delinquent items on the sign out list from the 40m. I returned about half, and ordered replacements for most of the other half.
I put the photodiodes on the SP table, and the 560 on the electronics bench. |
5217
|
Fri Aug 12 20:33:57 2011 |
Dmass | Summary | PSL | NPRO PDH-Locked to Ref Cav | To aid Jenny's valiant attempt to finish her SURF project, I did some things with the front end system over the last couple days, largely tricking Jamie into doing things for me lest I ruin the 40m RCG system. Several tribulations have been omitted.
We stole a channel in the frontend, in the proccess:
- Modified the C1GFD simulink model (now analog) to be "ADC -> TMP -> DAC" where TMP is a filter bank
- C1GFD_TMP.adl (in /opt/rtcds/caltech/c1/medm/c1gfd) is the relevant part which connects the ADC to the DAC in the frontend
- Confirmed that the ADC was working by putting a signal in and seeing it in the frontend
- Could not get a signal out of the anti aliasing board
- Looked sad until Kiwamu found a breakout board for the SCSI cable coming from the DAC
- Used SR560 to buffer DAC output
- drove a triangle wave with AWG into the TMP EXC channel (100 counts 1 Hz) and looked at it after the ~25 ft of BNC cable running between the DAC and the NRPO driver
- wave looked funny (not like a triangle wave), maybe the DAC is not meant to push a signal so far, so added buffer
- Took the control signal going to the fast input of the NPRO driver (using the 500 Ohm SR560 output - see Jenny's diagram) and put it into the anti aliasing board of the ADC
- Added switchable integrator to filter bank with Foton
- I couldn't get the names to display in the filter bank, so I looked sad again
- Jamie and Koji both poked at the "no name displayed" problem but had no conclusions, so I decided to ignore it
- I confirm that when the two filters were toggled "on" that the transfer function was as expected: simple integrator with a unity gain at ~10mHz - agrees with what Foton's Bode Plot tool says it should be (see attached DTT plot)
- I got Jamie to manually add the two epics channels from the TMP model to the appropriate .ini file so they would be recorded
- C1:GFD-TMP_OUTPUT (16 Hz)
- C1:GFD-TMP_INMON (16 Hz)
- RefCav heater servo seems to still be set up, so we can use existing channels:
- C1:PSL-FSS_RCPID_SETPOINT (temp setpoint - will do +/-1C steps about 35 C)
- C1:PSL-FSS_MINCOMEAS (In loop temp sensor - in C)
- C1:PSL-FSS_RCTEMP (out of loop temp sensor - in C)
- C1:PSL-FSS_TIDALSET (Voltage to heater - rails @ +/- 2V)
- Closed loop on the control signal for the NPRO driver with an integrator, saw error signal go to zero
- Turned up gain a little bit, saw some oscillations, then turned gain down to stop them, final gain = 2
- Left system on for Jenny to come in and do step responses
|
5304
|
Thu Aug 25 17:40:07 2011 |
Dmass | Update | Computer Scripts / Programs | elog broke, fixed | elog died b/c someone somewhere did something which may or may not have been innocuous. I ran the script in /cvs/cds/caltech/elog to restart the elog (thrice).
I have now banned Warren from clicking on the elog from home |
5340
|
Mon Sep 5 21:12:05 2011 |
Dmass | Update | Computer Scripts / Programs | elog broke, fixed | Restarted elog 9:11PM 9/5/11 |
5739
|
Tue Oct 25 21:23:17 2011 |
Dmass | Bureaucracy | elog | Elog Restarted | Elog went nonreponsive. SSH'ed into nodus to run restart script. Elog came back ~15 minutes later. |
9335
|
Mon Nov 4 12:07:55 2013 |
Dmass | Omnistructure | General | Replaced Broken Drill Bits | I broke a small bit while using the 40m drill press to vent some 1/4-20 screws for the cryo experiment.
I replaced it and refilled the small bit row in the bit index I was using; there were ~10 missing sizes |
5823
|
Sun Nov 6 09:39:25 2011 |
Dr. SUS | Update | SUS | Optics kicked | All suspended optics have been kicked at Sun Nov 6 09:39:25 PST 2011. Watchdogs will be reengaged in 5 hours. Please refrain from disturbing the optics in the meantime.
EDIT ZK: After all that, I left the 'doirun' bit off in runDrSUS. I ran it manually at the above time. |
11241
|
Thu Apr 23 23:07:23 2015 |
Dugolini | Frogs | ALARM | laptops warning | Please!

Don't put laptops on the ISC Tables! |
7711
|
Wed Nov 14 09:01:42 2012 |
Dumb statement catcher | Update | IOO | Turn off MCL path before doing MC spot measurement |
Quote: |
We have discovered that the MCL loop squishes the length fluctuations that result from the MC spot measurement angular dither. This is good, in that the MCL is doing what it ought to do. However, we need to turn it off before doing a spot measurement.
|
This is totally non-sensical statement, of course.
We might also say that the DARM loop totally squishes the GW signal and so its better not to have any feedback in the interferometer. |
6686
|
Fri May 25 19:13:10 2012 |
Duncan Macleod | Summary | Computer Scripts / Programs | 40m summary webpages | 40m summary webpages
The aLIGO-style summary webpages are now running on 40m data! They are running on megatron so can be viewed from within the martian network at:
http://192.168.113.209/~controls/summary
At the moment I have configured the 5 seismic BLRMS bands, and a random set of PSL channels taken from a strip tool.
Technical notes
- The code is in python depending heavily on the LSCSoft PyLAL and GLUE modules.
- /home/controls/public_html/summary/bin/summary_page.py
- The HTML is supported by a CSS script and a JS script which are held locally in the run directory, and JQuery linked from the google repo.
- /home/controls/public_html/summary/summary_page.css
- /home/controls/public_html/summary/pylaldq.js
- The configuration is controlled via a single INI format file
- /home/controls/public_html/summary/share/c1_summary_page.ini
Getting frames
Since there are no segments or triggers for C1, the only data sources are GWF frames. These are mounted from the framebuilder under /frames on megatron. There is a python script that takes in a pair of GPS times and a frame type that will locate the frames for you. This is how you use it to find T type frames (second trends) for May 25 2012:
python /home/controls/public_html/summary/bin/framecache.py --ifo C1 --gps-start-time 1021939215 --gps-end-time 1022025615 --type T -o framecache.lcf
If you don't have GPS times, you can use the tconvert tool to generate them
$ tconvert May 25
1021939215
The available frame types, as far as I'm aware are R (raw), T (seconds trends), and M (minute trends).
Running the code
The code is designed to be fairly easy to use, with most of the options set in the ini file. The code has three modes - day, month, or GPS start-stop pair. The month mode is a little sketchy so don't expect too much from it. To run in day mode:
python /home/controls/public_html/summary/bin/summary_page.py --ifo C1 --config-file /home/controls/public_html/summary/share/c1_summary_page.ini --output-dir . --verbose --data-cache framecache.lcf -SRQDUTAZBVCXH --day 20120525
Please forgive the large apparently arbitrary collection of letters, since the 40m doesn't use segments or triggers, these options disable processing of these elements, and there are quite a few of them. They correspond to --skip-something options in long form. To see all the options, run
python /home/controls/public_html/summary/bin/summary_page.py --help
There is also a convenient shell script that will run over today's data in day mode, doing everything for you. This will run framecache.py to find the frames, then run summary_page.py to generate the results in the correct output directory. To use this, run
bash /home/controls/public_html/summary/bin/c1_summary_page.sh
Configuration
Different data tabs are disabled via command link --skip-this-tab style options, but the content of tabs is controlled via the ini file. I'll try to give an overview of how to use these. The only configuration required for the Seismic BLRMS 0.1-0.3 Hz tab is the following section:
[data-Seismic 0.1-0.3 Hz]
channels = C1:PEM-RMS_STS1X_0p1_0p3,C1:PEM-RMS_STS1Y_0p1_0p3,C1:PEM-RMS_STS1Z_0p1_0p3
labels = STS1X,STS1Y,STS1Z
frame-type = R
plot-dataplot1 =
plot-dataplot3 =
amplitude-log = True
amplitude-lim = 1,500
amplitude-label = BLRMS motion ($\mu$m/s)
The entries can be explained as follows:
- '[data-Seismic 0.1-0.3 Hz] - This is the section heading. The 'data-' mark identifies this as data, and is a relic of how the code is written, the 'Seismic 0.1-0.3 Hz' part is the name of the tab to be displayed in the output.
- 'channels = ...' - This is a comma-separated list of channels as they are named in the frames. These must be exact so the code knows how to find them.
- 'labels = STS1X,STS1Y,STS1Z' - This is a comma-separated list of labels mapping channel names to something more readable for the plots, this is optional.
- 'frame-type = R' - This tells the code what frame type the channels are, so it can determine from which frames to read them, this is not optional, I think.
- 'plot-dataplotX' - This tells the code I want to run dataplotX for this tab. Each 'dataplot' is defined in it's own section, and if none of these options are given, the code tries to use all of them. In this configuration 'plot-dataplot1' tells the code I want to display the time-series of data for this tab.
- 'amplitude-XXX = YYY' - This gives the plotter specific information about this tab that overrides the defaults defined in the dataplotX section. The options in this example tell the plotter that when plotting amplitude on any plot, that axis should be log-scale, with a limit of 1-500 and with a specific label. The possible plotting configurations for this style of option are: 'lim', 'log', 'label', I think.
Other compatible options not used in this example are:
- scale = X,Y,Z - a comma-separated list of scale factors to apply to the data. This can either be a single entry for all channels, or one per channel, nothing in between.
- offset = X,Y,Z - another comma-separate list of DC offsets to apply to the data (before scaling, by default). DAQ noise may mean a channel that should read zero during quick times is offset by some fixed amount, so you can correct that here. Again either one for all channels, or one per channel.
- transform = lambda x: f(x) - a python format lambda function. This is basically any mathematical function that can be applied to each data sample. By default the code constructs the function 'lambda d: scale * (d-offset)', i.e. it calibrates the data by removing the offset an applying the scale.
- band = fmin, fmax - a low,high pair of frequencies within which to bandpass the data. Sketchy at best...
- ripple_db = X - the ripple in the stopband of the bandpass filter
- width = X - the width in the passband of the bandpass filter
- rms_average = X - number of seconds in a single RMS average (combine with band to make BLRMS)
- spectrum-segment-length = X - the length of FFT to use when calculating the spectrum, as a number of samples
- spectrum-overlap = X - the overlap (samples) between neighbouring FFTs when calculating the spectrum
- spectrum-time-step = X - the length (seconds) of a single median-mean average for the spectrogram
At the moment a package version issue means the spectrogram doesn't work, but the spectrum should. At the time of writing, to use the spectrum simple add 'plot-dataplot2'.
You can view the configuration file within the webpage via the 'About' link off any page.
Please e-mail any suggestions/complaints/praise to duncan.macleod@ligo.org. |
6687
|
Fri May 25 20:45:25 2012 |
Duncan Macleod | Summary | Computer Scripts / Programs | 40m summary webpages | There is now a job in the crontab that will run the shell wrapper every hour, so the pages _should_ take care of themselves. If you make adjustments to the configuration file they will get picked up on the hour, or you can just run the script by hand at any time.
$ crontab -l
# m h dom mon dow command
0 */1 * * * bash /home/controls/public_html/summary/bin/c1_summary_page.sh > /dev/null 2>&1
|
14822
|
Thu Aug 1 13:55:34 2019 |
Duo | Bureaucracy | Equipment loan | Gpib module taken to QIL lab | vanna --> QIL.
gautam 20190804: The GPIB module + power supply were returned to me by Duo ~5pm today at the 40m. |
7320
|
Thu Aug 30 18:01:05 2012 |
Elli | Update | IOO | Setting up Input MC cavity scan measurement | Riju, Elli
Today tried to take our first cavity scan. We unplugged the 55MHz sideband input from the RF combiner on the PSL table, and connected a network analyser instead. Using the network analyzer we injected a 12dBm signal (swept from 32MHz to 45MHz) through the RF combiner into the EOM to create our swept sidebands. We measured the MC cavity response by looking at the signal comming out of the RF photodiode on the MC2 table. I replaced the BNC cable connected to the RF PD with a longer BNC cable that could reach our network analyzer next to the PSL table. Riju will post a diagram of our setup.
We didn't see the expected carrier resonances when we performed a cavity scan. The light incident on the RF PD is around 0.7micro Watts and we are still thinking about whether this is strong enough to see our signal above the noise. We also want to work out what the strength of our swept sidebands is. We will attempt to do a 'real' cavity scan tomorrow.
|
7328
|
Fri Aug 31 13:22:29 2012 |
Elli | Update | IOO | Correcting improper termination of the 55MHz input to the EOM | Koji, Riju, Elli
This morning Koji discovered that the 55MHz input into the RF combiner that I disconnected yesterday wasn't terminated properly, so it was reflecting power back into the amplifier in the signal generation unit. We turned off the signal generation unit and checked that the amplifier was still working properly- it was. A 50 ohm terminator was attached to the end of the 55MHz cable so that it is now terminated properly.
When we tried to turn the signal generator box back on we discovered the switch is broken (the box will only stay on while you hold down the on switch) and will need to be replaced. In order to create the 29.5MHz sidebands to lock the mode cleaner, we bypassed the signal generation unit which won't stay on (unplugging '29.5 MHZ out' cable from the frequency generation unit), and instead sent a 0.39V 29.5MHz signal from a function generatior into 'RF input' on the 'RF AM Stabiliser' board.
We also increased the power coming exiting the PSL table and going into the cavity from 11 microwatts to 20 microwatts by adjusting the polariser at the end of the table slightly. The power has been set to 20 microwatts using the polariser a few days ago but had drifted down since then. |
7311
|
Wed Aug 29 19:28:41 2012 |
Elli King | Update | LSC | Setup for a cavity scan or the input mode cleaner | Riju, Elli
Today we prepared our experimental setup to take a cavity scan of the input mode cleaner, which we want to measure in the next day or so. Attached is a diagram of our setup.
What we want to do is to inject a set of sidebands into the PSL and sweep their frequency from 32-45 MHz (a range just over one fsr of the mode cleaner- vfsr=11MHz). We will measure the power transmitted out of the MC using a photo-diode and demodulate this signal with our input signal from the Marconi. From this we should be able to see the resonant frequencies of the carrier and the higher order modes.
One aspect we spent some time thinking about; whether we would be able to inject a signal into an EOM given the EOM and the Marconi are not perfectly impedance matched. Based on Kiwamu’s previous e-log entries designing the EOM, we decided that injecting a signal in 32-45 MHz region at 15dBm is similar to injecting the 29.5MHz sideband (at the same power level with very similar input impedance.) Fingers crossed we don’t blow anything up first week on the job. |
10227
|
Thu Jul 17 16:07:34 2014 |
Emily | Update | Electronics | VCO Driver | I took back he VCO driver that Reetika brought over to the 40m from the PSL lab. |
566
|
Wed Jun 25 12:25:28 2008 |
Eric | Summary | Cameras | 2D Gaussian Fitting Code | I initially wrote a script in MATLAB that takes pictures of the laser beam's profile and fits them to a two dimensional gaussian in order to determine the position and width of the beam. This code is now (mostly) ported to C so that it can be imbedded in the camera software package that Joe is writing. The fitting works fairly well for pictures with the beam directly incident on the camera, and less well for pictures of scatter off the end mirrors of the arms, since scatter from defects in the mirror have intensities much greater than the intensity of the beam's gaussian profile.
The next steps are to finish up porting the fitting code to C, and then modify it so it can better handle the images off the end mirror. Some thoughts on how to do this are to use a fourier transform and a low pass filter, or to simply use a center-of-mass calculation (with the defect peaks reduced in intensity), since position is more important than beam width in this calculation. The eventual goal is to include the edge of the optic in the picture and use the fit of the beam position in comparison to the optic's position to find the beam's location on the mirror. |
622
|
Wed Jul 2 10:35:02 2008 |
Eric | Summary | Cameras | General Summary | I finished up the 2D Gaussian fitting code, and, along with Joe, integrated into the Snap software so that it automatically does a fit to every 100th image. While the fitting works, it is too slow for use in any feedback to the servos. I put together a center of mass calculation to use instead that is somewhat less accurate but much faster (almost instantaneous versus 5-10 seconds). This has yet to be added to the Snap software, but doing so would not be difficult.
I put together a different fitting function for fitting the multiple lorentzian resonance peaks in a power spectrum that would result from sweeping the length of any of the mode cleaners. This simply doesn't work. I tested it on some of Josh Weiner's data collected on the OMC last year, and the data fits poorly. Attempting to fit it all at once requires fitting 80000 data points with 37 free parameters (12 peaks at 3 parameters per peak and 1 offset parameter), which cannot be done in any reasonable time period. Attempting to fit to one specific peak doesn't work due to the corruption of the other nearby peaks, even though they are comparatively small. The fit places the offset incorrectly if given the opportunity (green line in attemptedSinglePeakFitWithoutOffset.tiff and attemptedSinglePeakFitWithoutOffsetZoomed.tiff). Removing this as a parameter causes the fit to do a much better job (red line in these two graphs). The fit still places the peak 0.01 to the right of the actual peak, which worse than could simply be obtained by looking at the maximum point value. Additionally, this slight shift means that attempting to subtract out the peak so that the other peaks are accessible doesn't work -- the peaks are so steep that the error of 0.01 is enough to cause significant problems (red in attemptedPeakSubtraction.tiff is the attempted subtraction). Part of the problem is that the peaks are far from perfect lorentzians, as seen by cropping to any particular peak (OMCSweepSinglePeak.tiff ). This might be corrected in part by correcting for the conversion from PZT voltage to position, which isn't perfectly linear; though I doubt it would remove all the irregularities. At the moment, the best approach seems to be simply using a center of mass calculation cropped to the particular peak, though I have yet to try this.
Changing Josh's code to work for the digital cameras and the PMC or MC shouldn't be difficult. Changing to the MC or PMC should simply involve changing the EPICs tags for the OMC photodiodes and PZTs to those of the PMC or MC. Making the code work for the digital cameras should be as simple as redirecting the call to the framegrabber software to the Snap software. |
660
|
Fri Jul 11 20:16:01 2008 |
Eric | DAQ | Cameras | Taking data from the GC 750 Camera | Mafalda has been set up with a background process to constantly take data from the GC 750 camera (at the end of the x-arm) for the weekend. This camera will otherwise be inoperable until then.
In the small chance that this slows either Mafalda or the network to a crawl, the process to kill should have PID 26265. |
671
|
Tue Jul 15 10:09:42 2008 |
Eric | DAQ | Cameras | Did anyone kill the picture taking process on Mafalda? | Did anyone kill the process on Mafalda that was taking pictures of the end mirror of the x-arm last Friday? I need to know whether or not it crashed of its own accord. |
678
|
Wed Jul 16 10:50:55 2008 |
Eric | Summary | Cameras | Weekly Summary | Finished unwrapping, cleaning, baking, wrapping, wrapping again, packing, and shipping the baffles.
Attempted to set up the Snap software so that it could talk directly to EPICS channels. This is not currently working due to a series of very strange bugs in compiling and linking the channel access libraries. Alex Ivanov directed Joe and me to a script and makefile that are similar to what we're trying to do and it may solve our problem, but at the moment this still doesn't work. We're currently using a workaround that involves making unix system calls to ezca command line tools, but this is too hacky to leave in the final program.
Attempted to fit Josh's PZT voltage vs power plot of the OMC (from about a year ago) to lorentzians in order to try to develop fitting tools for more recent data. This isn't working, due to systematic error distorting the shapes of the peaks. Good fits can be obtained by cutting the number of points to a very small number around the peak of resonance, but this leads to such a small percentage of the peak being used that I don't trust these results either. (In the graph (shows the very top of the tallest peak): blue is Josh's original data, green is a fit to this peak using the top 66% of the peak and arbitrary, equal values for the error on each point, red is Josh's data averaged over bins of size 0.005, teal is a fit to these bins where the error on each point is the standard deviation of each bin, and magenta is a fit to these same bins, except cropped to the top ~10% of the peak, x-axis is voltage, y-axis is transmission power). Rana suggested that I take my own sweeps of the PMC using scripts that are already written: I'm currently figuring out where these scripts are and how to use them without accidently breaking something.
We've begun running the Snap software for long periods of time to see how stable it is. Currently, its only problem appears to be that it memory leaks somewhat: it was up 78% memory usage after a little over an hour. It doesn't put much strain on the computer, using only ~20% CPU. Stress put on the network from the constant transfer of images from the camera to the computer is not yet known. |
689
|
Thu Jul 17 12:15:21 2008 |
Eric | Update | PSL | Swept PMC PZT voltage range | I unlocked the PMC and swept over C1:PSL-PMC_RAMP's full range a couple of times this morning. The PMC should now be relocked and returned
to normal. |
722
|
Wed Jul 23 12:42:23 2008 |
Eric | Summary | Cameras | Weekly Summary | I finally got the ezcaPut command working. The camera code can now talk directly to the EPICS channels. However, after repeated calls of the ezcaPut function, the function begins claim to time out, even though it continues to write values to the channel successfully (EPICS is successfully getting the new value for the channel, but failing to reply back to the program in time, I think). It has seg-faulted once as well, so the stability cannot yet be trusted for running long term. For now, however, it works well enough to test a servo in the short term. The current approach simply uses a terminal running ezcaservo with the pitch and yaw offset channels of the ETMX, as well as the channels that the camera code output to. This hasn't actually been tested since we haven't had enough time with the x-arm locked.
Tested various fixed zoom lens on the camera, since the one we were previously using was too heavy for its mount and likely more expensive than necessary. The 16mm lens gets a good picture of the beam and the optic together, though the beam is a little too small in the picture to reliably fit a gaussian to. The 24mm lens zooms too much to see the whole optic, but the beam profile itself is much clearer. The 24mm lens is currently on the camera.
Scanned the PZT voltage of the PMC across its full offset range to gain a plot of voltage vs intensity. I used DTT's triggered time series response system to measure the outputs of the slow PZT voltage and transmission intensity channels, and used the script triangle wave to drive the PZT ramp channel slowly over its full range (I couldn't get DTT to output to the channel). Clear resonances did appear (PMCScanWide.tif), but the number of data points per peak was far too small reliably fit a lorentzian to (PMCScanSinglePeak.tif). When I decreased the scanning range and increased the time in order to collect a large number of points on a few peaks, the resulting data was too messy to fit to a lorentzian (PMCSlowSinglePeak.tif). |
769
|
Wed Jul 30 13:52:41 2008 |
Eric | Summary | Cameras | Weekly Summary | I tracked the tendency for ezcaPut to fail and sometimes seg-fault in the camera code to a conflict between the camera API and ezca, either on the
network level or the thread level. Since neither are sophisticated enough to provide controls over how they handle these two things, I instead
separated the call to ezcaPut out into a small, separate script (a stripped down ezcawrite), which the camera code calls at the system level. This is a
bit hacky of a solution, but its the only thing that seems to work.
I've developed a transformation based on Euler angles that should be able to take the 4 OSEMs in a picture of the end mirror and use their relative
positions to determine the angle of the camera to the optic. This would allow the position data determined by the fitting software to be converted
from pixels to meaningful lengths, and should aid any servo-ing done on the beams position. I've yet to actually test if the equations work, though.
The servo code needs to have slew rate limiters and maximums/minimums to protect the mirrors written in to it before it can be tested again, but I
have no idea what reasonable values for these limits are.
Joe and I recently scanned the PMC by driving C1:PSL-PMC_RAMP with the trianglewave script over a range of -3.5 to -1.25 (around 50 to 150 volts
to the PZT) and read out C1:PSL-ISS_INMONPD to measure the transmission intensity. This included slightly under 2 FSRs. For slow scans (covering
the range in 150 to 300 s), the peaks were very messy (even with the laser power at 1/6 its normal value), and it was difficult to place where the
actual peak center occurred. For faster sans (covering the range in 30 seconds or so), the peaks were very clean and nearly symmetric, but were
not placed logically (the same peak showed up at two very different values for the PZT voltage in two separate runs). I don't have time to put
together graphs of the scans at the moment; I'll have that up sometime this afternoon. |
772
|
Wed Jul 30 16:35:56 2008 |
Eric | Update | PSL | PMC Scan Graphs | Graphs of the PMC scan data that I got earlier today.
PMCLongScanWide.tiff shows the transmission intensity and PZT voltage plotted against time for a longer scan of the PMC (~120 seconds for one sweep).
PMCLongScanPeak.tiff is the same scan zoomed in on the primary peak. This scan was done with the laser power at around 1/3 its original value. However, scans done at around 1/6 the original value have peaks that are just as messy.
PMCShortScanWide.tiff shows the intensity and voltage for a more rapid scan (~30 second for one sweep). The black lines show how the peak positions are at very different PZT voltages (a difference of ~10 volts in both cases).
PMCShortScanPeak.tiff is zoomed in on the primary peak. The peak is much cleaner than for the long scan (less time for the laser's heat to expand the mirror?), though it is likely still too messy to reliably fit to a lorentzian. |
861
|
Wed Aug 20 12:39:11 2008 |
Eric | Summary | Cameras | Weekly Summary | I attempted to model the noise produced by the mirror defects in the ETMX images, in order to better assure that the fit to the beam Gaussian in these images is actually accurate. My first attempt involved treating the defects as random Gaussians which were scaled by the power of the beam's Gaussian. This didn't work at all (it didn't really look like the noise on the ETMX), and resulted in very different behavior from the fitting software (it fit to one of the noise peaks, instead of the beam Gaussian). I'll try some other models another time.
I made a copy of the ezcaservo source code and added options to it that allow the addition of minimum value, maximum value, and slew rate limits. This should allow the camera code to servo on ITMX without accidently driving the mirror too far or too fast. In order to get the code to recompile, I had to strip out part of the servo that changed the step value based on the amount of time that had elapsed (it relied on some GDS libraries and header files). Since the amount of time that passes is reasonably constant (about 2-3 steps per second) and the required accuracy for this particular purpose isn't extremely high, I didn't think it would matter very much.
I put together two MATLAB functions that attempt to convert pixel position in an image to actual position in real space. The first function takes four points that have known locations in real space (with respect to some origin which the camera is pointing at) and compares them to where those 4 points fall in the image. From the distortion of the four points, it calculates the three rotational angles of the the camera, as well as a scaling factor that converts pixels to real spatial dimensions. The second function takes these 4 parameters and 'unrotates' the image, yielding the positions of other features in the image (though they must be on the same flat plane) in real space. The purpose of this is to allow the cameras to provide positions in terms of physically meaningful units. It should also decouple the x and y axes so that the two dimensions can be servo'd on independently. Some results are attached; the 'original' image is the image as it came out of the camera (units in pixels), while the 'modified' image is the result of running the two functions in succession. The four points were the corners of the 'restricted access' sign and of the TV screen, while the origin was taken as the center of the sign or the TV. The accuracy of the transformation is reasonably good, but seems to depend considerably on assuring that the origin chosen in real space matches the origin in the image. To make these the same, they will be calculated by taking the intersections of the 2 lines defined by 2 sets diagonal points in each image. The first function will remain in MATLAB, since it only needs to be run once each time the camera is moved. The second function must be ported to C since the transformation must be done in realtime during the servo.
Joe and I attempted another scan of the PMC this morning. We turned the laser power down by a factor of ~50 (reflection off of the unlocked PMC went from ~118 to ~2.2) and blocked one beam in the MZ. We scanned from 40 V to 185 V ( -1 to -4.25 on the PZT ramp channel) with periods of 60 seconds and 10 seconds. In both cases, thermal effects were still clearly visible. We turned the laser power down by another factor of 2 (~1 on the PMC reflection channel), and did a long scan of 300 seconds and a short scan of 10 seconds. The 10 second scan produced what may be clean peaks, although there was clear digitization noise, while the peaks in the 300 second scan showed thermal effects. I've yet to actually analyze the data closely, however. |
880
|
Mon Aug 25 14:42:09 2008 |
Eric | Configuration | Cameras | ETMX Digital Camera | I changed the lens on the camera looking at the ETMX to a 16mm, 1:1.4 zoom lens. This is in preparation to measure a couple parameters that depend on the camera's position and angle, so please avoid repositioning it for a couple of days. |
891
|
Wed Aug 27 12:09:10 2008 |
Eric | Summary | Cameras | Weekly Summary | I added a configuration file parser to the Snap code. This allows all command line parameters (like exposure time, etc.) to be saved in a file and loaded automatically. It also provides a method of loading parameters to transform a point from its location on the image to its location in actual space (loading these parameters on the command line would substantially clutter it). The code is now fully set-up to test servo-ing one of the mirrors again, and I will test this as soon as the PMC board stops being broken and I can lock the X-arm.
I also took an image of the OSEMs on ETMX in order to apply the rotation transform code in order to determine the parameters to pass to Snap. The results were alpha = 2.9505, beta = 0.0800, gamma = -2.4282, c = 0.4790. These results are reasonable but far from perfect. One of the biggest causes of error was in locating the OSEMs: it is difficult to determine where in the spot of light the OSEM actually is, and in one case, the center was hidden behind another piece of equipment. Nevertheless, the parameters are good enough to use in a test of the ability to servo, though it would probably be worth trying to improve them before using them for other purposes. The original and rotated images are attached.
I've begun working on calculations to figure out how much power loss can occur due to a given cavity misalignment or change in a mirror's radius of curvature from heating. The goal is to determine how well a camera can indirectly detect these power losses, since a misalignment produces a change in beam position and a change in radius of curvature produces a change in beam waist, both of which can be measured by the camera.
Joe and I hunted down the requisite equipment to amplify the photodiode at the output of the PMC, allowing us to turn the laser power down even more during a scan of the PMC, hopefully avoiding thermal effects. This measurement can be done once the PMC works again. |
914
|
Wed Sep 3 12:26:49 2008 |
Eric | Summary | Cameras | Weekly Summary | Finished up simulating the end mirror error in order to test the whether the fitting code still provides reasonable answers despite the noise caused by the defects on the end mirror. The model I used to simulate the defects is far from perfect, but its good enough given the time I have remaining, and I have no reason to believe the differences between it and the real noise would cause any radical changes in how the fit operates. A comparison between a modeled image and a real image is attached. Average error (difference between the estimated value and the real value) for each of the parameters is
For the fit:
Max Intensity: 2767.4 (Max intensities ranged from 8000 to 11000)
X-Position: 0.9401 pixels
X Beam Waist: 1.3406 pixels (beam waists ranged from 35 to 45)
Y-Position: 0.9997 pixels
Y Beam Waist: 1.3059 pixels (beam waists ranged from 35 to 45)
Intensity Offset: 12.7705 (Offsets ranged from 1000 to 4000)
For the center of mass calculation (with a threshold that cut off everything above 13000)
X-Position: 0.0087 pixels
Y-Position: 0.0286 pixels
Thus, the fit is generally trustworthy for all parameters except for maximum intensity, for which it is very inaccurate. Additionally, this shows that the center of mass calculation actually does a much better job than the fit when this much noise is in the image. For the end mirrors, the fit is really only useful for finding beam waist, and even this is not extremely accurate (~3% error). All the parameters for the modeling is on the svn in /trunk/docs/emintun/MatLabFiles/EndMirrorErrorSimulation.txt.
Finished working on the calculations that convert a beam misalignment as measured as a change in the beam position on the two mirrors to a power loss in the cavity. Joe calculated the minimum measurable change in beam position to be around a tenth of a pixel, which corresponds to half a micron when the beam is directly incident on the camera. This gives the ability to measure fractional power losses as low as 2*10^-10 for the 40m main arm cavities. To me, this seems unusually low, though it scales with beam position squared, so if anything else limited the ability to measure changes in the beam position, it would have a large effect on the sensitivity to power losses. Additionally, it scales inversely with length, so shorter cavities provide less sensitivity.
This morning Joe and I tested the ability for the camera code to servo the ITMX in order to change the beam's position on the ETMX. Two major things have been changed since the last time we tried this. First, the calculated beam center that gets output to the EPICS channels now first goes through a transform that converts it from pixels into physical units, and should account for the oblique angle of the camera. The output to the EPICS channels should now be in the form of 'mm from the center of the optic', although this is not very precise at the moment. The second thing that was changed was that the servo was run with a modified servo script that included options to set a minimum, maximum, and slew rate in order to protect the mirrors from being swung around too much. The servo was generally successful: for a given x-position, it was capable of changing the yaw of ITMX so that the position seen on the camera moved to this new location. The biggest problem is that the x and y dimensions do not appear to be decoupled (the transform converting it to physical units should have done this), so that modifying the yaw of the mirror changed both the x and y positions (the y about half as much) as output by the camera. This could cause a problem when trying to servo in both dimensions at once, since one servo could end up opposing the other. I don't know the cause of this problem yet, since the transform that is currently in use appears to be correctly orienting the image. |
6881
|
Wed Jun 27 14:12:44 2012 |
Eric | Summary | General | SURF Week 1 | I started work familiarizing myself with the ELOG and some of the control systems at the 40m. I spent a fair bit of time gaining some general knowledge of the interferometer, control systems, calibration, null instruments, etc. On Friday, June 22 Yaakov and I spent the afternoon pulling cables for the beatbox that Jamie had finished up. We were able to get the cables from the rack containing the beatbox routed to the control room.
Then I started work on calibrating the beatbox. I set up the function generator to send a sine wave into the beatbox, then sent the signal from the beatbox to the oscilloscope. I compared both the input sine wave and the output from the beatbox at many frequencies, taking peak to peak measurements. I'm working on using the data to calibrate the beatbox now. |
6962
|
Wed Jul 11 14:22:54 2012 |
Eric | Summary | General | SURF Update | Here's what I accomplished since my last elog:
I continued working on the beatbox calibration. Instead of using the function generator for an input signal,
I used the network analyzer because it can generate higher frequencies that are of more interest to us. I ran
the network analyzer output into the RF in port, and took voltage measurements from the Q port using the
oscilloscope. The frequency range I focused on was 100 - 200 MHz, and I also took more closely spaced measurements
from 180 - 200 MHz. The data is recorded on the computer now, and I will analyze it more fully in the future.
I also edited the Calibration page on the LIGO 40 m wiki. Rana showed me the page on calibration, but there was
limited information there, so he recommended that I post my work there as well. Right now I haven't posted much,
but I will likely add some information on the Simulink model I'm working on and results of measurements to be
taken as the project progresses.
The majority of my work has been on developing a Simulink model in Matlab of the differential arm length sensing
and control loop. I am using Figure 6-1 from Rana's thesis as a guide on important components to include in the
model. Some of the details on the transfer functions of components need to be worked out, but a basic framework has
been established. Right now the transfer function of the arm cavity is being approximated as a single pole, but
we may integrate the calibration model I'm working on with Sasha's work on the arm cavity. I have also begun to
implement the length response function in the model. I believe it is giving correct results at frequencies up to
100 Hz, but is off at higher frequencies. This might be fixed after I continue to fill in the transfer functions
of the digital components; they are currently set to 1 until I find more information on them. |
|