ID |
Date |
Author |
Type |
Category |
Subject |
10235
|
Fri Jul 18 14:59:07 2014 |
Evan | Update | IOO | MC servo TFs |
[Rana, Evan]
This morning we took several TFs of the MC servo board using the HP4395A.
The 4395 source was teed, with one output of the tee going to 4395 R and the other output going to the board's IN1. We then took TFs of (4395 A) / (4395 R), where 4395 A was one of the following four points on the servo board:
- OUT2
- A TEST1
- B TEST1
- SERVO
For each of these points, we took a TF at two gain settings: IN1 and VCO gains both at 0 dB, and then IN1 and VCO gains both at 20 dB.
Before doing these measurements, we calibrated out the cable delay. Additionally, SERVO was always loaded with 50 Ω—either from the 4395 or from a terminator.
The attached png shows the servo board settings when these TFs were taken with the 0 dB gain settings. The settings for the 20 dB measurements are identical, except for the higher IN1 and VCO gains. |
Attachment 1: mcServoTFSettings.png
|
|
Attachment 2: MCtfs.pdf
|
|
10234
|
Thu Jul 17 22:08:14 2014 |
Koji | Update | General | 1X2 Rack Changes |
It sounds like the work was done carefully. Even so, Jenne or Manasa have to run the ALS (X and Y) to check if they are still functional. |
10233
|
Thu Jul 17 21:01:28 2014 |
Manasa | Update | General | 1X2 Rack Changes |
Quote: |
Purpose
Steve and I moved some things around in the 1X2 rack in order to make room (roughly 6") for the electronics box that will contain rf frequency counters, ADC, and Raspberry Pi's for use in the Frequency Offset Locking apparatus
Picture

Occurrences
First, we killed power by removing the fuse that the boxes we were moving were running through.
Then, we moved the boxes. I dropped//lost a washer. It didn't seem to cause any problems, so no further attempts to locate it were made.
The fuse was reinstalled, and everything was reconnected.
Moving Forward
We are now working on putting together the electronics box, which will contain ADC, and raspberry pi's. The frequency counters will be mounted on the front of the box.
Once complete, it will be installed for use in FOL.
|
Additional comments:
This was done based on the earlier proposed setup plan for the frequency counters that will be used to measure the beat note frequencies [Akhil's elog]
I switched off the power supply to the green PDs so that we don't cause any damage while moving the amplifier panel for the beat signals and beatbox. |
10232
|
Thu Jul 17 17:39:57 2014 |
Koji | Update | Electronics | PDFR debugging attempt : REFL11 |
What is the coupling factor between the RF in and the RF mon of the demodulator?
I don't assume you have the same amount RF power at those two points unless you have an RF amplifier in the mon path. |
10231
|
Thu Jul 17 17:19:25 2014 |
Steve | Update | PSL | PSL Innolight controller fan is dying with extra fan |
Quote: |
[Koji, Manasa]
The air flow from the dying fan was kinda weak and we decided to give a help with an external fan.
Koji brought a fan taken from a junk found at EE shop in W.Bridge.
The fan has been tied to the cage of the existing fan using cable ties to provide air circulation.
So even if the existing one dies anytime, we still don't super-heat anything.
The power supply for the fan rests next to the controller.
The air from the fan ventilation was hot, and now with the additional fan this hot air is actually sucked
out with stronger flow. So this is relieving for now.
|
PMC transmission as an indicator of laser controller with extra fan solution: 8 and 1day plot |
Attachment 1: fanadded.png
|
|
10230
|
Thu Jul 17 17:08:58 2014 |
Harry | Update | General | 1X2 Rack Changes |
Purpose
Steve and I moved some things around in the 1X2 rack in order to make room (roughly 6") for the electronics box that will contain rf frequency counters, ADC, and Raspberry Pi's for use in the Frequency Offset Locking apparatus
Picture

Occurrences
First, we killed power by removing the fuse that the boxes we were moving were running through.
Then, we moved the boxes. I dropped//lost a washer. It didn't seem to cause any problems, so no further attempts to locate it were made.
The fuse was reinstalled, and everything was reconnected.
Moving Forward
We are now working on putting together the electronics box, which will contain ADC, and raspberry pi's. The frequency counters will be mounted on the front of the box.
Once complete, it will be installed for use in FOL. |
10229
|
Thu Jul 17 16:39:34 2014 |
Nichin | Update | Electronics | PDFR debugging attempt : REFL11 |
In a attempt to debug the values of transimpedance generated by the PDFR system, I did a manual measurement for REFL11 PD.
- Took the tops off AS and POY tables. (REFL11 and REF PD) Under the supervising eye of Manasa
- Verify that no extra light is falling on REFL11.
- Retake DC voltage readings, power readings.
- Manually set the sweep parameters and record readings from network analyzer.
- Put the tops back on the tables
- Calculate transimpedance
Results:
REF PD(1611):
Pinc = 1.12 mW T_dc = 10000 V/A (datasheet)
Vdc = 7.68 V T_rf = 700 V/A (datasheet)
Calculated Responsivity = 0.68 A/W (Which matches perfectly with the datasheet value of 0.68 A/W)
REFL11:
Pinc = 0.87 mV T_dc = 66.2 V/A (schematic)
Vdc = 32.5 mV
Calculated Responsivity = 0.56 A/W
Network analyzer reading at 11 MHz : 0.42
Calculated RF Transimpedance = 460 V/A
40m Wiki : RF Transimpedance = 4 kV/A
I ran the same measurement using PDFR system and got the same results.
Attached: the automatic data and plot obtained.
Conclusion: The PDFR system and manual measurements agree with each other. However the values do not match with 40m Wiki. I have no clue about which measurement is correct or any mistakes I might be making in the calculations.
|
Attachment 1: REFL11_17-07-2014_154534.pdf
|
|
Attachment 2: REFL11_17-07-2014_154534.zip
|
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. |
10226
|
Thu Jul 17 02:57:32 2014 |
Andres | Update | 40m Xend Table upgrade | FInish Calculation on Current X-arm mode Matching |
Data and Calculation for the Xarm Current Mode Matching
Two days ago, Nick, Jenne, and I took a measurement for the Green Transmission for the X-arm. I took the data and I analyzed it. The first figure attached below is the raw data plotted. I used the function findpeaks in Matlab, and I found all the peaks. Then, by taking close look at the plot, I chose two peaks as shown in the second figure attached below. I took the ratio of the TEM00 and the High order mode, and I average them. This gave me a Mode Matching of 0.9215, which this value is pretty close to the value that I predicted by using a la Mode in http://nodus.ligo.caltech.edu:8080/40m/10191, which is 0.9343. Nick and I measured the reflected power when the cavity is unlocked and when the cavity is locked, so we measured the PreflUnLocked=52+1µW and PreflOnLocked=16+2µW and the backgroundNoise=0.761µW. Using this information we calculated Prefl/Pin=0.297. Now, since Prefl/Pin=|Eref/Ein|2, we looked at the electric fields component by using the reflectivity of the mirror we calculated 0.67. The number doesn't agree, but this is because we didn't take into account the losses when making this calculation. I'm working in the calculation that will include the losses.
Today, Nick and I ordered the lenses and the mirrors. I'm working in putting together a representation of how much improvement the new design will give us in comparison to the current setup.
|
Attachment 1: RawDataForTheModeGreenScan.png
|
|
Attachment 2: ResultForModeMatching.png
|
|
Attachment 3: DataAndCalculationOfModeMismatch.zip
|
10225
|
Thu Jul 17 01:24:35 2014 |
rana | Update | IOO | MC / EOM Stability Mystery Solved! |
MC loop is near unstable. Common gain reduced. Needs more loop tuning.
We've often seen that the MC gets into a state where it keeps losing lock and the EOM drive shows a large RMS. We've usually been looking at the noise spectrum to diagnose this.
Tonight we finally just measured the OLG. The attached plot shows the loop gain measured with the 4395 on the MC servo board
Although the phase margin is a healthy 45 degrees, its close to instability at 1 MHz. For this plot, I reduced the gain by 3 dB and now the margin is ~7 dB. So usually its pretty close to unstable and at least its always making a noise peak.
That whole TF above a few hundred kHz is weird. We should tune out whatever makes it so flat and also remove the resonance that makes the 1 MHz peak; maybe its from some post mixer low pass?
Anyone interested in helping in the investigation ought to measure the TF of the MC demod board, the MC servo board, and the FSS box.
Silver lining: if we fix this loop shape, we might be able to have a much more stable IMC and IFO. |
Attachment 1: MC_OLG.pdf
|
|
10224
|
Thu Jul 17 00:38:30 2014 |
Jenne | Update | LSC | RIN in arm transmission |
[Rana, Jenne]
We had a look at the RIN of the transmission signals TRX and TRY, when the arms were individually locked on IR. If the intensity noise is very bad, then the transmission signals aren't really a good option to use for locking. So, if the RIN is bad, we need to work on our intensity stabilization.
We need to understand what the situation is with the AOM, and why it isn't working as expected, so that we can reinstall it. We also need to decide if we're going to use the SR560 setup, or if the Chas ISS is sufficiently characterized for us to use.
The RIN is certainly bad. Also, I don't know why the Xarm's RIN is worse between 10 Hz and a few hundred Hz than the Yarm.

|
10223
|
Wed Jul 16 23:02:16 2014 |
Koji | Summary | Electronics | Bode Plots and complete Characterization of Frequency Counter |
If I assume 1sample delay for 0.1s sampling rate, the delay is Exp[-I 2 pi f T], where T is the sampling period.
This means that you expect only 36 deg phase delay at 1Hz. In reality, it's 90deg. Huge!
Also there are suspicious zeros at ~1.6Hz and ~3Hz. This may suggest that the freq counter is doing some
internal averaging like a moving average.
It would be interesting to apply a theoretical curve on the plot. It's an intellectual puzzle. |
10222
|
Wed Jul 16 22:17:40 2014 |
Akhil | Summary | Electronics | Bode Plots and complete Characterization of Frequency Counter |
Goal:
To estimate the transfer function and the noise in the FC that is a part of the FOL-PID loop.
Measurements Taken:
The setup used for the measurements is described in my previous elogs.
The input modulation signal and the FC output were recorded simultaneously for a certain period of time and the phase and gain are estimated from the data.
Analysis(Data and code attached):
The recordings must contain equal number of data points(around 6000 data points in my measurements) for analysis.
The steps I followed to generate these plots are:
- Took the FFT of both FC out data(from FC) and Modulation input(from SRS via ADC).
- Estimated the phase angles at the particular modulation frequencies from the FFT data(in Matlab using angle(x) for phase at the frequency f(x);x: is the frequency bin)
- Then for the phase of the system at a particular modulation frequency,
Phase(system) =Phase(FC Signal) - Phase(Input Signal)
- Plotted the acquired phase vs the modulation frequency on a Semi-log graph.
Results:
From the plots its can be inferred that :the delay of the FC is almost 0 until the modulation of 0.1 Hz. Then there are phase shifts of +/- 180 degrees showing that the system has multiple poles and zeroes(will be estimated after I have phase plots at few more carrier frequencies).
To Do Next:
Phase plots for varying carrier frequencies and different sampling times.
Installation of FC inside the 40m. |
Attachment 1: Phase_Data.zip
|
Attachment 2: Bode100MHz.png
|
|
10221
|
Wed Jul 16 21:24:41 2014 |
Reetika | Update | Electronics | VCO Driver inside 40m |
I found the VCO driver, that Rana asked me to locate, inside the 40m. I already have one VCO from PSL lab. Now, I have kept both of them inside the 40m lab(one on the cart in the side of the Y-arm and the other near the X-arm electronics table). |
10220
|
Wed Jul 16 21:23:35 2014 |
Manasa | Update | PSL | PSL Innolight controller fan is dying |
[Koji, Manasa]
The air flow from the dying fan was kinda weak and we decided to give a help with an external fan.
Koji brought a fan taken from a junk found at EE shop in W.Bridge.
The fan has been tied to the cage of the existing fan using cable ties to provide air circulation.
So even if the existing one dies anytime, we still don't super-heat anything.
The power supply for the fan rests next to the controller.
The air from the fan ventilation was hot, and now with the additional fan this hot air is actually sucked
out with stronger flow. So this is relieving for now. |
Attachment 1: IMG_1659.JPG
|
|
Attachment 2: IMG_1658.JPG
|
|
10219
|
Wed Jul 16 19:38:37 2014 |
manasa | Summary | PSL | AOM alignment issues and removed from beam path |
AOM removed from the beampath and PMC relocked.
AOM alignment:
1. Measured the initial power after PMC as 1.30W and reduced it down to 130mW.
2. Checked the power in the AOM zero order transmission before touching it. For 0-1V modulation input, the power dropped from 125uW to 98.3uW.
3. Steered the mirror right before the AOM to increase AOM zero order transmission and then carefully moved the AOM around to obtain maximum power attenuation. I repeated this a few times and the maximum attenuation that I could obtain was 125uW to 89.2uW (~30% attenuation).
Although this is not the right way to align the AOM, we do not have much options with the current setup as there is not enough separation between the zero order and first order beams and the AOM is on a fixed rigid mount.
4. I tried to dump the first order beam from the AOM and it wasn't satisfactory as well. There is barely any separation between the zero order and first order beams.
PMC relocking:
1. SInce the alignment to the PMC was disturbed by moving the AOM and the steering mirror in front of it, the PMC alignment was lost.
2. I could not relock the PMC at low power or high power. Rana had to come to rescue and fixed the alignment so that we could see flashes of PMC on the trans camera (This was done by aligning refl beam to the PMC REFL PD while giving a triangular ramp to the PMC PZT voltage).
Also I should not have tried to lock the PMC at high power as I could have been steering the beam at high power to the edges of the PMC mirrors that way and burning stuff easily.
3. Before fine tuning the alignment, I decided to remove the AOM from the beam path as there needs some work done on it to make it useful.
4. I removed the AOM from the beam path and relocked the PMC.
5. PMC is relocked with 0.79 counts in TRANS and I measured the power after PMC 1.30W
Attachment: picture showing AOM removed from the beampath. |
Attachment 1: AOMremoved.jpg
|
|
10218
|
Wed Jul 16 17:34:11 2014 |
Harry | Update | General | Fiber Coupled |
Purpose
To couple the spare NPRO into our Panda PM980 fibers, in order to carry out tests to characterize the fibers, in order to use them in FOL.
Design
Manasa and I spent this morning building the setup to couple NPRO light into the fibers. We used two steering mirrors to precisely guide the beam into the coupler (collimator).
We also attached the lens to a moveable stage (in the z axis), so the setup could be fine tuned to put the beam waist precisely at the photodiode.
The fiber was attached to a fiber-coupled powermeter, so I would be able to tell the coupling efficiency.

Methods
During alignment, the NPRO was operating at 1.0 amps, roughly half of nominal current (2.1A).
I first placed the coupler at the distance that I believed the target waist of 231um to be.
Using the steering mirrors and the stage that holds the couple, I aligned the axes of the coupler and the beam.
Finally, I used the variable stage that the lens is attached to to fine tune the location of the target waist.
Results
Once I was getting readings on the powermeter (~0.5nW), the laser was turned up to nominal current of 2.1A.
At this point, I and getting 120nW through the fiber.
While far from "good" coupling, it is enough to start measuring some fiber characteristics.
Moving Forward
Tomorrow, I hope to borrow the beam profiler once again so as to measure the fiber mode.
Beyond this, I will be taking further measurements of the Polarization Extinction Ratio, the Frequency Noise within the fiber, and the effects of a temperature gradient upon the fiber.
Once these measurements are completed, the fiber will have been characterized, and will be ready for implementation in FOL. |
10217
|
Wed Jul 16 17:06:41 2014 |
Nichin | Update | Computer Scripts / Programs | HP8591E spectrum analyzer remote scan |
Updated script does the following:
1) Gets the highest 2 peaks
2) Puts a marker on the peaks. Now it looks very similar to the spectrum analyzer display.
3) The refresh rate is still 3 seconds. It might become better if the analyzer was hooked up to a wired martian LAN port rather than the wireless module I am using now.
PFA a sample pdf |
Attachment 1: HP8591E_View.pdf
|
|
10216
|
Wed Jul 16 15:26:48 2014 |
Steve | Update | PSL | PSL Innolight controller fan is dying |
Quote: |
Quote: |
Also, while I was working on the PSL table, I heard noise that sounded like a bearing rolling around. I suspected the HEPAs, since the one on the north east corner of the table has a problem when it's turned up high (we've known about this for a long time), however turning off the HEPAs didn't affect the noise. The noise is strongest near the back of the PSL controller on the shelf above the table, and the PSL controller box is vibrating. So, I suspect that the fan on the PSL controller box is about to give out.
EDIT: To clarify, I mean the Innolight's controller.
|
The bearing is chirping in the back of the 2W Innolight laser controller. It is loud enough to hear it. I placed 4 soft rubber feet under the controller to avoid shaking other things on self.
The HEPA filter bearing becomes noisy at 50V
Keep it at 20V for low noise
|
The fan is dying. It is changing speed erratically and stops for short time periods. It is very likely to stop rotating soon. It will halt all operations in the lab. We can not see the PMC-T power because Manasa is working on
AOM alignment.
|
10215
|
Wed Jul 16 07:51:52 2014 |
Akhil | Update | General | Weekly Update |
Work Done:
- Solved all the timing issues pertaining to the R Pi and the FC.
- Took all the measurements for complete characterization of the frequency counter(Phase Plots to follow shortly).
- Finished installation of the FC on the martian and created a channel for the FC frequencies(will be tested in this week).
Plans for this Week:
- Testing of the EPICS soft IOC created for the FC as a channel access server and hence completing the installation of the FC.
- Placing the FC inside the lab( plan discussed in this elog: http://nodus.ligo.caltech.edu:8080/40m/10163) with proper supervision.
- Characterization of the temperature actuator.
Inside the 40m Lab:
I will need to be inside the lab to place the FC . This will be done in the morning session (on thursday) with supervision of Manasa and Steve(if required).
|
10214
|
Wed Jul 16 02:22:10 2014 |
Koji | Update | Electronics | Test run of PDFR system |
Log-log ... |
10213
|
Wed Jul 16 01:54:25 2014 |
Nichin | Update | General | Work plan for next week |
1) Debugging transimpedance calculations in the PDFR
Requires presence of an expert whenever I get inside the lab to take DC measurements or check the illuminating fibers.
2) Creating and incorporating canonical data plots with every measurement of PDFR.
3) Transfer function fitting for transimpedance
4) Improve the Spectrum analyzer scan scripts as mentioned in my elog. |
10212
|
Wed Jul 16 01:46:41 2014 |
Nichin | Update | Electronics | Test run of PDFR system |
A test run was conducted on the PDFR system last afternoon and transimpedance plots were generated for 6 of the PDs. The laser was shut down after the test run.
I have not verified (yet) if the transimpedance values indicated by the plots are correct or not. The values mostly look INCORRECT. But the peaks are exactly where they need to be. *phew!*
Reasons: Incorrect calibration, Light other than from the PDFR system fibers on the PDs
Will have to work on debugging all this. |
Attachment 1: PDFR_testRun_15-07-2014.pdf
|
|
10211
|
Wed Jul 16 01:35:16 2014 |
Koji | Summary | LSC | Python Wavelet peak finding for dramatic ALS - Red Resonance finding speedup |
From the last plot:
- Subtracting the offset of 0.0095, the modulation depth were estimated to be 0.20 for 11MHz, 0.25 for 55MHz
- Carrier TEM00 1.0, 1st order 0.01, 2nd order 0.05, 3rd order 0.002, 4th order 0.004
==> mode matching ~93%, dominat higher order is the 2nd order (5%).
Eric: now we have the number for the mode matching. How much did the cavity round-trip loss be using this number? |
10210
|
Wed Jul 16 01:27:01 2014 |
Nichin | HowTo | Computer Scripts / Programs | HP8591E spectrum analyzer remote scan |
The script for running continuous scans on HP 8591E spectrum analyzer is located at scripts/general/netgpibdata/HP8591E_contdScan.py
Give the file HP8591E_param.yml as an argument when running the script. This contains the sweep parameters: Start and stop frequencies along with the place where the plot is stored as a PDF.
The default PDF is located on the Desktop and is named HP8591E_View.pdf Open this using okular and then run the script. (Okular pdf viewer automatically reloads the PDF as and when a new one is created)
What the script does:
1) Set the start and stop frequencies as given in the .yml file
2) Take a data trace and plot it in a PDF.
3) Repeat taking traces and update the PDF. Untill Ctrl+C is pressed (PDF refresh rate: approximately every 3 seconds )
4) Exit smoothly after the keyboard interrupt.
Other details:
This spectrum analyzer is connected to a GPIB - Ethernet controller that is configured as santuzza.martian (192.168.113.109)
I have currently stolen the wireless modem from the spectrum analyzer inside the lab (vanna.martian) and using it for this one. *poker face*
To improve:
Get the plot to show where the two biggest peaks are located. Currently it recognizes only the biggest one.
Possibly have makers on the two peaks.
PFA a sample pdf |
Attachment 1: HP8591E_View.pdf
|
|
10209
|
Wed Jul 16 01:18:02 2014 |
rana | Summary | LSC | Python Wavelet peak finding for dramatic ALS - Red Resonance finding speedup |
New script called scripts/ALS/findRedResonance.py finds the IR resonance in less than 20 seconds.
- Do a ~2 FSR scan of the arm over 10 seconds using the Phase Tracker servo offset ramp. (dt = 10 s)
- Load the frame data for the TR_OUT and the Phase Tracker phase. (dt = 2 s)
- Use Python (modern) SciPy to find all peaks with moderate SNR (dt = 3 s)
- Take the top 3 peaks (all presumably TEM00) and choose the one closest to zero and go there.
The above is the gist of what goes on, but there were several issues to overcome to get the code to run.
- None of our workstations have a modern enough Python distro to run either the ipython notebooks or the new SciPy with wavelets, so I installed Anaconda Python in the controls home directory.
- In order to get the peak finder function to work well I gave it a range of peak widths to look for. If we change the speed of the ALS scan by more than 3x, we probably have to change the width array in the function.
- I've used the find_peaks_cwt function in SciPy. This uses a Ricker ('Mexican Hat') wavelet to find peaks by doing multi-res transforms and looking for ridges in the wavelet space (I think)
- To make the code run fast, I downsample from 16 kHz to 1 kHz right at the top. Would be better if we had downsampling in v2 of the getData function.
|
Attachment 1: findRedResonance.pdf
|
|
10208
|
Wed Jul 16 01:04:09 2014 |
Jenne | Update | LSC | Data for DARM on sqrtInv investigation |
I realized while I was looking at last night's data that I had been doing CARM sweeps, when really I wanted to be doing DARM sweeps. I took a few sets of data of DARM sweeps while locked on ALSdiff. However, Rana pointed out that comparing ALSdiff to TRX-TRY isn't exactly a fair comparison while I'm locked on ALSdiff, since it's an in-loop signal, so it looks artificially quiet.
Anyhow, I may consider transitioning DARM over to AS55 temporarily so that I can look at both as out-of-loop sensors.
Also, so that I can try locking DARM on DC transmission, I have added 2 more columns to the LSC input matrix (now we're at 32!), for TRX and TRY. We already had sqrt inverse versions of these signals, but the plain TRX and TRY were only available as normalization signals before. Since Koji put in the facility to sqrt or not the normalization signals, I can now try:
Option 1: ( TRX - TRY ) / (TRX + TRY)
Option 2: ( TRX - TRY ) / sqrt( TRX + TRY )
DARM does not yet have the facility to normalize one signal (DC transmission) and not another (ALS diff), so I may need to include that soon. For tonight, I'm going to try just changing matrix elements with ezcastep.
Since I changed the c1lsc.mdl model, I compiled it, restarted the model, and checked the model in. I have also added these 2 columns to the AUX_ERR sub-screen for the LSC input matrix. I have not changed the LSC overview screen. |
10207
|
Tue Jul 15 22:23:51 2014 |
Andres | Update | 40m Xend Table upgrade | Scan the Xarm for the mode matching |
Nick and I with the help of Jenne scan the green light when the cavity is unlocked. Nick placed a Beam dump on the IR so that we can just scan the green, but it was removed as soon as we finished with the measurement. I'm working on the calculation, and i'll be posted solution tonight. |
10206
|
Tue Jul 15 21:43:28 2014 |
Jenne | Update | LSC | QPDs back |
I removed the dumps in front of the trans QPDs. The Yend QPD needed re-normalization, so I did that. |
10205
|
Tue Jul 15 18:39:04 2014 |
Harry | Update | General | Weekly Plan (7.16.14) |
The Past Week
Attempted to design coupling telescope, turned out waist measurement was still off. Took another waist measurement, this time more reasonable.
Used recent waist measurement to actually design a coupling system to couple NPRO light into Panda PM980 fibers (see recent elog)
The Next Week
Assemble fiber coupling system
Measure coupling efficiency, ensure it's at least 60%
Begin measuring Polarization Extinction ratio
Materials
PLCX lens with f = 0.25m ------> status: here
Fiber Coupled Powermeter//PD ------> status: unknown (have any laying around?)
Quarter Wave Plate, Polarizing Beamsplitter, Photodiodes ------> status: here
other components from original razorblade measurement setup |
10204
|
Tue Jul 15 18:26:40 2014 |
Harry | Update | General | Beam Waist, Telescope, and Fiber Coupling |
Goal
To design an optical setup (telescope / lens) to couple 1064nm NPRO light into PANDA PM980 fibers in order to characterize the fibers for further use in the frequency offset locking setup.
Design

Calculations
The beam waist of the NPRO was determined as 233um 6cm in front of the NPRO. This was used as the seed waist in ALM.
The numerical aperture of the fiber was given as 0.12, which allowed me to calculate the maximum angle of light it would accept, with respect to the optical axis, as NA = sin(theta) where theta is that angle.
Given that the coupler has a focal length of 2mm, I used the formula r = f * tan(theta), to yield a "target waist" for efficient coupling into the fiber. This ended up being 241.7um.
Since there was not a huge difference between the natural beam width of the NPRO and our target waist, I had no need for multiple lenses.
I used 230um as a target waist for a la mode, to leave myself some room for error while coupling. This process gave me a beam profile with a lens (f=0.25m), and a target waist of 231um, located 38.60cm from the coupling lens
I have attached ALM code, as well as the beam profile image. Note that the profile takes zero to be the location of the NPRO waist.

Next Steps
After this setup is assembled, and light is coupled into the fibers, we will use it to run various tests to the fiber, for further use in FOL. First of all, we wish to measure the coupling efficiency, which is the purpose of the powermeter in the above schematic. We will measure optical power before and after the fibers, hoping for at least ~%60 coupling. Next is the polarization extinction ratio measurement, for which we will control the input polarization to the fibers, and then measure what proportion of that polarization remains at the output of the fiber. |
Attachment 3: fiberTesting.zip
|
10203
|
Tue Jul 15 17:34:01 2014 |
manasa | Update | PSL | proposing AOM re-alignment |
I am going to tweak the alignment of the beam into the AOM (before the PMC) tomorrow morning. If anybody has any objections to this, please raise a red flag.
Proposed alignment procedure:
1. Reduce PSL power to say 10%
2. Since the AOM is not on any sort of a mechanical stage, I will have to just play around carefully until I see a maximum power rejection into first order.
I am assuming that moving the AOM is not going to affect the input pointing because all these activities are happening before the PMC. So as long as I have the output beam from the AOM aligned to the PMC at the end, everyone should be happy. |
10202
|
Tue Jul 15 12:36:17 2014 |
Nichin | Update | Electronics | RF cables rerouted |
Quote: |
I have not connected them to the RF switch yet. ( until I figure out how to get both the switches working properly)
|
I went into the lab and connected the RF cables to the Mux. Will take measurements for each PD henceforth. |
10201
|
Tue Jul 15 11:04:05 2014 |
Steve | Update | safety | safety glasses must be worn all times! |
This is the third safety glasses that I found laying around in the IFO lab lately. Safety glasses must be worn ALL times in the IFO room!
This rule is essential for your protection! Please do not enter if you can not put up with this regulation!
|
Attachment 1: safetyglasses.jpg
|
|
10200
|
Tue Jul 15 01:41:43 2014 |
Jenne | Update | LSC | Data for DARM on sqrtInv investigation |
I took some data tonight for a quick look at what combinations of DC signals might be good to use for DARM, as an alternative to ALS before we're ready for RF.
I had the arms locked with ALS, PRMI with REFL33, and tried to move the CARM offset between plus and minus 1. The PRMI wasn't holding lock closer than about -0.3 or +0.6, so that is also a problem. Also, I realized just now that I have left the beam dumps in front of the transmission QPDs, so I had prevented any switching of the trans PD source. This means that all of my data for C1:LSC-TR[x,y]_OUT_DQ is taken with the Thorlabs PDs, which is fine, although they saturate around arm powers of 4 ever since my analog gain increase on the whitening board. Anyhow, the IFO didn't hold lock for much beyond then anyway, so I didn't miss out on much. I need to remember to remove the dumps though!!
Self: Good stuff should be between 12:50am - 1:09am. One set of data was ./getdata -s 1089445700 -d 30 -c C1:LSC-TRX_OUT_DQ C1:LSC-TRY_OUT_DQ C1:LSC-CARM_IN1_DQ C1:LSC-PRCL_IN1_DQ |
10199
|
Tue Jul 15 01:31:13 2014 |
Akhil | Summary | Electronics | Timing Issues of Mini Circuits UFC-6000: Solved |
The attached are the PSD plots with improved FC timing(with the same code as in http://nodus.ligo.caltech.edu:8080/40m/10151). More plots(Phase and PSD) to follow.
|
Attachment 1: qnoise.png
|
|
Attachment 2: qnoise.pdf
|
|
10198
|
Tue Jul 15 00:16:52 2014 |
Jenne | Update | SUS | PRM significantly pitched |
I'm starting to lock for the night, and I noticed that PRM is very, very pitched. Why? The PRM pitch slider is 5 full integer units higher than the backup (and the backup value is about where I like it, around -0.2).
I am not aware of any scripts that touch the PRM slider values. The PRM ASS (which I haven't used in ages) offloads the biases to the SUS screen fast channels, so even if someone turned that on and then saved the values, it wouldn't leave the PRM so very, very misaligned.
I have restored it, and relocked the PRMI, so all is well, but it's very weird to have found it so misaligned. |
10197
|
Mon Jul 14 17:51:34 2014 |
Nichin | Update | Computer Scripts / Programs | MEDM for PDFR system |
A
Successfully completed the rudimentary GUI for PDFR system. (users/nichin/PDFR)
Pressing any of the buttons above runs the script that does the following:
1) Change RF mux channel to the required one.
2) Frequency sweep on the network analyzer. The common sweep parameters are in a file named param_NWAG4395A.yml . PD specific parameters are in param_[PD name].yml in their respective folders
3) The transimpedance is calculated and the plot is saved as PDF in the respective folder for the PD. Each set of measurement data and plot is in a timestamped subfolder.
Further work:
To take transimpedance readings for each PD and create a canonical set of data that can be used to compare with data obtained for every measurement run. |
10196
|
Mon Jul 14 16:51:07 2014 |
Nichin | Update | Electronics | Martian table updated, Named server restarted |
[Nichin, Jenne]
The martian lookup tables are located at /etc/bind/zones/martian.db and etc/bind/zones/rev.113.168.192.in-addr.arpa
Jenne updated these to include santuzza.martian 192.168.113.109
The method to restart named server given at https://wiki-40m.ligo.caltech.edu/Martian_Host_Table also does not work.
I restarted it using >sudo /etc/init.d/bind9 restart
The named server is now updated and works fine. :) I will update the 40m wiki now. |
10195
|
Mon Jul 14 16:19:41 2014 |
Andres | Update | 40m Xend Table upgrade | Took the measurement for the Mode Matching |
Nick and I measured the reflected power of the green light in locked and unlocked. I'm working on the calculation of the mode matching. Tonight, I'll be posted my calculation I'm still working on it.
JCD: Andres forgot to mention that they closed the PSL shutter, so that they could look at the green light that is reflected off the harmonic separator toward the IR trans path. Also, the Xarm (and the Yarm) were aligned to IR using the ASS, and then ASX was used to align the green beam to the cavity. |
10194
|
Mon Jul 14 14:28:27 2014 |
Koji | Summary | Electronics | Timing Issues of Mini Circuits UFC-6000: Solved |
Looks good. Now you have the internal timer to verify the external clock.
If you can realize the constant rate sampling without employing the external clock, that's quite handy. |
10193
|
Mon Jul 14 13:03:23 2014 |
Akhil | Summary | Electronics | Timing Issues of Mini Circuits UFC-6000: Solved |
Main Problem:
The frequency counter (FC) takes in an analog RF input(signal) and outputs the frequency of the signal(Ranging from 1 MHz- 6000 MHz) in the digital domain (into a processor). The FC samples the data with a given sample rate( user defined) which ranges from 0.1 s to 1 s(faced problems in fixing this initially). For data acquisition, we have been using a Raspberry Pi(as a processor) which is connected to the martian network and can communicate with the computers inside the 40m. The ultimate challenge which I faced( and been knocking my head off from past two-three weeks) is the synchronization of clocks between the Raspberry Pi and the FC i.e the clock which the FC uses to sample and dump data( every 'x' s) and the clock inside the raspberry pi( used in the loop to wait for a particular amount of time the frequency counter takes to dump successive data).
Steps Taken:
- To address this problem, first I added an external clock circuit which monitors the Raspberry Pi and the FC to dump and read data at a particular rate(which is equal to the sampling rate of the FC)In detail: http://nodus.ligo.caltech.edu:8080/40m/10129.
- While doing so, at first the level trigger algorithm was used which means that the external clock frequency was half as that of the reciprocal of the sampling rate and a trigger was seen every time the level shifts from +DC to -DC(of the external square wave).
- But this did not completely mitigate the issues and there were still few issues on how quickly the ADC reads the signal and R Pi processes it.
- To minimize these issues completely, an edge trigger algorithm which detects a pos edge(rising) of the clock was used. The clock frequency is now equal to the reciprocal of the sampling rate. This algorithm showed better results and greatly minimized the drift of the sampling time.
Psuedo Code(code attached):
open device : FC via USB-HID;
open device : ADC via I2C;
always(for t= recording time):
read data from ADC(external clock);
if pos edge detected:
read data from FC and store it in a register;
else read data from ADC;
end
write data stored in the register to a file( can be an Epics channel or a text file);
Results:
The attached are the plots showing the time between samples for a large number of samples taken for different sampling times of the FC. The percentage error is the percentage of standard error in the timing between two samples for the data for the entire measurement. It can be inferred that this error has been cut down to the order of ms.
To do next:
- I have started taking phase measurements( analysis and plots will follow this elog) and also the PSD plots with the improved timing characteristics.
|
Attachment 1: 0.2timinganalysis.png
|
|
Attachment 2: 0.3timinganalysis.png
|
|
Attachment 3: 0.5timinganalysis.png
|
|
Attachment 4: 1stiminganalysis.png
|
|
Attachment 5: pdf.zip
|
10192
|
Mon Jul 14 12:49:07 2014 |
Nichin | Update | Electronics | New Prologix GPIB-Ethernet controller |
Quote: |
Quote: |
I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.
Static IP: 192.168.113.109
Mask: 255.255.255.0
Gateway: 192.168.113.2
I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!)
|
The instructions for adding a name to the martian DNS table are in the wiki page that I pointed you to:
https://wiki-40m.ligo.caltech.edu/Martian_Host_Table
|
The instructions at https://wiki-40m.ligo.caltech.edu/Martian_Host_Table are outdated!
The name server configuration is currently at /etc/bind/zones/martian.db [ source: elog:10067 ]
Anyway, I need superuser access to edit the files, which I don't have. Even if I did know the password, I don't think it's a good idea for me to be messing around. So any of the 40m folks please update the martian table to include:
santuzza.martian 192.168.113.109
|
10191
|
Sun Jul 13 17:06:35 2014 |
Andres | Update | 40m Xend Table upgrade | Xarm Table Upgrade Calculation and Diagrams of possible new table layout |
Current Mode Matching and Gouy Phase Between Steering Mirrors
We found in 40m elog ID 3330 ( http://nodus.ligo.caltech.edu:8080/40m/3330) a documentation done by Kiwamu, where he measured the waist of the green. The waist of the green is about 35µm. Using a la mode, I was able to calculate the current mode matching, and the Gouy phase between the steering mirrors. In a la mode, I used the optical distances,which is just the distance measured times its index of refraction. I contacted someone from ThorLabs (which is the company that bought Optics For Research), and that person told that the Faraday IO-5-532-LP has a Terbium Gallium Garnet crystal of a length of 7mm and its index of refraction is 1.95. The current mode matching is 0.9343, and the current Gouy phase between steering mirrors is 0.2023 degrees. On Monday, Nick and I are planning to measure the actual mode matching. The attached below is the current X-arm optical layout.
Calculation For the New Optical Layout
Since the current Gouy phase between the steering mirror is essentially zero, we need to find a way how to increase the Gouy Phase. We tried to add two more lenses after the second steering mirror, and we found that increasing the Gouy phase result in a dramatically decrease in mode matching. For instance, a Gouy phase of about 50 degrees results in a mode matching of about .2, which is awful. We removed the first lens after the faraday, and we added two more mirrors and two more lenses after the second steering mirror. I modified the photo that I took and I place where the new lenses and new mirrors should go as shown in the second pictures attached below. Using a la mode, we found the following solution:
label z (m) type parameters
----- ----- ---- ----------
lens 1 0.0800 lens focalLength: 0.1000
First mirror 0.1550 flat mirror none:
Second mirror 0.2800 flat mirror none:
lens 2 0.4275 lens focalLength: Inf
lens 3 0.6549 lens focalLength: 0.3000
lens 4 0.8968 lens focalLength: -0.250
Third mirror 1.0675 flat mirror none:
Fourth mirror 1.4183 flat mirror none:
lens 5 1.6384 lens focalLength: -0.100
Fifth mirror 1.7351 flat mirror none:
Sixth mirror 2.0859 flat mirror none:
lens 6 2.1621 lens focalLength: 0.6000
ETM 2.7407 lens focalLength: -129.7
ITM 40.5307 flat mirror none:
The mode matching is 0.9786. The different Gouy phase different between Third Mirror and Fourth Mirror is 69.59 degrees, Gouy Phase between Fourth and Fifth 18.80 degrees, Gouy phase between Fifth and Sixth mirrors is 1.28 degrees, Gouy phase between Third and Fifth 88.38 degrees, and the Gouy phase between Fourth and Sixth is 20.08 degrees. Bellow attached the a la Mode code and the Plots.
Plan for this week
I don't think we have the lenses that we need for this new setup. Mostly, we will need to order the lenses on Monday. As I mention, Nick and I are going to measure the actual mode matching on Monday. If everything look good, then we will move on and do the Upgrade.
|
Attachment 1: CurrentOpticalLayout.png
|
|
Attachment 2: NewSetUp.PNG
|
|
Attachment 3: AlaModeSolutionplots.png
|
|
Attachment 4: EntireScaleRangeAlaModeSolution.png
|
|
Attachment 5: NewXarmOptimizationFromFaraday.m
|
close all
clear all
% In this code we are using a la mode to optimatize the mode matching and
% to optimatize the Gouy phase between mirror 1 and mirror 2. All the units
% are in meter
w0=(50*1e-6)/sqrt(2); % The Waist of the laser measured after SHG
z0_laser=-0.0083; % position measured where the waist is located
lamb= 532*10^-9; % wavelength of green light in mm
lFaraday=.0638; % Length of the faraday
... 209 more lines ...
|
10190
|
Sun Jul 13 11:37:36 2014 |
Jamie | Update | Electronics | New Prologix GPIB-Ethernet controller |
Quote: |
I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.
Static IP: 192.168.113.109
Mask: 255.255.255.0
Gateway: 192.168.113.2
I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!)
|
The instructions for adding a name to the martian DNS table are in the wiki page that I pointed you to:
https://wiki-40m.ligo.caltech.edu/Martian_Host_Table |
10189
|
Fri Jul 11 22:28:34 2014 |
Chris | Update | CDS | c1auxex "Unknown Host" |
Quote: |
c1auxex has forgotten who it is. Slow sliders for the QPD head were not responding, so I did a soft reboot from telnet. The machine didn't come back, so I plugged the RJ45-DB9 cable into the machine and looked at it through a minicom session. When I key the crate, it gives me an error that it can't load a file, with the error code 0x320001. Looking that up on a List of VxWorks error codes, I see that it is: S_hostLib_UNKNOWN_HOST (3276801 or 0x320001)
I'm not sure how this happened. I unplugged and replugged in the ethernet cable on the computer, but that didn't help. Rana is going in to wiggle the other end of the ethernet cable, in case that's the problem. EDIT: Replacing the ethernet cable did not help.
Former elogs that are useful: 10025, 10015
EDIT: The actual error message is:
boot device : ei
processor number : 0
host name : chiara
file name : /cvs/cds/vw/mv162-262-16M/vxWorks
inet on ethernet (e) : 192.168.113.59:ffffff00
host inet (h) : 192.168.113.104
user (u) : controls
flags (f) : 0x0
target name (tn) : c1auxex
startup script (s) : /cvs/cds/caltech/target/c1auxex/startup.cmd
Attaching network interface ei0... done.
Attaching network interface lo0... done.
Loading...
Error loading file: errno = 0x320001.
Can't load boot file!!
|
We fixed this problem (at least for now) by adding c1auxex to the /etc/hosts file on chiara (following a hint from this page). The DNS setup might be the culprit here. |
10188
|
Fri Jul 11 22:02:52 2014 |
Jamie, Chris | Omnistructure | CDS | cdsutils: multifarious upgrades |
To make the latest cdsutils available in the control room, we've done the following:
Upgrade pianosa to Ubuntu 12 (cdsutils depends on python2.7, not found in the previous release)
- Enable distribution upgrades in the Ubuntu Software Center prefs
- Check for updates in the Update Manager and click the big "Upgrade" button
Note that rossa remains on Ubuntu 10 for now.
Upgrade cdsutils to r260
- Instructions here
- cdsutils-238 was left as the default pointed to by the cdsutils symlink, for rossa's sake
Built and installed the nds2-client (a cdsutils dependency)
- Checked out the source tree from svn into /ligo/svncommon/nds2
- Built tags/nds2_client_0_10_5 (install instructions are here; build dependencies were installed by apt-get on chiara)
- ./configure --prefix=/ligo/apps/ubuntu12/nds2-client-0.10.5; make; make install
- In /ligo/apps/ubuntu12: ln -s nds2-client-0.10.5 nds2-client
nds2-client was apparently installed locally as a deb in the past, but the version in lscsoft seems broken currently (unknown symbols?). We should revisit this.
Built and installed pyepics (a cdsutils dependency)
- Download link to ~/src on chiara
- python setup.py build; python setup.py install --prefix=/ligo/apps/ubuntu12/pyepics-3.2.3
- In /ligo/apps/ubuntu12: ln -s pyepics-3.2.3 pyepics
pyepics was also installed as deb before; should revisit when Jamie gets back.
Added the gqrx ppa and installed gnuradio (dependency of the waterfall plotter)
Added a test in /ligo/apps/ligoapps-user-env.sh to load the new cdsutils only on Ubuntu 12.
The end result:
controls@chiara|~ > z
usage: cdsutils
Advanced LIGO Control Room Utilites
Available commands:
read read EPICS channel value
write write EPICS channel value
switch switch buttons in standard LIGO filter module
avg average one or more NDS channels for a specified amount of seconds
servo servos channel with a simple integrator (pole at zero)
trigservo servos channel with a simple integrator (pole at zero)
audio Play channel as audio stream.
dv Plot time series of channels from NDS.
water Live waterfall plotter for LIGO data
version print version info and exit
help this help
Add '-h' after individual commands for command help.
|
10187
|
Fri Jul 11 20:05:34 2014 |
Jenne | Update | LSC | QPD dark noise checkout |
The other day, I took spectra of the Yend transmission QPD dark noise for several different configurations of the transimpedance gain and the whitening gains.
I also calculated with Optickle the expected sensitivity vs. CARM offset for the sqrtInv CARM sensor.
I put these things together to get a plot of transmission QPD noise vs. CARM offset, for a chosen set of analog settings.
Measurement of Yend transmission QPD dark noise
Since EricQ had already checked out the whitening filters (see elog 9637 and elog 9642), I didn't check on them. I just left them (the analog whitening, and the digital antiwhitening filters) on.
First, I checked the noise vs. transimpedance gain. There are a few too many settings to put them all on one plot, so I have them sorted by the original transimpedance: 0.5 kOhms vs 5 kOhms. It's a little tricky to see, but all of the spectra that begin with the 5k transimpedance have a little extra noise around 10 Hz, although I don't know why. In the legend I have made note of what the settings were. x1 x1 is my representation of the "inactive" setting.

