You don't need the fourth glass piece on the diamond beam dump.
Paco accidentally clicked on C1:SUS-MC1_UL_TO_COIL_SW_1_1 (MC1 POS to UL Coil Switch) and clicked it back on. We didn't see any loss of lock or anything significant on the large monitor on left.
< Two inspection people taking pictures of ceiling and portable AC unit passed. They rang the doorbell but someone else let them in. They walked out the back door.>
The alignment of the pick-off mirror near ETMX is done. Everything turned out to be easy once we realized that there is no sense getting the alignment laser (going through viewport to pick-off to ITMX) back to ETMX. It is only necessary to hit ITMX somehow, since this makes sure that there is one scattered beam that will make it from ITMX to pick-off through viewport.
After the auxiliary optic (that we never used in the end) was removed again, we levelled the optical table.
So in the current setup, we can have small-angle scattering measurements on ITMX and large-angle scattering measurements on ETMX.
This is how it was envisioned. The video camera was in nobodies mind to look through the 40 mm diameter hole than.
Rana is proposing 50 mm hole in the baffle plate that is attached to the tower. Atm1
Atm2 is showing the back side where the solid line is 40 mm
Green welding glass is used in these Koji designed dumps (D1102375)
We have 10 pieces of hexagonal dumps for 5.5" high beam They require 1 5/8" space. Atm1
Atm2, Large V traps are 3" tall only, 5 pieces
Atm3, Diamond shapes come with 2" and 1" square green glass ( after Koji's correction I removed the not needed glass ) D1102445 and D1102442
Baked green glass pieces in stock: 30 pieces of 2" x 2" ,--- 30 pieces of 1" x 1",David 4-17-2014
Baked diamond holders in stock: 10 pieces of 2" and 10 pieces of 1"David 4-17-2014
PEEK shims 2" and 1"
Baked green glass pieces blank: 4 pieces of 7" x 9"
Baked green glass pieces with 40 mm hole on 7" x 9" for SUS tower: 7 pieces.
NOTE: in December 2012 we talked about 50 mm aperture need. What diameter is the right one today? 51 mm aperture plates are cut 4-10-2014
Zeroth order IMC ringdown setup
Following Gautam's IMC ringdown setup, I took the REFL PD form the PMC ringdown experiment and installed it in the IMC REFL path blocking WFS2 (Attachment 1).
I also ran a BNC cable from the transmission PD that Gautam installed on the IMC table to the vertex where the signals are measured on the scope.
I offloaded the WFS servo output values onto the MC alignment (using the WFS servo relief script) so that its dc values would be correct when the servo is off.
Unfortunately, it seems like the script severely misaligned the MC mirrors at some point when the MC got unlocked. We should fix the script such that it stops when the offloading is complete.
We got the MC realigned but left it in a state where it is not locking easily.
I used D1400293 to get the latest logged details about the universal PDH box used to lock the green laser at X end. The uPDH_X_boost.fil file present there was used to obtain the control model for this box. See attachment one for the code used. Since there is a variable gain stage in the box, I tuned the gain of the filter model F_AUX in ALS_controls.yml to get the maximum phase margin in the PDH lock of the green laser. Unity gain frequency of 8.3 kHz can be achieved in this loop and as Gautam pointed out earlier, it can't be increased much further without changes in the box.
The ALS control model remains stable with a reduction in total estimate noise because of the above update. There are few things to change though:
Gautam will soon follow up with detailed analysis, but here is a brief summary of some of our activities and findings.
Please note that there is a long BNC cable still laid out from the IOO rack area to the X end table; watch your step!
With the Y end laser, I was able to lock the PLL with a lower actuation range (1.6MHz/V), and with the PSL in both the free-running and MCL locked configurations.
I took spectra (attached) with the same actuation range (3.2 MHz/V) for the AUX X+PSL and AUX Y+PSL combinations (PSL shutter closed) just to keep things consistent. It looks like there is hardly any difference between the two combinations - could the apparent factor of 3 worse performance of the X end laser have been due to different actuation ranges on the Marconi?
I've not managed to take a spectrum for the proposed replacement Lightwave laser on the PSL table, though with Eric's help, I've managed to find the beatnote (at a temperature of 53.0195 degrees). I had to do some minor alignment tweaking for this purpose on the PSL table - the only optics I touched were the ones in the pink beam path in attachments 1 and 2 in this elog (the setup used to make the measurement is also qualitatively similar to attachment 3 in the same elog, except for the fact that we are feeding back to the Marconi and not the laser - a detailed sketch with specific components used will be put up later). I'll try and measure the frequency noise of this laser as well over the weekend and put up some spectra.
With regards to possibly switching out the Lightwave on the PSL table for the (faulty?) Innolight at the X end, I've verified the following:
It remains to characterize the beam coming out from the Lightwave laser and do a mode matching calculation to see if we can use the same optics currently in place (with slight rearrangement) to realize a satisfactory mode-matching solution - I've obtained a beam profiler to do this from Liyuan and have the software setup, but have yet to do the beam scan - the plan is to do this on the SP table, but we've put off moving the Lightwave laser off the PSL table until we (i) establish conclusively that the X end laser is malfunctioning and (ii) check the frequency nosie of the Lightwave relative to the Aux lasers currently at the ends.
The area around the Marconi is in a little disarray at the moment with a bunch of cables, SR560s, analyzers etc - I didn't want to disconnect the measurement setup till we're done with it. I have however turned both IR beat PDs on the PSL table off, and have reconnected the Marconi output to the Frequency Generation Unit and have set the carrier back to 11.066209MHz, +13dBm.
EDIT 01/12/2016 6PM: I've updated the plots of the in-loop spectra such that they are calibrated throughout the entire domain now. I did so by inferring the closed-loop transfer function (G/(1-G)) from the measured open-loop transfer function (G), and then fitting the inferred TF using vectfit4 (2 poles). The spectra were calibrated by multiplying the measured spectra by the magnitude of the fitted analytic TF at the frequency of interest.
EricQ brought back one of the Marconis that was borrowed by the Cryo lab to the 40m today (it is a 2023B - the Marconi used for all previous measurements in this thread was 2023A). Koji had suggested investigating the frequency noise injected into the PLL by the Marconi, and I spent some time investigating this today. We tried to mimic the measurement setup used for the earlier measurements as closely as possible. One Marconi was used as a signal source, the other as the LO for the PLL loop. All measurements were done with the carrier on the signal Marconi set to 310MHz (since all our previous measurements were done around this value). We synced the two Marconis by means of the "Frequency Standard" BNC connector on the rear panel (having selected the appropriate In/Out configurations digitally first). Two combinations were investigated - with either Marconi as LO and signal source. For each combination, I adjusted the FM gain on the Marconi (D in the plot legends) and the overall control gain on the SR560 (G in the plot legends) such that their product remained approximately constant. I measured the PLL OLG at each pair to make sure the loop shape was the same throughout all trials. Here are the descriptions of the attached plots:
Attachment #1: 2023A as LO, 2023B as source, measured OLGs
Measured OLG for the various combinations of FM gain and SR560 gain tested. The UGF is approximately 30kHz for all combinations - the exceptions being D 1.6MHz, G=1e4 and D=3.2MHz, G=1e4. I took the latter two measurements just because these end up being the limiting values of D for different carrier frequencies on the Marconi.
Attachment #2: 2023A as LO, 2023B as source, measured spectra of control signal (uncalibrated above 30kHz)
I took the spectra down to 2Hz, in two ranges, and these are the stitched versions.
Attachment #3: 2023B as LO, 2023A as source, measured OLGs
Attachment #4: 2023B as LO, 2023A as source, measured spectra of control signal (uncalibrated above 30kHz)
So it appears that there is some difference between the two Marconis? Also, if the frequency noise ASD-frequency product is 10^4 for a healthy NPRO, these plots suggest that we should perhaps operate at a lower value of D than the 3.2MHz/V we have been using thus far?
As a quick trial, I also took quick spectra of the PLL control signals for the PSL+Aux X and PSL+Aux Y beat signals, with the 2023B as the LO (Attachment #5). The other difference is that I have plotted the spectrum down to 1 Hz (they are uncalibrated above 30Hz). The PSL+Y combination actually looks like what I would expect for an NPRO (for example, see page 2 of the datasheet of the Innolight Mephisto) particularly at lower frequencies - not sure what to make of the PSL+X combination. Also, I noticed that the amplitude of the PSL+Y beatnote was going through some large-amplitude (beat-note fluctuates between -8dBm and -20dBm) but low frequency (period ~10mins) oscillations. This has been observed before, not sure why its happening though.
More investigations to be done later tonight.
I took several measurements today using the revised PLL scheme of using the Marconi just as an LO, and actuating on the Laser PZT to keep the PLL locked (I will put up a sketch soon). On the evidence of the attached plots (spectra of PLL control signal), I guess we can conclude the following:
Attachment #2: Measured OLG of PLL for the PSL+X and PSL+Y combinations. The UGF in both cases looks to be above 100 kHz, so I didn't do any calibration for the spectra attached. The gain on the SR560 was set to 200 for all measurements.
Attachment #3: Measured spectra of PLL control signal for various diode currents, with one reading from the PSL+Y combination plotted for comparison. When we took some data last night, Eric noted that there was a factor of ~6 increase in the overall frequency spectrum level at higher currents, I will update the plots with last night's data as well shortly. I found it hardest to keep the PLL locked at a diode current of 2.00 A across all measurements.
Attachment #4: Measured spectra of PLL control signal at two different crystal temperatures. There does not seem to be any significant dependance on temperature, although I did only do the measurement at two temperatures.
Attachment #4 Attachment #1: All the data used to make these plots (plus some that have yet to be added to the plots, I will update them).
Unrelated to this work:
When I came in this afternoon, I noticed that the PMC was unlocked. The usual procedure of turning the servo gain to -10dB and playing around with the DC output adjust slider on the MEDM screen did not work. Eric toggled a few buttons on the MEDM screen after which we were able to relock the PMC using the DC output adjust slider.
Retraining the MCL filters resulted in a slight improvement in the performance. Compared to no FF, the RMS in the 0.5-5 Hz range is reduced by approximately a factor of 3.
Attachment #1 shows my re-measurement of the MC2 position drive to MCL transfer function.
Attachment #2 shows the IIR fits to the FIR filters calculated here.
Attachment #3 shows several MCL spectra.
Conclusions + next steps
For all the loops where we drive the NPRO PZT, there is some notch/resonance feature due to the PZT mechanical resonance. In the IMC loop this limits the PZT/EOM crossove to be less than 25 kHz. I don't have a model for this, btu it should be included.
If you hunt through the elogs, people have measured the TF of ALS NPRO PZT to phase/frequency. Probably there's also a measured ALS PDH loop somewhere that you could use to verify your model.
The guy from KroneCrane (sp?) came today and started the crane inspection on the X End Crane. There were issues with our crane so he's going to resume on Monday. We turned off the MOPA fur the duration of the inspection.
The plan is that they will bring enough weight to test it at slightly over the rating (1 Ton + 10 %) and we'll retry the certification after the oiling on Monday.
The south end crane has one more flaw. The wall cantilever is imbalanced: meaning it wants to rotate south ward, because its axis is off.
This effects the rope winding on the drum as it is shown on Atm2
Atm1 is showing Jay Swar of KoneCrane and the two 1250 lbs load that was used for the test. Overloading the crane at 125% is general practice at load testing.
It was good to see that the load brakes were working well at 2500 lbs. Finally we found a good service company! and thanks for Rana and Alberto
for coming in on Saturday.
Jeff Stinson, technician of KoneCrane inspected the south end crane hoist gear box. This was the one that was really low on oil. The full condition require
~ 950cc of EPX-7 (50-70W) high viscosity gear oil. The remaining 120 cc oil was drained and the gear box cover was removed. See Atm 1
He found the gear box, load brake and gearing in good condition. The slow periodic sound of the drive was explained by the split bearings at Atm 3
The Vertex and the east end crane gear boxes needed only 60 cc oil to be added to each Atm 4 and their drives were tested.
Conclusion: all 3 gear boxes and drives are in good working condition.
Tomorrow's plan: load test at 1 ton and correct-check 3 phase wiring.
Atm1, service report: load test were performed at max horizontal reach with 1998 lbs ( American Ton is 2000 lbs)
Vertical drives and brakes worked well. The 5 minutes sagging test showed less than 1 mm movement .
The wiring is correct. Earlier hypothesis regarding the wiring ignored the mechanical brake action.
Our cranes are certified now. Operator training and SOP is in the work.
Vertex Folding I -beam will get latch-lock and the south end I-beam will be leveled.
Atm2, south end
Atm3, east end
Atm4, folding crane at ITMX at 14 ft horizontal reach
yes, its fine to use this with a level 3 or level 7 mixer; let's see some PM transfer functions !
Is this sufficient enough for the mixer to work?
What does OAF stand for? The entry doesn't say that. Also the acronym is not in the abbreviation page of the wiki.
Can anyone please explain that?
I am Aakash Patil. I will be working at the 40m lab as a SURF student with Gautam Venugopalan on enclosures for seismometers to shield them from thermal and magnetic fluctuations. This week I will be working on the development of hardware for four probe measurement along with a constant current source. It will effectively help us in accurate temperature measurement throughout the development of enclosure.
Me and Gautam yesterday opened the tilt-free seismometer enclosure to see if we could use the thermocouples and
other things previously used by Megan. But we are planning to get new four-wire RTDs for our work.
For the next day or two, I will be trying to set up Acromag Busworks terminal so that the data logging during
this enclosure development experiment becomes perfect and easy. Johannes has sent me the wiki page URL for the same.
Today I tried to setup Acromag Busworks card. I was able to calibrate and test it over USB but I couldn't test it over ethernet. I'll utilize a few hours tomorrow to test it over ethernet and see if I can make it work. I have also found a few RTDs which I want to use for temperature sensing via four probe method. So, tomorrow I'll get these RTD details revived by Gautam and Steve.
I was wondering if we have a basic DAQ card with maybe 4 channels which is simple to setup like NI DAQ cards.
About acquiring data: Initially I couldn't start with proper Acromag setup as the Raspberry pi had a faulty SD card slot. Then Gautam gave me a working pi on which I tried to install EPICS. I spent quite a time today but couldn't setup acromag over ethernet. But, it would be great if we have a USB DAQ card. I have found a good one here http://www.mccdaq.com/PDFs/specs/USB-200-Series-data.pdf It costs around 106$ including shipping (It comes with some free softwares for acquiring data) . Also, I know an another python based 12bit DAQ card (with an inbuilt constant current source) which is made by IUAC, Delhi and more information can be found here http://www.iuac.res.in/~elab/expeyes/Documents/eyesj-progman.pdf It costs around 60$ including shipping.
About temperature sensing: The RTD which I found on Omega's list is having a temperature resolution of 0.1 deg C. I have also asked them for the one with good resolution. Also according to their reply, they have not performed any noise characteristics study for those RTDs.
The existing enclosure for seismometer at LIGO 40m lab is a cylindrical stainless steel can placed upside down over the seismometer. It has more empty space between the seismometer and the internal surface of enclosure which is not desirable(I'll quantitatively elaborate this statement once my temperature measuring setup is ready).
Stainless steel has a thermal conductivity in the range of 16.3 to 16.7 W/m/K and magnetic permeability 1.260e-6 H/m.Assuming an ambient temperature 298K, and the temperature inside the enclosure as 295K, as well as substituting all the values for dimesions and material properties of existing enclosure,
k=16.4 W/mK, μ=1.260e-6 H/m, L=2ft=0.6096m, b=r2 =0.5ft=0.1524m, thickness=5mm, a=r1 =0.1474m.
So by using the textbook relations(I have mentioned them in my report), the value of attenuation coefficient is 5.953584e-05 and the value of rate of heat transfer= 5.64913 kW. The attenuation coefficient value is quite better for steel but proper care needs to be taken to avoid heat transfer. For studying the variation of rate of heat transfer and attenuation with the thickness of enclosure material, I have plotted the following attached graphs for different materials which include hardened stainless steel, aluminium, pure iron and nanoperm-muMetal.
About Data Acquisation
I have already invested a lot of time to configure and use acromag busworks card over ethernet. So now I have made an arrangement to measure temperature by AD592CNZ temperature transducer IC. I would be using raspberry pi for acquiring data untill I figure out a way to use acromag busworks card for the same. This setup of acquiring logging temperature using raspberry pi is mostly ready except the calibration part.
I have taken out the heaters and temperature sensors from the enclosure which was made by Megan last summer. Soon I will test and configure those heaters.
I have transferred most of the temperature measurement stuff from the front area to seismometer at the end of Y-arm. While arranging the components I have taken all care that they will not interfere with existing system. Also, I have temporarily taken a monitor from the front area to the area near same seismometer as I couldn't talk to Rpi via ssh. For next twelve hours, I am now recording temperature inside as well as outside the seismometer enclosure. Some temperature sensors are inside the enclosure while some are outside the seismometer enclosure.
I am using AD592CNZ temperature transducer ICs for measuring temperature inside as well as outside the enclosure. It is a current output IC which outputs current proportional to temperature. As mentioned in the data sheet of AD592, I am using the following two schematics:
Though I still need to calibrate these temperature transducers, I did some measurements. I have temperature readings, and now my goal in few days is to find a transfer function of temperature fluctuations inside the enclosure to outside the enclosure.
About data acquisition:
We have re-configured the raspberry pi(B8:27:EB:70:D0:D8) on martian network. It's new ip address is 192.168.113.107(domenica.martian). Also, we have added the Acromag Busworks card(00:01:C3:00:9F:C8) on the martian network and its ip address is 192.168.113.237(acroey.martian).
Acromag is talking now, after few changes to the original EPICS configuration and cross compile configuration. Modbus config files also were changed and compiled again to run it on linux-arm architecture. I have made use of pyModbus for the final work and I am planning to use the same for grabbing channels. Though I am unable to grab channel data right now, I am able to communicate to it over ethernet and send and receive data.
Aidan has described the physical connections and initial setup here : https://nodus.ligo.caltech.edu:30889/ATFWiki/doku.php?id=main:resources:computing:acromag#recovering_from_a_terminal_power_communication_outage .
Since I used a Raspberry Pi(domenica.martian) for communicating to Acromag(acroey.martian) card, I had to recompile everything for linux-arm architecture.
For EPICS installation, download the EPICS base from http://www.aps.anl.gov/epics/download/base/baseR184.108.40.206.tar.gz . Installing dependencies, build, install epics at /usr/local/epics. By downloading modbusApp source from https://llocds.ligo-la.caltech.edu/daq/software/source/epics-220.127.116.11_long-source.tar.gz , build the modbusApp for linux-arm architecture in modules/modbus directory inside epics base.
Put all the files mentioned by Aidan and run a tmux session to grab channels.
Also, pyModbus can be used to read the channels. I'll put the physical connections schematic shortly.
I took off the silicon rubber heaters which were used by a SURF last year for heating the enclosure. The heater data sheet has mentioned the power dentsities, but I doubted the values. So I wanted to measure the actual power density by these heaters. I think the rubber heaters are broken somewhere within, the surface is not heated evenly. Although I don't have a good quantative reason to use, I was thinking to use a thermoelectric cooling module for the enclosure.
From the data I collected few days back, I am trying to obtain a transfer function of temperature inside the enclosure to that of outside. My aim is to measure the pole frequency of temperature fluctuations inside the enclosure relative to the outside fluctuations.
I have measured the transfer function of temperature fluctuations inside the enclosure to that of the temperature fluctuations outside. The transfer function has been estimated by using 'tfestimate' which is library function in Matlab and which estimates the transfer function based on Welch's method. The attached plots shows the transfer function of the temperature inside the enclosure to that of outside temperature.
In order to determine a relation between temperature inside the enclosure to that of the outside temperature, I have calculated the mean squared coherence. I have used Matlab's 'mscohere' library function which uses Welch's method to calculate the coherence. Attached plot shows the coherence between the temperature across the enclosure.
Also, I have attached the matlab script which I used for generating these plots.
%temperature data outside the enclosure on channel 2
%temperature data inside the enclosure on channel 3
%sampling frequency in Hz
I have made the changes as suggested by Gautam.
Please find the new attached plots and the new script.
I tried to recompile the modbusApp binary for linux-arm acrhitecture since I suspected someting wrong with it. But still the problem persists; I can connect to acromag but cannot access the channels. I have also reconfigured new acromag bus works terminal XT 1221-000 and I want to test if I could access its channels. My target is to complete this acromag setup work before sunday morning so that I can focus towards having some useful results for my presentation.
There were many unknown and unsolved problems with using modbusApp for linux-arm architecture. So I tried to install the necessary files to setup Acromag Busworks card 1221-000 on Zita(192.168.113.217), which is a linux-x86_64 machine on the martian network. After installing a few dependencies and seting up few symbolic links for some libraries, everything is successfully configured. Initially I was unable to run myiocconfig.cmd file(as mentioned by Aiden on ATF wiki page) due to a undefined macro error for envset. Later I found that this error might be due to THIS bug in epics base. So, I removed the first four lines of that given code and directly referenced the .db file's location and it worked.
Now, I am facing another issue while running this file but on different line. Random symbols are returned on the last second line of the file each time I run it. I have attached the screenshots of those errors. I tried changing the encoding of the file several times but still it is showing the same error.
Lydia helped me to troubleshoot the Accromag connection problems which I was facing previously. If power goes off/turned off manually, the ethernet cable has to be pulled out and put back again until only a non-blinking green light is observed. I was foolish enough that I did not use secure power connections. About the random symbol, a code block was not closed in the other supporting file which was being called in the main program. There are still some port errors and register errors, which I would work on later tonight.
I've taken the FSS frequency generation box out of the 1Y1 rack. It's sitting on one of the electronics benches. I'm measuring its phase noise.
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.
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.
% plot the data from the Lightwave Temperature sweep
% Lightwave temperature
LWTemp = [0.2744
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.
% load a raw data file into MATLAB
fid = fopen('phase_camera_data.dat');
n1 = 750;
A3D = ones(n1, n1, 58);
for jj = 1:58
A = fread(fid, [1024, 1024], 'uint16');
A3D(:,:,jj) = A((512-floor(n1/2)):(512-floor(n1/2))+n1-1, ...
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.