Good job Q! Give us more details please or play Rachmaninoff Piano Concernto #2
Atm2, EQ 3.5 and 4.1
confirming ITMX is really free
Taking inspiration from J. Lewis et. al, ITMX has been freed.
I tried aligning the green beam, elliptical as it is, to the arm by using the various steering mirrors after the doubling oven. The following was done:
kicks ITMX-UL magnet into stuck position.
Hopefully it is only sticking.
I measured the guralp raw outputs and the TFs using the handheld unit and an FFT analyzer.
The handheld unit was connected to each guralp with the same cable which is confirmed t be functional with the Yend Guralp.
The signal for Z, N, and E directions are obtained from the banana connectors on the handheld unit. Each direction has mass, low gain velocity, and high gain velocity output. The PSDs of the signals were measured with an FFT analyzer. The transfer function from the mass signal to the low/high gain signals were also measured for each direction.
The adjustment screw for the E output of the Xend does not work. I had to tilt the Xend Guralp using the leg screws to bring the E signal to zero.
Attachment 1: Raw voltage PSD for all outputs
Attachment 2: Comparison of the low gain vel outputs
- All of the mass output show similar PSDs.
- Low gain velocity outputs shows somewhat similar levels. I still need to check if the output is really the ground velocity or not.
- High gain velocity outputs are either not high gain, broken, or not implemented.
- We need to calibrate the low gain output using signal injection, huddle test, or something else.
Attachment 3: TFs between each mass output and the low or high gain outputs
- TFs between the mass signal and the low vel signals show the similar transfer functions between the channels.
- The high gain outputs show low or no transfer function with regard to the mass signals.
Eric and I spent some time yesterday night trying to recover the green in the arm after the laser swap. The problem essentially was that though I was getting ~800uW of green out of the doubling oven, the mode wasn't clean, and hence, the beam profile looked really messed up just before entering the arm cavity.We got to a point where we thought we were getting a good mode out of the doubling oven (as judged by propagating this beam onto the wall with the help of a mirror). But we were only getting ~400uW of green power. I tried tweaking the alignment of the oven on the 4 axis stage for a while, but was not able to improve the situation much. So I decided to start from scratch:
I am beginning to wonder if this ellipticity is inherent from the IR beam from the laser? My beamscan results suggest that the beam is more divergent in the "P direction" as compared to the "S direction", which is borne out by these photographs. And if this is indeed the case, do we need to add cylindrical lenses to correct this?
Unrelated to this work: The ITMX Oplev seems to have wandered off so the X arm won't lock. I am not realigning the Oplev for now, but am turning the ITMX Oplev servo off for the night.
Perhaps related to my work on the endtable: The ETMX oplev MEDM readings seemed to be frozen, though there was red light on the QPD on the endtable. Checking the CDS overview screen, I saw that all models on c1iscex had crashed. I sshed into c1iscex and restarted all the models, but the IOP block remained red. I checked the datetime, and found that this was wrong - so I followed the instructions here, but the "Diag Word" block remains red. I am shutting down the watchdog for ETMX and leaving this as is for now... This seems to have happened before...
I manually aligned the IMC. Spot positions are all < 1.5mm. PMC trans of ~0.74, MC2 Trans of ~15400, MC Refl ~0.4, which is better than its been for some time now.
Somehow the WFS DC offsets were off, which made it look like it was impossible to center the beam on WFS2. The script for setting these wasn't working so I fixed it, ran it. WFS and MC2 trans offsets were set, WFS are back on and have been holding MC REFL nice and low for ~3 hours.
Arms were dither aligned, wrote the offsets to SDF files. Oplevs need centering. No further daqd crashes.
daqd has indeed continued to be unstable. I found system times had drifted apart again... I think something weird happened in the booting of the frontends. The monit processes were not running on any of the frontends. I ntpdate'd again, and manually started monit on each fronted via sudo /etc/init.d/monit start.
sudo /etc/init.d/monit start
TP3 drypump replaced after 10,344 hrs at 750 mTorr foreline pressure.
The foreline pressure is 13 mTorr after 8 hrs of running, TP3: 50K rpm, 0.14 Amp with all annuloses pumped.
The annulos pressures are 0.3 - 5 mtorr
Frame builder just crashed again
I was able to realign the arms, lock them, and have run the dither align to maximize IR transmission - looks like things are back to normal now. For the Y-end, I used the green beam initially to do some coarse alignment of the ITM and ETM, till I was able to see IR flashes in the control room monitors. I then tweaked the alignment of the tip-tilts till I saw TEM00 flashes, and then enabled LSC. Once the arm was locked, I ran the dither align. I then tweaked ITMX alignment till I saw IR flashes in the X arm as well, and was able to lock it with minimal tweaking of ETMX. The LSC actuation was set to ETMX when the models were restarted - I changed this to ITMX actuation, and now both arms are locked with nominal IR transmissions. I will center all the Oplev spots tomorrow before I start work on getting the X green back - I've left the ETM Oplev servos on for now.
While I was working, I noticed that frame builder was periodically crashing. I had to run mxstream restart a few times in order to get CDS back to the nominal state. I wonder if this is a persistent effect of the date/time issues we were seeing earlier today?
Chiara reports an uptime of >195 days, so its UPS is working fine
FB, megatron, optimus booted via front panel button.
Jetstor RAID array (where the frames live) was beeping, since its UPS failed as well. The beep was silenced by clicking on "View Events/Mute Beeper" at 192.168.113.119 in a browser on a martian computer. I've started a data consistency check via the web interface, as well. According to the log, this was last done in July 2015, and took ~19 hrs.
Frontends powered up; models don't start automatically at boot anymore, so I ran rtcds start all on each of them.
rtcds start all
All frontends except c1ioo had a very wrong datetime, so I ran sudo ntpdate -b -s -u pool.ntp.org on all of them, and restarted the models (just updating the time isn't enough). There is an /etc/ntp.conf in the frontend filesystem that points to nodus, which is set up as an NTP server, but I guess this isn't working.
sudo ntpdate -b -s -u pool.ntp.org
PMC locking was hindered by sticky sliders. I burtrestored the c1psl.snap from Friday, and the PMC locked up fine. (One may be fooled by the unchanged HV mon when moving the offset slider into thinking the HV KEPCO power supplies need to be brought down and up again, but it's just the sliders)
Mode cleaner manually locked and somewhat aligned. Based on my memory of PMC camera/transmission, the pointing changed; the WFS need a round of MC alignment and WFS offset setting, but the current state is fine for operation without all that.
Pasadena reported the Sunday night event as a power transient caused by the trip of a power transmission line. This affected the entire city. Once the loss was detected, the system automatically switches to an alternate source. It was about one second for the system to recover.
2W Innolight, both Lightwaves at the ends, PSL HEPA, Ref Cavity and 3 AC units turned on.
The 40m vacuum did not trip. It is vacuum normal.
The Jetstore computer is indicating power failer.
Looks like that's the case. LIGO GC also sent an e-mail that there was a popwer glitch.
I came into the 40m a few minutes ago, and noticed the following (approximately in this order):
To investigate further, I checked today's summary pages, and whatever caused this, happened around 730am today morning (approx 5 hours ago). I also saw that all the watchdogs were tripped, except MC3, BS and SRM.
I then tracked down the beeping - I believe that it is coming from Megatron.(in fact, it is coming from the Jetstor..)
I also found that the PSL is OFF, and the Marconi, though ON, has the display parameters set to values that I normally see when it is first turned ON (i.e. the carrier frequency is 1200MHz, the output is -140dBm etc - this is what led me to suspect that somehow the power connection was interrupted? As far as the workstation computers are concerned, I don't think ROSSA was affected, but pianosa is frozen and donatella is at the login screen. The CDS overview MEDM screen refuses to load correctly (though some of the other MEDM screens are working fine). I'm not entirely sure how to go about fixing all of this, so for now, I'm leaving the PSL off and I've shutdown the remaining watchdogs.
It just occurred to me to check the status of the vacuum - the MEDM screen seems to suggest everything is fine (see Attachment #1). I went down to the X end to do a quick check on the status of the turbo pumps and everything looks normal there...
800e-6 / 0.225^2 = 0.016
I thought Kiwamu had roughtly 2%/W.
After carefully tweaking the mode-matching of the IR into the crystal and the four-axis translation stage on which the doubling oven is mounted, I managed to recover 800uW of green power going into the green Faraday. Considering we have ~225mW of IR power coming out of the IR faraday (and roughly that amount going into the SHG crystal), I'd say this is pretty consistent (if not slightly better) with a recent power budget I had made for the X end. The amount of green power we get out of the doubling crystal is very sensitive to the alignment of the crystal to the beam axis. I suspect we could improve the situation slightly if the mode-matching lenses were mounted on translational stages so we could tweak their position, but the current situation on the X endtable does not provide space for this. In any case, I'd say we are at least as good as we were before, and so this should be an adequate fix until the new end-table is installed (though I don't know why we aren't seeing the predicted SHG conversion efficiency of 3-4% as predicted by Kiwamu's calculations, we are getting more like .36% conversion efficiency)...
Because the alignment of the beam before the doubling oven had changed, I had to adjust the steering mirrors to make the green beam go into the green faraday. I had placed a couple of irides for the green beam as a reference of the old path into the arm, and I used these to adjust some of the green mirrors to center the green beam on these. However, I did not observe any flashes in the arm. I will check if we are still mode-matched to the arm, and if the lenses downstream of the doubling oven need to be moved....
It shipped out for repair evaluation.
Arrived to Hayward,CA 2016Feb16
what is next?
Atm 3, Ron Drever could not celebrate with us because of health issues.
After the discussion at the meeting, I decided to go ahead and open the top of the oven so that I could get a visual on where the crystal was located - this helped in the alignment, and I was able to get some green light out of the oven. I had to tweak the position of the Doubling oven a little (with the top open) in order to align the crystal to the beam axis. However - I was only able to get ~140uW of green light going into the Faraday. I had measured the power at various points along the beam path recently with the old setup. We used to have ~860uW of green going into the Faraday there. To see if I could improve the situation a little, I checked that the beam was reasonably centered on both apertures of the IR Faraday, and then removed the irides upstream of the doubling oven. These were preventing me from placing the lenses exactly as per the a la mode solution. Once the irides were removed, I moved the lenses to their optimal positions as best as I could with a tape measure to mark out distances. I then further tweaked the position of the doubling oven using the 4 axis stage, monitoring the green power while doing so. The best I could get was ~200uW. Perhaps the positions of the lenses need to be optimized further. I also checked the IR power before and after the IR Faraday - these numbers are ~260mW and ~230mW respectively (I maximized the transmitted power through the Faraday by rotating the HWP, the QWP that was in the beam path has now been removed as the Lightwave outputs linearly polarized light), and compare favourably to the numbers in the old setup. Doing a naive scaling accounting for the fact that we have less power going into the doubling crystal, I would expect ~700uW of green light coming out, so it looks like the mode matching into the doubling crystal is indeed sub-optimal. However, now that things are roughly aligned, I hope the optimization will go faster...
Some updates on the laser swap situation:
2. Implementing the new solution:
As I check the manual of the Innolight (pg17) and the datasheet of the Lightwave, I wonder if the Quarter Wave Plate that was placed immediately after the Innolight laser head is even necessary now - I assume the purpose of the combination of QWP+HWP was to turn the elliptically polarized light from the Innolight into linearly polarized light before the Faraday. But the Lightwave already produces linearly polarized light. I will check out what is the configuration on the Y-end table...
Steve pointed me to an old elog by Zach where he had measured the waist of the 1W Innolight NPRO. I ran a la mode with these parameters (and the original optics in their original positions prior to last night's activities), and the result is in reasonably good agreement (see Attachment #1) with my initial target waist of 35 um at the center of the doubling oven (which I presume coincides with the center of the doubling crystal). The small discrepancy could be due to errors in position measurement (which I did by eye with a tape measure) or because I did not consider the Faraday in the a la mode calculation. However, I wonder why this value of 35 um was chosen? In this elog, Kiwamu has determined the optimal waist size to be 50um at the center of the doubling crystal. Nevertheless, as per his calculations, the doubling efficiency should be non-zero (about 1% lower than the optimum conversion efficiency) at 35um or 70um, so we should be able to see some green light as long as we are in this fairly large range. So perhaps the fact that we aren't seeing any green light is down to sub-optimal alignment? I don't think there is a threshold power for SHG as such, its just that with lower input power we expect less green light - in any case, 200mW should be producing some green light... From what I could gather from a bunch of old elogs by Aidan, the Raicol PPKPT crystals have dimension 1mm x 1mm x 30mm (long axis along beam propagation), so there isn't a whole lot of room for error perpendicular to the direction of propagation... I wonder if it is possible, for the initial alignment, to have the top cover of the doubling oven open so that we can be sure we are hitting the crystal?
Tonight we embarked on the laser swap. In short, we have gotten ~210mW through the faraday doubler, but no green light is apparent. The laser outputs ~300mW, so it's not exactly a work of art, but I still expected some green. More work remains to be done...
Gautam took numerous photos of the table before anything was touched. One lens was swapped, as per Gautam's plan. The innolight laser and controller are on the work bench by the end table. The lightwave is on the table and on standby, and is not hooked up to the interlock mounted on the table frame, but instead one below the table directly next to the controller. The ETMX oplev laser is turned off.
I looked in the optics cabinet to see what lenses we have available, and re-ran the mode-matching calculation to see if we could find a better solution - I'm attaching a plot for what looks like a good candidate (optimized mode-matching efficiency for the X mode is 100%, and for the Y mode, it is 97.98%), though it does involve switching "L1", which is currently a 175mm efl lens, for a 125mm efl lens. I've also indicated on the plot where the various other components are relative to the optimized positions of the lens, and it doesn't look like anything is stacked on top of each other. Also, the beam width throughout is well below 4.7mm, which is the maximum cited width the Faraday can handle, as per its datasheet. "L1" doesn't quite get the waist of the beam to coincide with the geometrical center of the Faraday, but I don't think this is requried? Also, I've optimized the mode matching using the measured X width of the beam (red curve in Attachment #1), and have overlaid the calculated Y width of the beam for the optimized position of the lenses (red curve in Attachment #1). The target waist was 35um at the center of the doubling oven, which the X profile achieves, but the Y profile has a width of 32 um at the same point.
In all the calculations, I've not accounted for possible effects of the HWPs and the Faraday on the beam profile....
No sign of damage
I've done a first pass at trying to arrive at a mode-matching solution for the X-end table once we swtich the lasers out. For this rough calculation, I used a la mode to match my seed beam (with z = 0 being defined as the shutter housing on the current position of the Innolight laser head, and the waist of the beam from the NPRO being taken as the square-root of the X and Y waists as calculated here), to a target beam which has a waist of 35um at the center of the doubling oven (a number I got from this elog). I also ignored the optical path length changes introduced by the 3 half-wave plates between the NPRO and the doubling oven, and also the Faraday isolator. The best a la mode was able to give me, with the only degrees of freedom being the position of the two lenses, was a waist of 41um at the doubling oven. I suppose this number will change once we take into account the effects of the HWPs and the Faraday. Moreover, the optimized solution involves the first lens after the NPRO, L1, being rather close to the second steering mirror, SM2 (see labels in Attachment #2, in cyan), but I believe this arrangement is possible without clipping the beam. Moreover, we have a little room to play with as far as the absolute physical position of the z=0 coordinate is - i.e. the Lightwave NPRO head can be moved ~2cm forward relative to where the Innolight laser head is presently, giving a slightly better match to the target waist (see attachment #3). I will check the lenses we have available at the 40m to see if a more optimal solution can be found, but I'm not sure how much we want to be changing optics considering all this is going to have to be re-done for the new end table... Mode-matching code in Attachment #4...
Steve thinks that the X-end Innolight does not come with the noise-eater option (it is an add-on and not a standard feature, and the purchase order for the PSL Innolight explicitly mentions that it comes with the NE option, but the X-end Innolight has no such remarks), which would explain why there is no difference with the noise eater ON/OFF. During earlier investigations however, I had found that there was a cable labelled "Noise-Eater" connected to one of the Modulation Inputs on the rear of the Innolight controller. Today, we traced this down. The modulation input on the rear says "Current Laser Diode 0.1A/V". To this input, a Tee is connected, one end of which is terminated with a 50ohm terminator. The other end of the Tee is connected to a BNC cable labelled "Nosie-Eater", which we traced all the way to the PSL table, where it is just hanging (also labelled "X end green noise eater"), unterminated, at the southeast corner of the PSL table. It is unlikely that this is of any consequence given the indicated coefficient of 0.1A/V, but could this somehow be introducing some junk into the laser diode current which is then showing up as intensity fluctuations in the output? Unfortunately, during the PLL measurements, I did not think to disconnect this BNC and take a spectrum. It would also seem that the noise-eater feedback to the laser diode current is implemented internally, and not via this external modulation input jack (the PSL, which I believe has the noise-eater enabled, has nothing connected to this rear input)...
I've repeated the measurement for the x-direction and also did the y-direction, taking into account Koji's suggestion of keeping the power meter as close as possible to the knife edge. Attachment #1 shows a picture of the setup used. Because an ND filter is required to use this particular power meter, the geometrical constraints mean that the closest the power meter can be to the knife edge is ~3cm. I think this is okay.
The result from the re-measured X-scan (Attachments #2 and #4) is consistent with the result from yesterday. Unfortunately, in the y-direction (Attachments #3 and #4), I don't seem to have captured much of the 'curved' part of the profile, even though I've started from pretty much adjacent to the HWP. Nevertheless, the fits look reasonable, and I think I've captured sufficient number of datapoints to have confidence in these fits - although for the Y-scan, the error in the waist position is large. The ellipticity as measured using this method is also significantly smaller than what the CCD beam profiler was telling us.
If we are happy with this measurement, I can go ahead and work on seeing if we can arrive at a minimally invasive mode-matching solution for the X-end table once we switch the lasers out...
Pasadena fire marshal inspected the lab today. No violation was found.
I don't think the discrepancy is a serious issue as long as the mode is clean. The mode is determined by the NPRO crystal and is hard to change by anything except for the thermal lensing in the crystal.
And I never succeeded to reproduce the mode listed in the manual.
One thing you'd better to take care is that clipping of the beam produces diffraction. The diffracted beam spreads faster than the nominal TEM00 mode. Therefore the power meter should to be placed right after the razor blade. i.e. As you move the longitudinal position of the razor blade, you need to move the power meter.
As Koji pointed out in the previous elog, the CCD beam profiler was ill suited for this measurement. Nevertheless, to get a rough idea of the beam profile, I made a few rearrangements to my earlier setup:
Following Koji's suggestion, I decided to do a knife-edge measurement as well. The measurement configuration was similar to the one described above, except the PBS/BS were removed, and a 1.0 neutral density filter was was installed ~80cm from the laser head (here the ~300 mW beam was >2mm in diameter, as judged by eye). I used the Ophir power meter, which was why I had to install an ND filter as it is rated for 100mW max power. I will put a picture up tomorrow. Thermal lensing shouldn't be of much consequence here, as we just need the whole beam to fall onto the power meter active area (verified by eye), and only the relative change in power levels as the knife edge cuts the beam matters. I took the cross-sectional profile of the beam by translating the knife in the x-direction (i.e. cut the beam "left to right" ).
Attachments 1 and 2 are the results from todays measurements. It remains to repeat by cutting the beam along the y direction, and see what ellipticity (if any) shows up. I also found some "nominal" numbers in page 4 of the Lightwave datasheet - it tells us to expect a waist 5cm from the shutter housing, with horizontal and vertical 1/e^2 diameters of 0.5mm and 0.38mm respectively. My measurement suggests a horizontal diameter of ~0.25mm (half the "nominal" value?!), and the waist location to be 8.22cm from the shutter housing. I wonder if this discrepancy is a red flag? Could it be due to the HWP? I'm reasonably sure of my calculations, and the fits have come out pretty nicely as well...
Daily summary pages are blank today. Yesterday is ok
jiIn fact, it is one of the most difficult type mode profiling to measure a beam directly out from a laser source.
If you reduce the power by ADJ, this significantly changes the output mode as the pumping power varies temperature gradient of the laser crystal and thus thermal lensing in it. I'd recommend you to keep the nominal power.
If you use a PBS for power reduction, you should increase the transmission ~x10 from the minimum so that you are not dominated by possible junk polarization.
Any transmissive BK7 components where the beam is small can cause thermal lensing. In order to avoid this issue, I usually use two noncoated (or one AR coated) optical windows made of UV fused silica to pick off the beam. Once the beam power is reduced I suppose it is OK to use an additional ND filter in front of the CCD.
Another more reliable method is an old-good knife edge measurement.
I've moved the following components that was a part of Koji's setup from the PSL table to the SP table so that I may measure the beam profile of the beam from the spare Lightwave NPRO and work on a mode-matching solution for the X-end.
I did some preliminary characterization of the beam from the Lightwave - in the power controlled mode, setting the "ADJ" parameter to 0 (which is the state recommended in the manual) gives an output power of ~240mW. I used the HWP and PBS to dump most of this into a "Black Hole" beam dump, but I was still getting about 300uW of power after this. This was saturating the CCD in the beam profiler (even though 300uW for a beam of ~1mm should be well within the recommended operating limits as per its manual - maybe the ND filter on the camera isn't really ND4.0), and so I further reduced the "ADJ" parameter on the laser controller to -20, such that I had no saturation of the CCD. I will try and take some data later today. The laser is presently in "Standby" mode, and the SP table is fully covered again.
Before distrubing the beat setup with the spare Lightwave laser, I wanted to see if I could resolve the apparent difference in behaviour between the measured free running noise of the spare Lightwave laser and my earlier measurements with the existing X and Y end lasers above ~5kHz. So I redid the measurement, but this time, on Eric's suggestion, while taking spectra on the SR785, I was careful to maintain the same "CH1 input range" while measuring the control signal spectrum and the measurement noise spectra. The level used was -20dBvpk. I think the measured spectrum shape now makes sense - above ~4kHz, the SR560 noise means that the SNR is poor and so we can only trust the spectra up to this value (the spectra for the end lasers are from earlier measurements where I did not take care to keep the input range constant). Anyways, I think the conclusion is that the spare Lightwave seems to have a free-running frequency noise that is approximately a factor of 3 worse than the Lightwave laser at the Y-end, though this may be because I didn't take the measurement at the optimal operating conditions (diode current, power etc). But I guess this is tolerable and that we can go ahead with the planned swapping out of the existing Innolight at the X-end with this laser.
I will now move the Lightwave laser off the PSL table onto the SP table where I will do some beam characterization and see if I can come up with a satisfactory mode-matching solution for the swap. I've borrowed a beam profiler from the TCN lab for this purpose.
This is the same one as what you got from Steve. But you can find full pages.
The Innolight laser control unit has a 25 pin D-sub connector on the rear which is meant to serve as a diagnostics aid, and the voltages at the various pins should tell us the state of various things, like the diode power monitor, laser crystal TEC error temperature, NE status etc etc. Unfortunately, I am unable to locate a manual for this laser (online or physical copy in the filing cabinets), so the only thing I have to go on is a photocopied page that Steve had obtained sometime ago from the manual for the 2W NPRO. According to that, Pin 1 is "Diode laser 1, power monitor, 1V/W". The voltage I measured (with one of the 25 pin breakout boards and a DMM) is 1.038V. I didn't see any fast fluctuations in this value either. It may be that the coefficient indicating "normal" state of operation is different for the 1W model than the 2W model, but this measurement suggests the condition of the diode is alright after all?
I also measured the voltage at Pin 12, which is described in the manual as "Noise Eater, monitor". This value was fluctuating between ~20mV and ~40mV. Toggling the NE switch on the front of the control unit between ON and OFF did not change this behaviour. The one page of the manual that we have, however, doesnt provide any illumination on how we are supposed to interpret the voltage measured at this pin...
It rained hard yesterday. We have not had this strong downpoor for years. We got 0.7" and the roof did not leak.
We got it! Traps are removed.
It is strange that there is no difference between with and without NE, isn't it?
I don't think there's any evidence that the noise eater is bad. That would change the behavior of the relaxation oscillation which is at 1 MHz ?
While I was investigating the AM/PM ratio of the Innolight, I found that there was a pronounced peak in the RIN at ~400kHz, which did not change despite toggling the noise eater switch on the front panel (see plot attached). The plot in the manual suggests the relaxation oscillations should be around 600kHz, but given that the laser power has dropped by a factor of ~3, I think it's reasonable that the relaxation oscillations are now at ~400kHz?
After adjusting the alignment of the two beams onto the PD, I managed to recover a stronger beatnote of ~ -10dBm. I managed to take some measurements with the PLL locked, and will put up a more detailed post later in the evening. I turned the IMC autolocker off, turned the 11MHz Marconi output off, and closed the PSL shutter for the duration of my work, but have reverted these to their nominal state now. The are a few extra cables running from the PSL table to the area near the IOO rack where I was doing the measurements from, I've left these as is for now in case I need to take some more data later in the evening...I
Innolight 1W 1064nm, sn 1634 was purchased in 9-18-2006 at CIT. It came to the 40m around 2010
It's diodes should be replaced, based on it's age and performance.
RIN and noise eater bad. I will get a quote on this job.
The Innolight Manual frequency noise plot is the same as Lightwave' elog 11956
Rana stated yesterday that there will be a vacuum control update in the close future. Witnesses : Rich, Chris and Dave
Can you give me this in writing?
Air condition maintenance is happening. It should be done by 10am
We will update the X circuit DCC page with an accurate schematic and photo.
I've uploaded reasonably high-resolution photographs of the uPDH box for the X-end and Y-end on their respective wiki pages. I've uploaded two photos for each box, one of the circuit board (I checked that these photos are clear enough that we can zoom in and read off component values if necessary), and one of the box with the peripherals not integrated into the circuit board (i.e. the minicircuits mixer ZAD-8+ and the little Pomona box that is an LP filter for the output from the mixer). Since I pulled the boxes out, I thought it might not be a bad idea to measure the TFs of these Pomona boxes and make sure nothing weird is going on, I'll put up some plots later.
Rana and I discussed some things to look at earlier today:
I also did a quick check of the behaviour of the Servo Gain potentiometer by checking the resistance at various positions of the knob - we had suspected that the potentiometer may be logarithmic, but I found that it was in fact linear. I'll put up a plot of the gain as a function of the Servo Gain knob position soon,(plot added) along with results from the other checks.
While disassembling the setup at the X-end to get the PDH box out, I noticed that the signal from the LO is going to the mixer through a Pomona box (no such Pomona box is used at the Y-end). I opened it up and found that it contains just a pair of capacitors in parallel, so it's a phase shifter?. The LO signal also goes through an attenuator. The mixer in both boxes is a ZAD-8+, so why is this part of the setup different?
Both PDH boxes are not hooked up at the moment, I will restore the setups at both ends after running a few more checks on the boxes...
Yesterday, I uploaded some EAGLE schematic files and a LISO source file for the green PDH servo electronics to the 40m LISO git repository. In doing so, I realized that the DCC document for the X box (D1400293) was not updated at the end of the electronics work we did in Aug/Sep 2014. This is entirely my fault.
The Y box document (D1400294) is currently accurate.
The missing information is that, as I posted In ELOG 10457, I ended up destroying our original X box, and replaced it with a spare from the ATF. It was restuffed to match the Y end box pretty much exactly. We will update the X circuit DCC page with an accurate schematic and photo.
Gautam tells me that he and Rana were looking at the outdated schematic and thinking about improvements, but at least some of this was already done back in 2014 (specifically, the resistors used to specify the AD8336 preamp gain were changed).
Summary of the work done today:
Alignment and other work on PSL table
As mentioned in a previous elog, the beatnote amplitude I obtained was tiny - so I checked the alignment of the two beams onto the PD. I did this as follows:
After doing all of this, I found a beatnote at ~-10dBm at a temperature of 45.3002 degrees on the Lightwave. The DC level was ~8V (~4V contribution from each beam).
PLL and frequency nosie measurements:
Pretty much the same procedure as that described in this elog was followed for setting up the PLL and taking the measurements, except that this time, I used the two SR560s in a better way to measure the open loop TF of the PLL. This measurement suggested a UGF of ~ 10kHz, which seems reasonable to me. I turned the 11MHz marconi off because some extra peaks were showing up in the beat signal spectrum. I judged that the beatnote was not large enough to require the use of an attenuator between the PD and the mixer. I was able to lock the PLL easily enough, and I've attached spectra of the control signal (both uncalibrated and calibrated). To calibrate the spectrum, I did a quick check to determine the actuator gain of the spare Lightwave laser, by sweeping the fast PZT with a low frequency (0.5Hz) 1Vpp sine wave, and looking at the peak in the beat signal spectrum move on the network analyzer. This admittedly rough calibration suggests that the coefficient is ~5MHz/V, consistent with the other Lightwave. Eric suggested a more accurate way to do this would be to match up spectra taken using this method and by locking the PLL by actuating on the FM input of the Marconi - I didn't try this, but given the relatively large low-frequency drifts of the beatnote that I was seeing, and that the control signal was regularly hitting ~2V (i.e shifting the frequency by ~10MHz), I don't think this is viable with a low MHz/V coefficient on the Marconi, which we found is desirable as described here.
The spare Lightwave frequency noise seems comparable to the other two measurements (see attachment #2). If anything, it is a factor of a few worse, though this could be due to an error in the calibration? I'm also not sure why the shapes of the spectra from today's measurement differ qualitatively from those in elog 11929 above ~7kHz.
Some random notes:
I didn't really appreciate this measurement until just now. IF you can save the DTT .xml file with all the traces in it (i.e. NOT just the plots), we should save this data for comparison plotting later. Perhaps Gautam can post the gzipped xml file for you into the log.
The accelerometers don't read any real noise below ~3 Hz, so we can't judge the difference down low, but this seems like a good measurement in the 5 - 100 Hz band.
Unfortunately I had closed all the DTT windows that Steve had used for the earlier plots. So I took the spectra again - there may be minor differences given that this measurement was taken at ~11pm at night. Anyways, plots and the xml data file are attached.