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.
I was giving a tour of the 40m yesterday. We were looking at the PSL table. About 30 seconds after I turned the lights on a glass cover from one of the lights (NW corner) popped out of its holder and smashed on the table.
I've cleaned up all the broken glass I could see but there may be some small shards there. Please use caution in that area.
Is this a setpoint temperature that we can change by writing to the channel or is it a readout of the actual temperature of the oven?
This is a readout channel just to monitor the actual temperature.
We added a channel on c1psl in order to monitor the temperature of the PPKTP sitting on the PSL table.
We found the beat at 1064nm. T(PSL)=26.59deg, T(X-end)=31.15deg.
The X-end laser was moved to the PSL table.
The beating setup was quickly constructed with mode matching based on beam profile measurements by the IR cards.
We used the 1GHz BW PD, Newfocus #1611-FS-AC.
As soon as we swept the Xtal temp of the X-end laser, we found the strong beating.
finally we found it !
I've been trying to get a PID loop running for the green locking and I've discovered that some of the directories in the path for the Perl Modules are now obselete. Specifically, since the scripts directory has been moved from /cvs/cds/caltech/scripts to /cvs/cds/rtcds/caltech/c1/scripts the following locations in the Perl @INC path list need to be changed:
I've added the above directories to the PERL5LIB path in /cvs/cds/caltech/cshrc.40m.
setenv PERL5LIB /cvs/cds/caltech/scripts/general:
nodus:~>perl -e 'user EpicsTools'
I've set up a PID script that senses the EX-PSL Green Beat note (from the frequency counter) and actuates on the temperature of the end laser to drive the beat note to a given setpoint.
Right now the script only passes the initial sanities checks, that is:
The settings all need to be tuned up - e.g. maximum_increment, hard_stops, time_step, PID constants.
Additionally, the units in the whole thing are pretty useless - some of the channels are in VOLTS, others in WATTS. I'd like to change all these to be in Hz.
EPICS channels added:
Yeah. Joe and I rebooted c1psl a couple of times this morning. I didn't realize the burtrestore wasn't automatic.
Has C1PSL rebooted? Has burtrestore been forgotten? Even without elog?
We found some settings are wrong and the PMC has pretty low gain.
Kiwamu and I roughly calibrated the analogue output from the SR620 frequency counter yesterday. The input channel, intuitively named C1:PSL-126MOPA_126MON, now reads the measured frequency in MHz with an error of about 0.1MHz - this is, I think, due to the bit noise on the D/A conversion that Kiwamu discovered earlier. That is, the output range of the SR620 corresponds to around 100MHz and is digitized at 10-bit resolution, and ...
100MHz/(10^2) ~= 0.098MHz. [Sad Face]
We set the EPICS range to [-100, 100] (corresponding to [-5V, 5V]), connected a Marconi to the Freq Counter, input a variety of different frequencies and measured the counts on the EPICS channel.
The linear fit to the calibration data was F = 2.006*EPICScount - 0.2942. From this we worked out the maximum and the minimum for the range settings that give the channel in MHz: EGUF = -200.8942 and EGUL = 200.3058. The previous range was [-410, 410]
I restored C1:PSL-126MOPA_126MON to its original settings (EGUF = -410, EGUL = 410) and added a new calc channel called C1:LSC-EX_GRNBEAT_FREQ that is derived from C1:PSL-126MOPA_126MON. The calibration in the new channel converts the input to MHz.
field(DESC,"EX-PSL Green Beat Note Frequency")
field(SCAN, ".1 second")
I rebooted c1psl and burtrestored.
The PID loop is ready to be run on the green beat note but, since the tanks are open, there is no green transmission from the end getting to the PSL table. Nevertheless, here's the screen for the PID loop. The loop script is still in my directory /cvs/cds/caltech/users/abrooks/GRNXSlowServo
The medm screen is attached. It shows the current beat note frequency in MHz ()
In c1auxey/ETMYaux.db I added a couple of channels. These are all displayed on the MEDM screen. I added them to autoBurt.req as well.
I rebooted c1auxey to get these to work.
Once we get the green beat back again, the PID loop should servo on the end laser temperature to drive the Beat Frequency to the Frequency Setpoint, C1:LSC-EX_GRN_PID_SETPT, which can be set by the pink slider.
RA: All MEDM screens must be in the proper MEDM directory!! Also, all perl scripts must have a .pl extension!!! Also, all scripts must be in the scripts directory even if they are in development!!! And all scripts should use 'env' rather than have absolute pathnames for the location of perl, csh, tcsh, python, etc.
That's not unreasonable. But if we try
grep "perl" /cvs/cds/rtcds/caltech/c1/scripts/*/*
grep "perl" /cvs/cds/rtcds/caltech/c1/scripts/*/*
you can see that we've got a fair amount of housekeeping to attend to. We might want to think about tidying up the scripts directory as part of the cds upgrade.
Good news. I feel multi-chromatic-locking success is just around the corner.
By the way, there's a new presentation on the DCC from the ANU group where they've locked a short single cavity with both colors - G1000735:
[Koji, Osamu and Kiwamu]
We aligned the beam axis pointing down to both X and Y arm.
Now the beams are hitting the centers of both ETMX and ETMY.
Amazingly Osamu made X arm flashing by aligning the cavity.
Kiwamu and I plugged the output from a DS3456 function generator into the ADC and started recording the data. The func. generator output a 237.8Hz, 1Vpp sine wave. We chose this value because it corresponds to the FSR of a 38.5m cavity (=3.896MHz) divided by 2^14, the frequency divider amount we intend to use.
Since 1 FSR divided down is 237.8Hz and corresponds to a length change of the cavity of 532nm/2 = 266nm, then we can, roughly, say that a frequency change of 1Hz corresponds to a length change in the cavity of approximately 1nm. The width of the 237.8Hz peak in the spectra corresponds to an upper limit on the noise floor due to digitizing the signal (this could be limited by the ADC, or the function generator, or the windowing on the FFT).
The FWHM of the peak in the spectrum was approximately 5mHz, corresponding to an uncertainty in the length of the cavity of about 6pm (we used a Hanning Window, 50% overlap and a BW of 2.92mHz, 7 averages). Regardless of what is the dominant contribution to the width of the peak, this implies that the frequency noise associated with digitizing a signal in the ADC is much smaller than we require and will not limit our performance if we choose to use a frequency divider and digital PLL with the Green Locking.
RA: Here's the previous measurement
If we use a digital PLL for locking the frequency of the PSL and END green lasers then we can expect a UGF of around 1kHz (assuming a sampling rate of 16kHz). Let's assume a simple 1/f loop giving a loop gain of ~1000x at 1Hz. If the free-swinging ETM pendulum motion at 1Hz is of the order of 1 micron, then the residual motion at 1Hz, once we lock the digital PLL by actuating on the ETM position, will be of the order of 1nm. This is bordering on too high.
Alternatively, is we use an analogue PLL then we can expect a much higher UGF and many orders of magnitude more gain at 1Hz (see here). So we would expect the residual motion of the pendulum to be much smaller - probably limited by some other noise source somewhere in the system (I doubt it's going to be reduced by 12 orders of magnitude).
RA: I think ballpark's not good enough for this. To see what's good enough, we need to to an analysis similar to what Bram has for the ALS. Get the 40m seismic spectrum from the arm locking spectrum or the green laser feedback signal and then correct it for a realistic loop shape.
KA: For this purpose I have made the simulink model for the green locking more than a year ago, but the entire green team has consistently neglected its presence...
KA: For this purpose I have made the simulink model for the green locking more than a year ago, but the entire green team has consistently neglected its presence...
Agreed. It doesn't completely rule out the digital PLL. I'll check out Kiwamu's model.
Whether or not it's as clean as we'd like, it's really nice to see this result with real data.