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).
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;
write data stored in the register to a file( can be an Epics channel or a text file);
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:
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.
Plans for this Week:
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).
To estimate the transfer function and the noise in the FC that is a part of the FOL-PID loop.
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:
Phase(system) =Phase(FC Signal) - Phase(Input Signal)
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.
Thanks Koji , for your hint for the brain teasing puzzle. I was looking into Filters that are usually used in devices like counters, DSO and other scopes. I found that , to improve the quality of the measurement one of the best approach is averaging. I looked deeper into averaging and found out this:
There are two general use-cases for averaging . The first, successive sample averaging, takes a single acquisition and averages between its samples. The second, successive capture averaging, combines the corresponding samples of multiple captures to create a single capture. Successive sample averaging is also called boxcar filtering or moving average filtering. In an implementation of this type of averaging each output sample represents the average value of M consecutive input samples. This type of averaging removes noise (one of the reasons the noise level was not bad: http://nodus.ligo.caltech.edu:8080/40m/10151) by decreasing the device's bandwidth(could be one of the reasons why the FC operates in 4 different frequency ranges). It applies an LPF function with a 3dB point approximated by 0.433 * s / M, where M is the number of samples to be averaged, and s is the sample rate in samples per second.
Now I tried verifying the 3 dB points in the gain plots I generated :
For 1 s Sampling time : the 3 dB point for such a Boxcar filter should be at 0.433* 1/M. If we assume that it averages for 2 samples, M=2 which gives the 3dB point at 0.288 Hz but occurs somewhere between 0.3 and 0.4 Hz. (http://nodus.ligo.caltech.edu:8080/40m/140619_120548/GainVsFreq.png)
For 0.1s Sampling time: the 3dB point should be at 2.17 Hz and in reality is 2.5 Hz(http://nodus.ligo.caltech.edu:8080/40m/140701_211904/gain.png).
Also, This type of filter will have very sharp nulls at frequencies corresponding to signals whose periods are integer sub-multiples of M/s. As seen my previous plots (http://nodus.ligo.caltech.edu:8080/40m/10118 , http://nodus.ligo.caltech.edu:8080/40m/10070) there are sharp nulls at frequencies
0.4 Hz for 1S sampling time and
at 1.5 Hz,3 Hz for 0.1 S sampling time as correctly predicted.
The moving average filter is L-sample moving average FIR, with the frequency response as: H(ω) = (1/L) (1 − e− jω L)/(1 − e− jω)..
There is an overall delay of (M - 1)/2 samples from such a length-M causal FIR filter.
The expected bode plots for such a filter with L= 5 is attached(attachment 2).
The expected bode plots for such a filter with L= 4 is attached and compared with the measured.
RXA: When comparing two things, please put them onto the same plot so that they can be compared.
Inside the 40m Lab:
As a part of installation of two(X-ARM and Y-ARM) frequency counters in the 40m, I have tested their performance when using them both on a single Raspberry Pi. The timing plots are attached. There are almost no timing issues in this configuration and it can be said that there is no harm using both of the FCs on the same platform.
We will be installing the FC box inside the lab and carry out few tests with RF mon beat note inputs.
As a part of temperature actuator characterization, today Eric Q and I made some measurements for the open loop TF of both the X-arm and Y-arm thermal actuators.
For this, we gave an input of random excitation for the temperature offset input( since we faced some serious issues when we gave in Swept sine yesterday) and observed the PZT actuation signal keeping the arm to be locked all the time of our measurements and ensuring that the PZT signal doesn't saturate.
The channels used for the measurement were C1:ALS-X_SLOW_SERVO2_EXC as the input and C1:ALS-X_SLOW_SERVO1_IN1 as the output.
The random noise used for the measurement :
Y-ARM: Gain- 6000; Filter - butterworth-first order - band-pass filter with start frequency= 1 Hz stop frequency = 5 Hz.
X-ARM: Gain -3000; Filter - butterworth- first order- band-pass filter with start frequency 3 Hz and stop frequency = 30 Hz and notch(1,10,20).
The Y-ARM measurement was stable but for the X-ARM, the PZT was saturating too often so Eriq Q went inside the lab and placed a 20dB attenuator in the path of the X-ARM PZT signal readout to carry out the stable measurements.
The units of the TF of these measurements are not calibrated and are in count/count. I will have to calibrate the units by measuring the PZT count by changing the cavity length so that I can get a standard conversion into Hz/count. I will elog the calibrated TFs in my next elog after I take the cavity length and PZT TFs.
The attached are the bode plots for both the X-ARM and Y-ARM thermal actuators(non-calibrated). I will work on finding the poles and zeroes of this system once I finish calibration of the TF measurements.
I succeeded in creating a new channel access server hosted on domenica ( R Pi) for continuous data acquisition from the FC into accessible channels. For this I have written a ctypes interface between EPICS and the C interface code to write data into the channels. The channels which I created are:
The scripts I have written for this can be found in:
db script in: /users/akhil/fcreadoutIoc/fcreadoutApp/Db/fcreadout.db
Python code: /users/akhil/fcreadoutIoc/pycall
C code: /users/akhil/fcreadoutIoc/FCinterfaceCcode.c
I will give the standard channel names(similar to the names on the channel root)once the testing is completed and confirm that data from FC is consistent with the C code readout. Once ready I will run the code forever so that both the server and data acquisition are in process always.
Yesterday, when I set out to test the channel, I faced few serious issues in booting the raspberry pi. However, I have backed up the files on the Pi and will try to debug the issue very soon( I will test with Eric Q's R Pi).
To run these codes one must be root ( sudo python pycall, sudo ./FCinterfaceCcode) because the HID- devices can be written to only by the root(should look into solving this issue).
Instructions for Installation of EPICS, and how to create channel server on Pi will be described in detail in 40m Wiki ( FOLL page).
Koji said that the method we used for X-arm thermal actuator TF measurement was not correct and suggested us to make measurements separately for high and low frequencies( ensuring coherence at those frequencies is high).
(Edit by KA: The previous measurements for X/Y arm thermal actuators were done with each arm individually locked. This imposes the MC stability to the arm motion. The MC stability is worse than the arm stability due to shorter length and more number of the mirrors. Thus the arm motions were actually amplified rather than stabilized. The correct configuration was to stabilize MC using the other arm and control the measurement arm with the arm cavity length.)
So I and Eric Q took some improved TF measurements last night for the X-arm. The input excitation and the filters used were similar to that of the previous measurement . The attached are the TF plots showing two different frequency measurements.The data was saved and will be used to generate a complete TF. The attached (TFX_new.pdf)shows the independent TF measurement for X-arm temperature actuator. The black legend shows the TF at high frequencies(>1 Hz) and the red at low frequencies(<1 Hz). The final TF plots( from the data) will be posted in my next elog.
We also made the measurements needed for calibration of these actuator Transfer functions. For this we gave some excitation for the arm length( separately for X arm and Y arm) and measured the PZT response. I will eLog with the details of the measurement and results shortly.
controls@rossa|~ 2> ls /users/akhil/fcreadoutIoc
ls: cannot access /users/akhil/fcreadoutIoc: No such file or directory
This code should be in the 40m SVN somewhere, not just stored on the RPi.
I'm still confused why python is in the mix here at all. It doesn't make any sense at all that a C program (EPICS IOC) would be calling out to a python program (pycall) that then calls out to a C program (FCinterfaceCcode). That's bad programming. Streamline the program and get rid of python.
You also definitely need to fix whatever the issue is that requires running the program as root. We can't have programs like this run as root.
I tried making these changes but there was a problem with R pi boot again.I now know how to bypass the python code using IOC.I will make these changes once the problem with the Pi is fixed.
To calibrate the measured TFs and characterize the thermal actuator for the FOL loop, we [ Me, Eric Q, Koji ] made the TF measurements of PZT response by giving a disturbance to the position of each of X and Y arm ETM and ITM.
In order to make reasonable conclusions, the measurements were done at frequencies greater than 20 Hz (assuming the PZT response to be flat till a few KHz), which is out of the bandwidth of the control loops operating for other noises at low frequencies, so that we can get the response only( mainly) due to the disturbance of the masses.
For this measurement , a Sine sweep excitation was given as an input to one of the test mass and PZT actuation signal was monitored. The channels used for the measurement are:
Input( Mirror displacement):
Output ( PZT Response):
The units of the TF of these measurements are not calibrated and are in count/count. For this I will use the ITMX and ITMY calibration values from Izumi's Elog. I will also make some calculations and post in the calibrations of ETMX and ETMY in a separate elog.
I am now estimating the calibrated Thermal Actuator TF and will estimate the location of poles and zeroes to build the PID loop. I will elog the final calibrated TFs in my next elog.
The attached are the Bode Plots for ETM and ITM for X and Y arms.
Work Completed :
- Transfer Function
- Quantization Noise Estimation
EPICS and Channel Readout:
Frequency Offset Locking(FOL) Box Design and Plan:
Work Plan for Upcoming Weeks:
The ultimate goal of characterizing the temperature actuator turned to be fruitful in obtaining the calibration values for ETMX and ETMY (Calibration of ITMs were done previously here but not for ETM). In this process, I measured the PZT response by displacing one of the test masses in the frequency range of 20 Hz and 900 Hz and measured the transfer functions in counts/counts.
ETMX = [12.27 x 10 -9/ f2 ] m/count
ETMY = [14.17 x 10 -9/ f2] m/count
I calculated these calibration values from the measurements that we have taken( in detail : elog) and did the following calculations:
The measurements I made were :PZT count/ Actuator Count separately for all the test masses.
PZT count/ Actuator count = [PZT count/ arm cavity displacement(m) ]*[ displacement of a test mass(m) / Actuator Count]
For a same laser and assuming flat response of the PZT, the term [PZT count/ arm cavity displacement(m) ] remains for all the test masses.
The fitting was done on the gain plots of the PZT Response vs Test mass displacement and a function G * f ^-2 was fitted. The resulting G values were:
ETMX: 8.007* f ^-2
ITMX: 3.067* f ^-2
ETMY :11.389* f ^-2
ITMY : 3.745* f ^-2
To calculate the calibration of ETMX:
[PZT count/ Actuator count : ETMX ] / [ displacement of a test mass(m) / Actuator Count :ETMX] = [PZT count/ Actuator count : ITMX ] / [ displacement of a test mass(m) / Actuator Count :ITMX]
putting the values from the above fitting and Kiwamu's elog,
the calibrated value was calculated to be [12.27 * 10^-9 /f^-2 ]m/count.
A similar calculation was done for ETMY.
The attached are the fitting plots for the measurements taken.
Now using these and the previously measured calibrations, I will get the complete calibrated TF of the thermal actuator.
Plan for the week:
Inside the Lab:
The goal of the measurements we made ( my previous 3 elogs) was to characterize the laser frequency thermal actuator that is a part of the FOL- PID loop.
For this we made indirect TF measurements for the thermal actuator by looking at the PZT response by 1)arm cavity( ETM ,ITM) displacement and 2) temperature offset excitation. The goal was to do something like getting G1=TF3/TF1 and G2=TF3/TF2 and ultimately dividing G2/G1 to get TF2/TF1 with correct calibration. The final TFs obtained are the X and Y arm TFs for Laser frequency response vs temperature offset in(HZ/count). The calculations in detail are:
Obtained G1 = PZT response/ Temperature Offset (count/count): (in detail here )
Obtained G2 = PZT response/ X and Y arm displacement( count/ count) : (in detail here)
Calibrated G2 to count/m ( in detail here)
Divided G2/G1 to get X and Y arm displacement/ Temperature Offset( m/ count) to get G3
Did these calculations:
dL/ L = dF /F
F = c/lambda ;Lambda = 532 nm ; L =
X arm length = 37.79 +/- 0.05 m
Y arm length = 37.81 +/- 0.01 m
TF: Laser Freq/ Temperature Offset = G3 *F/L (HZ/Count)
The calibration coefficients for the ends are :
X End: [23.04 +/- 0.23 ]* 10^3 (HZ/Count)
Y End: [18.71 +/- 0.2 ]* 10^3 (HZ/Count)
For the TFs of the temperature actuator on laser frequency I used ITMs for both the arms. The bode plots for the calibrated( HZ/Temp Count) are attached.
For the X-Arm Thermal Actuator, I calculated the TFs at two different frequency ranges and combined the results where the coherence is high(>0.7). At 1 Hz the coherence was not as good as the other frequencies(due to the suspension resonance at 0.977 Hz).
The poles and zeroes are estimated after fitting this data using Matlab vectfit tool.The graphs showing fit and measured values are attached.
Y arm Thermal Actuator:
5th order TF fitted:
z1 = -0.9799;
z2 = 2.1655;
z3 = -2.9746- i * 3.7697
z4 = -2.9746+ i * 3.7697
z5 = 95.7703 + 0.0000i
p1 = -0.0985- i* -0.0845
p2 = -0.0985+ i* -0.0845
p3 = -0.6673- i* -0.7084
p4 = -0.6673+ i* -0.7084
p5 = -8.7979.
X-arm Thermal Actuator:
Gain = 20
z2 = -18.2774
z3 = -16.6167
z4 = -1.2486
z5 = 28.1080
p1 = -0.1311 - 0.1287i
p2 = -0.1311 + 0.1287i
p3 = -8.3797 + 0.0000i
p4 = -4.0588 - 7.5613i
p5 = -4.0588 + 7.5613i
I will use get the poles and zeroes from these fitted bode plots and use it to build the PID loop.
Koji asked me to get the calibration of the PZT counts to Volts for the the X and Y ends. Yesterday, I went inside the lab and took some measurements from the digital readout of the PZT by giving in a DC offset(-5 to +5 volts) to PZT_Out and read out from these channels:
For X-end: C1:ALS-X-SLOW_SERVO1_IN1
For Y-end: C1:ALS-Y-SLOW_SERVO1_IN1
Since a 20dB attenuator was placed in the path of X-arm readout while taking the Transfer functions(Detail), I did the calibration measurements without removing it from the path. However, for the Y arm there was no attenuator in the readout path.
The obtained calibration values are :
X- arm PZT : [146.3 +/- 2.37 ] counts/Volt
Y- arm PZT : [ 755.1 +/- 3.6] counts/Volt
The attached are the fit and data plots for the above calibration.
The PZT seems to saturate at around +/- 3500 counts. So for the Y arm, I excluded the saturated points and fitted the data points again.
As for the calibration number, we expect the 3276.8 count/V for +/- 10 V range of a 16 bit ADC but the number is ~800 count/V. I couldn't figure out a reason why the number is so different.
The new calibration values are :
X- arm PZT : [146.3 +/- 2.37 ] counts/Volt (with a 20 dB attenuator included in the path)
Y- arm PZT : [ 797 +/- 3.6] counts/Volt
I will get the calibration in MHz/V of PZT actuation and check whether these numbers make any sense.
The PZT actuation on the laser frequency in MHz/V ( assuming the previous calibration here of the PZT count/V) is :
X- arm: 33.7 MHz/V
Y- arm: 14.59 MHz/V
This number seems to be wrong by a factor of 10.
So we[I and EricQ] decided to trace the cables that run into the ADC from the PZT Out. We found a black LEMO box in the path to ADC,which is an anti-aliasing filter for each input channel. However,in theory the response of this filter should be flat up until a few kHz i.e. for the DC gain it should be 1. But we will manually test it and look at the DC gain of the LEMO box.
Finally, the efforts put in the Frequency Counter paid off . I tested the working of both the FC and EPICS channels that I created by displaying the beat note on MEDM screens. EricQ helped me locking the X arm ( Y arm free) thus acquiring only the X arm beat note from the frequency counter. We plotted the beat note on MEDM and clearly could see a stable beat note when the arm was locked. Now it can be said that the FC(two of course) can replace the spectrum analyzer outside and also get the beat-note frequencies into EPICS channels. The channel names of these two beat note frequencies are:
X Arm: C1:ALS-XBEAT_FREQ_MHZ
Y Arm: C1:ALS-YBEAT_FREQ_MHZ
(Note: There are many problems in alignment of the arms and we could have beat note only for some time after putting a lot of effort).
Today I and EricQ went inside the lab and set up the cables running from the a DAC channel into PZT input so that we can use the PID controller to tune in the PZT offset to maintain the beat note within a detectable range (This is plan B as the main plan of actuating on the laser temperature can be achieved only after the fiber setup with the PSL is ready). I obtained all the poles and zeroes of plant and started designing a PID loop to test it with the existing system.
I will put in my PID values into the already existing PERL controller code (that is used for controller design in the 40m) and run tests with the PID loop while actuating on the PZT offset.
The scripts written for interfacing the FC with R Pi, building EPICS database, piping data into EPICS channels,PID loop for FOL are contained in :
The instructions to run these codes on R Pi( controls@domenica) will be available on FOL 40m wiki page.
Also instructions regarding EPICS installation on R Pi and building an EPICS SoftIoc to streamline data from hardware devices into channels will be updated shortly.
The attached in a zip file are the Simulink feedback loop models for the FOL for both X and Y ends. The controller PID values are estimated by setting a temperature count reference point to 5344, which corresponds to 100 MHz frequency. The plant transfer function is as calculated in my previous elogs.
We were not able to test the PID loop , with the green laser by PZT actuation because of the misalignment of the arms and non-existence of the beat note since last few days. However, we have a complete idea of the design and PID parameters that will be used for the FOL with infrared laser. So we decided that it would be better to test the loop by temperature actuation after the fiber optics is installed and the coupling of infrared laser into the fiber is complete. As of now, we have planned to place the FOL box inside so that it can be used to obtain the green laser beat note on the StripTool graphs.
The beams from the Innolight and Lightwave NPROs were both incident on a 1GHZ New Focus PD. Mott and I swept the temperature of the Lightwave and tracked the change in frequency of the beatnote between the two. The Innolight temperature was set to 39.61C although the actual temperature was reported to be 39.62C.
Freq. vs temperature is plotted below in the attached PDF. The slope is 2.8GHz/K.
The data is in the attached MATLAB file.
Same thing for the Innolight Mephisto.
Not unexpected values with dn/dT around 11E-6 K^-1 and coefficient of thermal expansion = 8E-6 K^-1 and a laser resonator length of order 10cm.
Please put those numbers onto wiki somewhere at the green page or laser characterization page.
Kiwamu and I looked at all the electronics that are currently in place for the green locking on the X-arm and have made a set of block diagrams of the rack mounted units that we should build to replace the existing ... "works of art" that sprawl around out there at the moment.
1. "ETM Green Oscillator/PDH support box". Not a great name but this would provide the local oscillator signal for the end PDH (with a controllable phase rotator) as well as the drive oscillator for the end laser PZT. Since we need to hit a frequency of 216.075kHz with a precision that Kiwamu needs to determine, we'd need to be able to tune the oscillator ... it needs to be a VCO. It'd be nice to be able to measure the output frequency so I've suggested dividing it down by N times to put it into the DAQ - maybe N = 2^7 = 128x to give a measured frequency of around 1.7kHz. Additionally this unit will sum the PDH control signal into the oscillation. This box would support the Universal PDH box that is currently at the X-end.
2. "Vertex X-arm beatnote box" - this basically takes the RF and DC signals from the beatnote PD and amplifies them. It provides a monitor for the RF signal and then converts the RF signal into a square wave in the comparator.
3. "Mixer Frequency Discriminator" - just the standard MFD setup stored in a box. For temperature stability reasons, we want to be careful about where we store this box and what it is made of. That's also the reason that this stage is separated from the X-arm beatnote box with it's high-power amps.
4. RS232 and EPICS control of the doubling ovens
5. Intensity stabilization of the End Laser
P.S. I used Google Diagrams for the pictures.
Skip to final thought ...
Kiwamu and I have set about measuring the contrast of the signal on the RF PD. We can only do this when the end green laser is locked to the cavity. This is because the green transmission through the cavity, when unlocked, is too low. Unfortunately, once we lock the green beam to the cavity, we can't keep the beatnote on the RF PD stable to within a few hundred Hz of DC (remember that the cavity is swinging around by a couple of FSRs). So we also lock the PSL to cavity.
At this point we're stuck because we can't get both of these beams resonant within the cavity AND have the frequency difference between them be less 1kHz - when the lasers are locked to the cavity, their frequencies are separated by an integer number of FSRs + a fixed frequency offset, f_offset, that is set by the phase difference on reflection from the coating between the two wavelengths (532nm and 1064nm). We can never get the frequency difference between the lasers to be less than this offset frequency AND still have them both locked to the cavity.
So our contrast measuring method will have to use the RF signal.
So this is our method. We know the incident power from each beam on the RF PD (see Kiwamu's elog entry here), but to recap,
P_green_PSL = 72 uW (as measured today)
P_green_XARM = 560 uW (as measured by Kiwamu last week).
The trans-impedance of the RF PD is 240 Ohms. We'll assume a responsitivity of 0.25 A/W. So, if the XARM transmission and PSL green beams are perfectly matched then the maximum value of the RF beat note should be:
RF_amplitude_max = 2* SQRT(P_green_PSL*P_green_XARM) * responsivity * transimpedance = 240*0.25*2*(72E-6*560E-6)^(1/2) (volts)
= 24 mV = -19.5 dBm (or 27.5dBm after the +47 dB from the two ZFL-1000LN+ amplifiers - with +15V in - that protrude from the top of the PD)
The maximum RF strength of the beat-note that we measure is around -75 dBm (at the RF output of the PD). This means the contrast is down nearly 600x from optimal. Or it means something is broken.
Final thought: at the end of this procedure we found that the RF beat note amplitude would jump to a different and much higher amplitude state. This renders a lot of the above useless until we discover the cause.
The attached table shows the amplitude of the green beat note when the end laser was in various states. We can increase the beat note amplitude dramatically by switching to a different states.
C1:GCX-GRN_REFL_DC: 638 counts
C1:GCV-XARM_BEAT_DC: (PSL blocked) 950 avg counts (zero = -794 counts)
amplitude of beat note: -23dBm (after PD + amps) (f ~ 30 MHz)?
C1:GCX-SLOW_SERVO2_OUT: 318 counts
C1:GCX-GRN_REFL_DC: 180 counts
C1:GCV-XARM_BEAT_DC: (PSL blocked) 1270 avg counts (zero = -794 counts)
C1:GCV-XARM_BEAT_DC: (PSL unblocked) 1700 avg counts (zero = -794 counts)
amplitude of beat note: -7dBm (after PD + amps) f = 60MHz
amplitude of beat note: 0dBm (after PD + amps) f = 30MHz
C1:GCX-SLOW_SERVO2_OUT: 290 counts
C1:GCX-GRN_REFL_DC: 220 counts
C1:GCV-XARM_BEAT_DC: (PSL blocked) 1120 avg counts (zero = -794 counts)
C1:GCV-XARM_BEAT_DC: (PSL unblocked) 1520 avg counts (zero = -794 counts)
amplitude of beat note: 0dBm (after PD + amps) f = 15MHz
C1:GCX-SLOW_SERVO2_OUT: 305 counts
PSL temp = ??
C1:PSL-FSS_SLOWM = -3.524
We've set up a preliminary test bed for the phase camera. It simply uses a HeNe that is split into two beams. One is frequency shifted by an AOM by -40 MHz - df, where df is some acoustic frequency. The second beam is transmitted through a 40MHz EOM to get sidebands. The two beams are recombined and are, currently, incident on a photodetector, but this can be replaced by the phasecamera.
We turned everything on with df = 1kHz and confirmed that a 1kHz signal is visible on the output from the photodetector (PD). The signal looks to be about 1:300 of the DC level from the PD.
Joe and I built a very simple digital frequency to amplitude converter using the RCG. The input from an ADC channel goes through a filter bank (INPUT), is rectified and then split in two. One path is delayed by one DAQ cycle (1/16384 s) and then the two paths are multiplied together. Then the output from the mixer goes through a second filter bank (LP) where we can strip off twice the beat frequency. The DC output from the LP filter bank should be proportional to the input frequency.
Input Channel: C1:GFD-INPUT_xxx
Output Channel: C1:GFD-LP_xxx
Joe compiled the code and we tested it by injecting a swept sine [100, 500]Hz in the input filter bank. We confirmed that output of the LP filter bank changed linearly as a function of the input frequency.
The next thing we need to do is add a DAC output. Once that's in place we should inject the output from a 4kHz VCO into the ADC. Then we can measure the transfer function of the loop with an SR785 (driving the VCO input and looking at the output of the DAC) and play around with the LP filter to make sure the loop is fast enough.
The model is to be found here:
The attached figures show the model file in Simulink and a realtime dataviewer session with injecting a swept sine (from 500Hz to 100Hz) into the INPUT EXC channel. We've had some frame builder issues so the excitation was not showing on the green trace and, for some reason, the names of the channels are back to front in dataviewer (WTF?), - the lower red trace in dataviewer is actually displaying C1:GFD-LP_OUT_DAQ, but it says it is displaying C1:GFD-INPUT_OUT_DAQ - which is very screwy.
However, the basic principle (frequency to amplitude) seems to work.
One more thing ... we can calibrate the output of the LP filter to give a result in Hz with the following calibration:
LP_OUT = -1/(2*dt)*(LP_IN -1), where dt is 1/16384, the delay time of the delayed path.
Therefore LP_OUT = -8192*(LP_IN-1).
Aidan: Joe and I have added a channel that takes the DC output from the vertex beatnote PD and sends it, via RFM, to a DAC at the ETMX end. Immediately before the output is a filter C1GCX_AMP_CTRL. The output of the DAC is connected to the CURRENT LASER DIODE modulation input on the back of the Innolight driver. This will modulate the current by 0.1A/V input.
We should be able to modulate the green laser on the end now and stabilize the intensity of the amplitude on the beatnote PD at the vertex. (In this configuration, the ampltiude noise of the PSL laser will be injected onto the end laser - we may want to revisit that).
Joe's comments on model change:
I added a RFM connection at the output of the C1:GCV-XARM_BEAT_DC filter in the c1gcv model. The RFM connection is called: C1:GCV-SCX_ETMX_AMP_CTRL.
This RFM connection goes to the c1scx model and into Kiwamu's GCX box, which uses top_names. There's a filter inside called AMP_CTRL, so the full filter name is C1:GCX-AMP_CTRL. The output then goes to the 7th DAC output.
There are 3 standard techniques to reduce this effect:
1) Stabilize the end laser by sensing the green light coming into the PSL before recombination and feeding back with SR560 (this is the only one that you should try at first).
The reason that I chose this PD is that, apparently, the green light coming from the cavity is clipped when it is picked off for its DC PD.
Jenne, Koji and I assembled the Covesion Oven today, inserted a PPKTP crystal from Raicol, aligned the crystal to a 50mW focus and
got some green beam coming out.
Covesion Oven assembly
The oven contains a brass clip that can clamp a crystal up to 10mm wide x 0.5mm high x 40mm long (according to the instructions). According to the correspondence from Covesion the clip can accomodate a crystal up to 1.5mm high. Our crystal is 1mm x 1mm x 30mm.
Alignment of the crystal to the focus
The oven was mounted on a 4-axis Newport translation stage. We plonked the assembly onto the table, removed the lid and adjusted the rough position so that a focus of the 1064nm beam, from a 100mm lens, was positioned near the center of the crystal - then it was clamped down to the table. From here we adjusted the alignment of the stage, using an IR card and a viewer to guide us, until we eventually saw some green beam coming out. We were all very excited by this! We optimized the alignment as best we could using the IR card and then we replaced the lid on the oven. At this point the temperature of the PPKTP was around 26.5C and the green beam coming out look quite dim. We turned the oven up to around 36 degC and observed the beam getting much brighter and we approached the optimum phase-matching condition.
We haven't done anyway quantitative measurements yet but we were pleased with how easy this first stage was.
[Edit by Koji] More photos are on Picasa album
I spent some time tracking down the AS beam which had vanished from the AP table. Eventually, by dramatically mis-aligning SRM, PRM and ITMY, returning BS to its Jan 1st PITCH and YAW values and tweaking the ITMX alignment [actual values to follow], I was able to get an AS beam out onto the AP table. I verified that it was the prompt reflection off ITMX by watching it move as I changed the YAW of that optic and watching it stay stationary as I changed the YAW of ITMY.
Jamie and I then steered the beam through a 2" PLCX-50.8-360.6 lens and placed the RF PD (AS55) at the focus. Additionally, we installed the AS camera to observe the leakage field through a Y1S steering mirror (as shown in the attached diagram).
Currently the PD has power but the RF and DC outputs are not connected to anything at the moment.
Atm 2 by Steve
AS port ITMX YAW range where AS beam was visible = [-1.505, -1.225] - these extrema put the beam just outside of some aperture in the system -> set ITMX YAW to -1.365
ITMX PITCH range = [-0.7707, -0.9707] -> set to ITMX PITCH to -0.8707
I was investigating the beat note amplitude on the vertex PD again yesterday. The incident power on the PD was 150uW in the PSL green beam and 700uW in the X-ARM green beam. With perfect overlap and a transimpedance of 240, I expected to get a beat note signal of around 25mV or -19dBm. Instead, the size was -57dBm. Bryan and I adjusted the alignment of the green PSL beam to try and improve the mode overlap but we couldn't do much better than about -50dBm. (The noise floor of the PD is around -65dBm).
When we projected the beams to the wall of the enclosure, the xarm beam was 2 to 3x as large as the PSL green beam, indicating that the beam size and/or curvatures on the PD were less than ideal. There is a telescope that the XARM beam goes through just before it gets to the PD. I mounted the second lens in this telescope on a longitudinal translation stage. With some finagling of the position of that lens we were able to improve the beatnote signal strength to -41dBm.
Obviously the ideal solution would be to measure the beam size and RoC of the PSL beam and XARM beams and then design a telescope that would match them as precisely as possible because there's still another 20dB signal strength to be gained.
I measured the scatter from the eLIGO beam dumps as best I could. The experiment setup is shown in the attached diagram.
After familiarizing myself with the equipment in the morning I noticed three issues with the setup
1 - around the minimum scatter the back scatter from the beam dump is very susceptible to the incident angle (makes sense since the Si plate inside the beam dump at Brewster's angle when there is minimum scatter).
2 - The mirrored plug (Part 20 in D0900095) which is suppose to be used for alignment is not very effective. It moves around too much in its hole in the front face of the beam dump. Just by touching it I could make the reflected beam jump around by about 0.1 radians.
- I think to align these properly we'll have to partly assemble the dumps. If we leave off the front plate of the horn then we can measure the reflection off the Si. If we measure this with a power meter then alignment becomes a simple matter of rotating until this reflection is minimized.
3. - For this measurement the incident beam was a small (~ 1mm diameter) central beam with a small amount of spray of laser light beyond that central region. This spray was hitting the aluminium front face of the beam dump and was scattering back to the photodiode. This was clearly the limiting factor in the measurement. Most of this light was spread horizontally so I placed a couple of pieces of black glass on either side of the aperture, just blocking the edges a little. This reduce the background reading at the minimum scatter from 17.0uV to around 4.5uV with still a little bit of light hitting the top and bottom of beam dump face.
The incident power on the beam dump fluctuated a little but was in the range 20.5 to 22mW. The response of the PD is approximately 0.2 A/W and the transimpedance is 7.5E4 V/A.
The SR830 Sensitivity was set to 1x1 mV.
It was difficult to measure the actual angle of incidence. The dump pivoted about a point directly under the input aperture at the front. By measuring the displacement of a point on the back of the dump as I rotated it and knowing the distance between this point and the pivot point I was able to make a reasonably accurate measurement of a range of angles about the minimum.
The measured scatter (in V measured directly by the PD and as a fraction of the incident power) is shown in the attached plots.
I think I can do a better job cleaning up the incident beam - so these numbers only represent an upper limit on the scatter.
attachment 1: beam dump assembly
attachment 2: experimental layout
attachment 3: scatter measurement
attachment 4: BRDF - (scatter divided by the solid angle = 1.1 m steradians)
attachment 5: (slightly blurred )photo of dump - overhead view
See Adhikari eLOG entry: http://nodus.ligo.caltech.edu:8080/AdhikariLab/194
The elog crashed when I was uploading a photo just now. I logged into nodus and restarted it.
Koji asked me to take a profile of the output of the 1W NPRO that will be used for green locking. I used the razor-scan method, plotting the voltage output of a PD vs the position of the razor across the beam, both vertically and horizontally. This was done at 6 points along the beam path out of the laser box.
I determined the beam spot size at each point by doing a least-squares fit on the plots above in Matlab (using w as one of the fitting parameters) to the cumulative distribution functions (error functions) they should approximate.
I then did another least-squares fit, fitting the above "measured" beam profiles to the gaussian form for w vs z. Below is a summary.
It seems reasonable, though I know that M2 < 1 is fishy, as it implies less divergence than ideal for that waist size. Also, like Koji feared, the waist is inside the box and thus the scan is almost entirely in the linear regime.
There is a clearly a difference in the divergence angle of the x and y beams - maybe 10-20%. Since the measurements are outside the Rayleigh range and approximately in the linear regime, the slope of the divergence in this plot should be inversely proportional to the waists - meaning the x- and y- waist sizes should differ by about 10-20%. You should check your fitting program for the waist.
Jenne, Koji and I opened up the package from Raicol and examined the crystals under the microscope. The results were mixed and are summarized below. There are quite a few scratches and there is residue on some of the polished sides. There is a large chip in one and there appear to be gaps or bands in the AR coatings on the sides.
There are two albums on Picassa
1. The package is opened ...
2. The crystals under the microscope.
Here is Crystal 724 polished side 2 with all photos along the length stitched together
Here's a photo of the set-up used. The beam profile is measured relative to the f=-100mm lens.
I had a think about the algorithm we might use for the phase camera measurement. MATLAB has an fft function that will allow us to extract the data that we need with a single command.
We record a series of images from a camera and put them into a 3D array or movie, image_arr, where the array parameters are [x-position, y-position, time], i.e. a 2D slice is a single frame from the camera. Then we can do an FFT on that object with the syntax, f3D = fft(image_arr, [ ], 3), which only does the FFT on the temporal components. The resulting object is a 3D array where each 2D slice is an 2D array of amplitude and phase information across the image for a single temporal frequency of the movie.
So if we recorded a movie for 1s where the sample rate is 58Hz, then the 1st frame of f3D is just a DC image of the movie, the 2nd frame are the complex 1Hz components of the movie, etc all the way up to 29Hz.
Suppose then that we have a image, part of which is being modulated, e.g. a chopper wheel rotating at 20 or 24Hz, or a laser beam profile which contains a 1kHz beat between a sideband and a reference beam. All we have to do is sample at at least twice that modulation frequency, run the command in MATLAB, and then we immediately get an image which contains the phase and magnitude information that we're interested in (in the appropriate 2D slice o the FFT).
As an example, I recorded 58 frames of data from a camera, sampling at 58Hz, which was looking at a spinning chopper wheel. There was a white sheet of paper behind the wheel which was illuminated from behind by a flashlight. The outer ring was chopping at 24Hz and the inner ring was chopping at 20Hz. I stuck all the images into the 3D array in MATLAB, did the transformation and picked out the DC, 20Hz and 24Hz signals. The results are shown in the attached PDFs which are:
You can, and I have, run the MATLAB engine from C directly. This will allow you to transfer the data from the camera to MATLAB directly in memory, rather than via the disk, but it does need proper memory allocation to avoid segmentation faults - that was too frustrating for me in the short term. In this case, the 58 frames were recorded to a file as a contiguous block of data which I then loaded into MATLAB, so it was slower than it might've otherwise been. Also the computer I was running this on was a bit of a clunker so it took a bit of time to do the FFT.
The data rate from the camera was 58fps x (1024 x 1024) pixels per frame x 2 bytes per pixel = 116MB per second. If we were to use this technique in a LIGO phase camera, where we want to measure a modulation which is around 1kHz, then we'd need a sample rate of at least 2kHz, so we're looking at at least a 30x reduction in the resolution. This is okay though - the original phase camera had only ~4000 spatial samples. So we could use, for instance, the Dalsa Falcon VGA300 HG which can give 2000 frames per second when the region of interest is limited to 64 pixels high.
Andri and I mounted the Raicol Crystal #724 in one of the new Covesion Ovens. The procedure was the same as before - see elog entry here.
There was one issue - the glass plate that goes on top of the crystal is coated on one side with ITO (Indium-Tin Oxide) and it's not 100% certain that this was mounted in the correct orientation. It is virtually impossible to tell which side of the glass is coated.
The base plate of the oven was tapped for an M3 hole. We retapped it for an 8-32 and bolted it to a post and that one of the New Focus 4-axis translation stage. The assembly is currently bolted to the PSL table, awaiting use.