I then looked at the noise with different whitening gain slider settings. All but one of the traces are the 20 kOhm setting.

These .xml files are in /users/jenne/Arms/TransQPDnoise_July2014/
Calculation of inverse sqrt transmission sensitivity
I used Optickle to give me the power transmitted through the ETMs. I first find the transmission in the FPMI case. I use that to normalize the full PRFPMI transmission, so that the output units are the same as our C1:LSC-TR[x,y]_OUT units.
I take the square root of the transmitted power (sum of transmissions from each arm) at each CARM offset point, add 1e-3 as we do in the front end model to prevent divide-by-zero problems, and then take the inverse.
I find the slope by taking the difference in power between adjacent points, divided by the CARM offset difference between those points.
In this plot, I have taken the absolute value of the sensitivity, just for kicks. I also display an arbitrarily scaled version of the log of the transmitted power, so that we can see that the highest sensitivity is at half the maximum power.

Calculate the QPD dark noise in terms of meters
Finally, I put it all together, and find the dark noise of the QPD in terms of meters. Since the spectra were measured in units where the single-arm transmission is unity, the already match the units that I used to calculate the sqrtInv sensitivity.
I take the spectra of the QPD dark noise for the 20 kOhm case, and multiply it by the sensitivity calibration number at several different CARM offsets. As we expect, the noise is the best at half-max transmission, where the sensitivity is maximal.

|
10186
|
Fri Jul 11 17:49:12 2014 |
Nichin | Update | Electronics | New Prologix GPIB-Ethernet controller |
I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.
Static IP: 192.168.113.109
Mask: 255.255.255.0
Gateway: 192.168.113.2
I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!)
|
10185
|
Fri Jul 11 15:29:26 2014 |
Harry | Update | General | Telescope With Collimator |
I used a la mode to make a design for the coupling telescope with a 3.3um target waist, that included the collimator in the overall design. The plot is below, and code is attached.
The components are as follows:
label z (m) type parameters
----- ----- ---- ----------
lens1 0.7681 lens focalLength: 0.5000
lens2 0.8588 lens focalLength: 0.0350
collimator 0.8832 lens focalLength: 0.0020
The z coordinates are as measured from the beam waist of the NPRO (the figure on the far left of the plot).
Moving forward, this setup will be used to couple the NPRO (more specifically, the AUX lasers) light into the SM 980 fibers, as well as to help characterize the fibers themselves.
Ultimately, this will be a key component in the Frequency Offset Locking project that Akhil and I are working on, as it will transport the AUX light to the PSL, where the two beams will be beaten with each other to generate the input signal to the PID control loop, which will actuate the temperature servos of the AUX lasers. |
Attachment 1: telescope_2.zip
|
Attachment 2: telescopeWCollimator.png
|
|