Jamie went out to look at IP POS, and the beam was *way* off. Even though our alignment is still rough, we're kind of close right now, so Jamie put the beam back on the QPD, but we need to recenter IPPOS after we get good alignment.
IPPOS is back. A cable had been disconnected at the 1Y2 rack. So I put it back to place.
The cartoon below shows the current wiring diagram. I think this configuration is exactly the same as it it used to be.
+ Fixing IPPOS (volunteers)
Its back in and re-centered. Our next move on IPPOS should be to replace its steering mirror with something bigger and more rigid.
20K -> 3.65 K (R6, R20, R42, R31) (unused)
20K -> 3.65 K (R7, R21, R32, R43, R11, R24, R35, R46)
If you look in the schematic (D990272), you see that its an AD797 transimpedance stage with a couple of LT1125 stages set to give some switchable gain. It looks like some of these
switches are on and some are not, but I am not sure where it would be controlled from. I've attached a snapshot of one quadrant of the schematic below.
The schematic shows the switches in the so-called 'normally closed' configuration. This is what the switches do with zero volts applied to the control inputs. As the schematic also shows,
just disconnecting the 'switch' inputs cause the switch's control inputs to go high (normally open configuration, i.e. pins 2-3 connected, pin4 open). For the record, the default positions of the IPPOS switches are:
** EDIT (Nov 2, 2009): I forgot to attach the before and after images; here they are:
I tried to compare the IP_POS time series with the IPANG and MC_TRANS but was foiled at first:
1) The IPANG scan rate was set to 0.5 second, so it doesn't resolve the pendulum motions well. Fixed in the .db file.
2) Someone had used a Windows/DOS editor to edit the .db file and it was filled with "^M" characters. I have removed them all using this command: tr -d "\r" <ETMXaux.db > new.db
3) The MC_TRANS P/Y channels were on the MC Lock screen but had never been added to the DAQ. Remember, if there's a useful readback on an EPICS screen. its not necessarily in the frames unless you add it to the C0EDCU file. I have done that now and restarted the fb daqd. Channels now exist.
4) Changed the PREC of the IPPOS channels to 3 from 2.
5) changed the sign for the IBQPD (aka IPANG) so that bigger signal is positive on the EPICS screen.
After locking the arms (after the MC alignment work), Manasa and I aligned IP POS, IP ANG, and both end transmission QPDs.
We noticed that IP ANG is clipping in yaw as it comes onto the end table. It looks to me like it's clipping on the edge of the plastic box's aperture, but I can't guarantee that it's not also clipping elsewhere.
Pointing stability of 4 days. Initial pointing does not go through suspended optics. It is launched right after the Piezo Jena steering mirrors in the BS chamber.
IP-ANG on epics screen is C1:ASC-IBQPD_X and Y in dataviewer were recentered. This beam is clipping a bit in ETMX chamber pick off mirror.
IP-POS pick off is in the BS chamber and it's qpd on the BS_ISCT This beam is also clipping just a little bit. This is easy to fix. We'll have to remove an iris from the BS optical levers table.
note: arms were not locked when I recentered
IP-ANG clipping can be traced back to our last vent of Aug. 18, 2008 See elog entry #845
This was an after earth quake - sus repair vent
Initial pointing or IP-ANG is a pointing monitor of the MC. This beam is launched after the second pzt steering mirror.
IP-ANG is missing the pick up mirror by a few inches at ETMYchamber
1000 days plot show last appearance in Feb 2010
IP-ANG is coming out of ETMY without clipping. The beam is very high on the pick off mirror at the end table but it is still missing the qpd .
[Jenne, Evan Hall]
Both IPPOS and IPANG beams are (after turning on the input and output PZTs) hitting their QPDs. However IPANG was saturating. We went down to take a look, and we had ~2.8mW incident on the QPD. There was an ND filter sitting unmounted, next to the diode, and an empty fork directly in front of the diode. Since IPPOS also has an ND filter in front, we stuck this ND filter back in. Now we are no longer saturating.
We're not hitting (yet) the center of these 2 PDs, but we're at least hitting the diodes, so it shouldn't be too hard to steer the input PZTs.
Whomever took away this ND filter without elogging it was BAD!!! (Jamie, when we first found IPANG coming out of the vacuum during this vent, we moved some of the mirrors on the out-of-vac table in the IPANG path. Was the ND filter removed at that time? Or has it been out for much longer, and we never noticed because IPANG wasn't coming nicely out of the vacuum / was clipping on the oplev lens?)
[Whomever took away this ND filter without elogging it was BAD!!! (Jamie, when we first found IPANG coming out of the vacuum during this vent, we moved some of the mirrors on the out-of-vac table in the IPANG path. Was the ND filter removed at that time? Or has it been out for much longer, and we never noticed because IPANG wasn't coming nicely out of the vacuum / was clipping on the oplev lens?)
I do not remember removing anything from that setup. We just moved some mirrors and lenses around
I was having trouble centering IPANG using the PZTs, and I suspected something funny was going on at the end. I went down there, and the beam was focused right on the PD, and the spot was very very small. I think this means that when I was trying to center the beam, I was falling into the gap between the pieces of the diode. Also, as Koji pointed out to me the other day, if the PD is at the focal point of the beam, any parallel rays hitting the lens just before the PD will all go to the same place, no matter how the input beam has moved. This means we're not getting as much info out as we'd like.
So. I moved the lens a little bit farther from the PD such that we are just beyond the focal point of the beam. The beam size is now ~1mm on the QPD.
This means, however, that I moved the beam on the QPD such that IPANG is no longer a reference of the input pointing. Ooops. I think this adjustment needed to be done though. Right now, the PZTs are set to where we had them yesterday, when we moved them slightly to center the IPANG QPD, and I've recentered IPANG.
I've set up two IPC channels that take the output from the digital frequency counters and send them to the end front-ends (via the RFM model). A summary of the steps I followed:
I've set things up such that we can select either the "PZT IN" or the frequency counter as the input to the slow servo, via means of a EPICS variable called "FC_SWITCH" (so C1:ALS-X_FC_SWITCH or C1:ALS-Y_FC_SWITCH). If this is 0, we use the default "PZT IN" signal, while setting it to 1 will change the input to the slow servo to be the frequency readout from the digital frequency counter. I've not updated the MEDM screens to reflect the two new paths yet, but will do so soon. It also remains to install appropriate filters for the servo path that takes the frequency readout as the input.
Tangentially related to this work: I've modified the FC library block so that it outputs frequency in MHz as opposed to Hz, just for convenience..
When signals are transmitted between the models running at different rates, no AI or AA filters are automatically applied. We need to fix our models.
This is known, but we just haven't fully groked it yet. We need to look closely at every place we have IPCs between models running at different rates. The sender has no information about receivers, so it can't reasonably do anything to pre-filter the signal on it's own.
So for transmission from:
*sigh* This is one of those things that I meant to take care of months ago, but haven't yet. I agree that it needs doing. It's been on my whiteboard to-do list for a long time now. Bad Jenne for not taking care of it.
Dataviewer wouldn't launch on pianosa - it seemed to work fine on Donatella though. Rana suggested using the ipcs -q command. The complete fix can be found in this elog. This did the trick, dataviewer runs fine on Pianosa now...
I centered IPPOS. I do not find any IPANG beam on the ETMY table, even waving the IR card in the black beam tube.
I took photos of the PZT2 HV supplies with the new camera, but I can't figure out how to get the pictures off the camera. I guess the camera is smarter than I am.
The input matrix of IPPOS were fixed so that the horizaontal motion correctly shows up in X and the vertial is Y.
(what I did)
+ The data base file, QPD.db, were edited.
QPD.db is a part of the c1isxaux slow machine and it determines the input matrix for deriving the X/Y signals from each quadrant element.
+ The previous input matrix was :
X = (SEG1 + SEG4) - (SEG2 + SEG3)
Y = (SEG1 + SEG2) - (SEG3 + SEG4)
+ The new matrix which I set is :
X = (SEG1 + SEG2) - (SEG3 + SEG4)
Y = (SEG1 + SEG4) - (SEG2 + SEG3)
The new matrix is a just swap of the previous X and Y.
+ Then c1isxaux was rebooted by :
+ The I did the burt restore it to this morning.
The channels for IPPOS had been assigned in a wrong way.
I've suspected that the TTs are drifting significantly over the course of the last couple of days, because despite repeated alignment efforts, the AS beam spot has drifted off the center of the camera view. I tried looking at IPPOS, but found that there was no data. Looking at the table, the QPD was turned backwards, and the DAQ cable wasn't connected (neither at the PD end, nor at 1Y2, where instead, a cable labelled "Spare QPD" was plugged in). Fortunately, the beam was making it out of the vacuum. So as to have a quantitative diagnostic, I reconnected the QPD, turned it the right way round, and adjusted the steering onto it such that with the AS spot on the center of the CCD monitor, the beam is also centered on the QPD. The calibration is uncertain, but at least we will be able to see how much the spot drifts on the QPD over some days. Also, we only have 16 Hz readback of this stuff.
I leave it to Chub to take the high-res photo and update the wiki, which was last done in 2012.
Already, in the last ~1 hour, there has been considerable drift - see Attachment #2. The spot, which started at the center of the CCD monitor, has now nearly drifted off the top end. The ITMX and BS Oplev spots have been pretty constant over the same timescale, so it has to be the TTs?
I found that the ADC channels for IP_ANG had been assigned to a wrong machine.
IP_ANG is supposed to be acquired at c1auxey (east end), but actually it had been at c1auxex (south end).
This is the reason why we couldn't see any signals from IP_ANG.
So I fixed it by editing the db files (i.e. ETMXaux.db and ETMYaux.db). Now it seems working fine.
This mistake obviously came from the X-Y name swapping business. Something else might be still wrong.
A cable for IP_POS has been disconnected at the LSC rack, 1Y2. Due to it currently no IP_POS signal shows up on the digital side.
It looks like we disconnected the cable together with some unused cables when we were cleaning up the wiring of the LSC rack.
The cable, a shielded flat-cable, is supposed to send DC power to the QPD and send the signals from the QPD to an interface board on the LSC rack.
I will check how it used to be and reconnect it.
I found the disconnected cable, but I do not see the interface board at the LSC rack
A cable for IP_POS has been disconnected at the LSC rack, 1Y2. Due to it currently no IP_POS signal shows up on the digital side.
The new K6XS mounts I ordered have arrived. I want to install one of them at the Y-end. I can't find a picture of the current layout but it exists as there is a hardcopy affixed to the ETMY chamber door, Steve, can we dig this up and put it in the wiki? In any case, the current beam going into the fiber is the pickoff from the post-SHG harmonic separator. I'd like to change the layout a bit, and use a pickoff before the doubling oven, but looking at the optical table, this seems like a pretty involved task and would probably require large scale optical hardware rearrangement. In any case, the MM of the green beam into the Y-arm is <50%, so I would like to redo that as well. Does anyone know of a measurement of the mode from the Lightwave NPRO that is installed at EY? I think Annalisa is the one who installed this stuff, but I can't find an actual NPRO mode measurement in her elog thread.
Found it: elog4874, elog8436. I updated the laser inventory page to link the lasers in use to the most recent mode measurements I could find on the elog. I guess ideally we should also link the AM/PM response measurements.
SV ETMY optical table layout
as of 3-31-2016
The oplev path was optimized with AR coated lenses and new He/Ne laser Jan 24, 2017
My goal tonight was to lock the PSL frequency to be resonant in the XARM cavity, using the PSL+EX beat as the error signal. I was not successful - mainly, I was plagued by huge BR mode coupling in the error signal, and I could not enable the BR notch filter in the control loop without breaking the lock. Need to think about next steps.
Anyway, now that I have a workable set of settings that gets me close to the ALS lock of the XARM, I expect debugging to proceed faster.
Update 2019 July 23: I looked at the control loop shape today, see Attachment #3. I'm not sure I understand why the "BounceRoll" filter in this filter bank looks like a resonant gain rather than a notch, as it does for the Oplev or SUSPOS loops for example - don't we want to not actuate at these frequencies because the reason the signal exists is because of the imperfect OSEM/magnet positioning? This does not explain the spectrum shown in Attachment #2 however, as that filter was disabled.
To start the noise budgeting, I decided to measure the "DFD noise", which is really the quadrature sum of the following terms:
According to past characterizations of these noises, the ADC noise level, which is expected to be at the level of a few uV/rtHz, is expected to be the dominant noise source.
The measurement was made by disconnecting the NF 1611 free space photodiode from the input to the RF amplifier on the PSL table, and connecting a Marconi (f_carrier = 40 MHz, signal level=-5dBm) instead. The phase tracked output was then monitored, and the resulting digital spectrum is the red curve in Attachment #1. The blue curve is the ASD of fluctuations of the beatnote between the PSL and EX IR beams, as monitored by the DFD system, with the X arm cavity length locked to the PSL frequency via the LSC servo, and the EX green frequency locked to the X arm cavity length by the analog PDH servo.
Assuming the Marconi frquency noise is lower than the ones being budgeted:
Next noises to budget:
Updated the noise budget to include the unsuppressed frequency noise from the EX laser. It does not explain the noise between 10-100 Hz, although the 1-3 Hz noise is close.
Actually, I think the curve that should go on the budget is when the X arm length is locked to the PSL frequency, whereas this is when the X arm is just locally damped. I will update it later tonight.
Update 1010pm: I've uploaded the relevant plot as Attachment #2. Predictably, the unsuppressed frequency noise of the EX laser is now higher, because the MC length is a noisier frequency reference than the arm cavity. But still it is a factor of 10 below the measured ALS noise.
My goal was to do some further characterization of the IR ALS system tonight. With POX as an OOL sensor, I measured an RMS displacement noise of 8 pm with the arm under ALS control. I calculated the CARM linewidth to be 77 Hz (=10.3 pm) for the 40m parameters, assuming 30ppm arm loss. Fuurthermore, this number is 3x better than the 24 pm RMS quoted in the Izumi et. al. paper. Of course I am quoting the best results from my efforts tonight. Conclusions:
Since the stability and noise seemed quite good, I decided to collect some arm scan data to give to our modeSpec SURFs to practice fitting (which is the short dip in TRX in Attachment #4). Although after the discussion with Rana today, I think it may be that we want to do this measurement in reflection and not transmission, and look for a zero crossing in the PDH signal. In any case, I was able to scan 7 FSRs without any issues. I will upload the data to some git repo. GPS start time is 1208850775, sweep was 3mins long.
I think the next step here is to noise-budget this curve. At least the DFD noises
These spectra were taken with the arm cavity length locked to the PSL frequency using POX as an error signal, and the EX laser frequency locked to the XARM cavity length by the analog PDH servo at EX, so there is no feedback control with the ALS beat signal as an error signal.
I borrowed the Olympus and forgot to leave a note - I should have it for at most a day. dmassey@ligo if you need it urgently
The script is moving forward and we feel we are close, however we still have a couple of issues, which are:
1) some python misbehaviour between the system environment and the anaconda one; currently we call bash commands within the python script in order to avoid using the ezca library, which is the one complaining;
2) the fine scan is somewhat not so robust yet, need to investigate more; the main suspects are the wavelet parameters given to the algorithm, and the Offset and Ramp parameters used to perform the scan.
Here is an example of a best case scenario, with 20s ramp and 500 points:
Tonight I tried some more tests on the script; it seems to work better, with both performance and robustness improved, although the Xarm behaved badly almost all the time. I did not perform all the tests I wanted because the ALS lock was pretty unstable tonight (not only because of the X arm), with more than a few lock losses; after the last lock loss, however, I couldn't restore the Xarm. I'll do some more tests as soon I can recover it, or post the result of the first batch of tests.
In addition, I encountered the following error multiple times, but I have no idea about what could it be:
Thu Nov 06 02:00:13 PST 2014
medmCAExceptionHandlerCb: Channel Access Exception:
Channel Name: Unavailable
Native Type: Unavailable
Native Count: 0
Message: Virtual circuit disconnect
Requested Type: TYPENOTCONN
Requested Count: 0
Source File: ../cac.cpp
Line number: 1214
EDIT on X arm: I found different settings in C1SUS_ITMX, with respect to ETMX, ITMY and ETMY (namely LSC/DAMP is OFF and LSC/BIAS is ON); I don't know if this is intended or for some reason ITMX was not recovered properly after the lock loss, so I didn't change anything, but it may be worth looking into that.
Still no luck in recovering the X arm, I am giving up for tonight; honestly I didn't try many things, as I don't know well the system and didn't want to mess things up.
Preliminary results so far:
I confirm that the best settings for the ramp of the ALS scan are 20s and 500 points; this causes however the script to be fairly slow (80s for the scan/data collection, 7s for the coarse peak finding, 17s for the fine peak finding, total ~2 min); in the best cases the TR*_OUT obtained is around 0.90, as shown in the first plot (early in the evening, all the following plots are in chronological order, if that can help finding the reason for the X arm misbehaviour...):
However, after a few minutes somehow the TR*_OUT went down a bit, without any kind of intervention; also, it is visible the instability of the X arm:
Even when X arm was somewhat stable, its performance and robustness were (far) worse than the Y arm ones:
The following plot shows (about the Y arm only) that there is still some margin, as the maximum value of TRY_OUT is not completely kept at the end of the procedure:
Finally the last plot I managed to obtain, before the X arm went completely crazy...
The next step, after obviously figuring out the X arm situation, is to try some averaging during the fine scan, I don' t know if this will improve the situation, however it shouldn't impact on the execution time. Tomorrow I'll post something more detailed on the script itself and the wavelet implementation.
Yesterday I did some more tests with a modifies script; the main difference is that scipy's default wavelet implementation is quite rigid, and it allows only very few choices on the wavelet. The main issue is that our signal is a real, always positive symmetrical signal, while wavelets are defined as 0-integral functions, and can be both real or complex, depending on the wavelet; I found a different wavelet implementation, and I combined it with some modified code from the scipy source, in order to be able to select different wavelets. The result is the wavelet_custom.py module, which lives in the same ALS script directory and it is called by the script. In both the script and the module there the references I used while writing them. It is now possible to select almost any wavelet included in this custom module; "almost" means that the scipy code that calls the find_peaks_cwt routine is picky on the input parameters of the wavelet function, I may dig into that later. For the last tests, instead of using a Ricker wavelet (aka Mexican hat, or Derivative of Gaussian Order 2), I used a DOG(6), as it also has two lesser positive lobes, which can help in finding the resonance; the presence of negative lobes is, as I said, unavoidable. I attach an example of the wavelet forms that are possible, and in my opinion, excluding the asymmetric and/or complex ones, the DOG(6) seems the best choice, and it has provided slightly better results. There are other wavelet around, but they are not included in the module so I should implement them myself, I will first see if they seem fitting our case before starting writing them into the module. However, the problem of not finding the perfect working point (the "overshoot-like" plot in my previous elog) is not completely solved. Eric had a good idea about that: during the fine scan, the the PO*11_ERR_DQ signals should be in their linear range, so I could also use them and check their zero crossing to find the optimal working. I will be working on that.
Tonight I started testing a new method for the fine scan:
The other night (before the holidays), I tried ALS offset tuning with IR POX/POY signals and it worked pretty good.
I didn't need to tune the offset after the scanning script stopped.
Once we are at the foot hill of the main resonance, I ran something like
ezcaservo -r C1:LSC-POX11_I_MON C1:LSC-ALSX_OFFSET -g -0.003 &
ezcaservo -r C1:LSC-POY11_I_MON C1:LSC-ALSY_OFFSET -g -0.003 &
(... I am writing this with my memory. I could be wrong but conceptually the commands looked like these)
[Jenne and Kiwamu]
This time we aligned the vertical angle (not the translation) of the IR beam so that the transmitted light from BS shoots the center of ETMY.
The idea is to use ETMY as a beam pointing reference instead using IP_ANG, assuming the translation is not so bad.
As a result it looks like we are wining. A quick A2L test on ITMX_PITCH showed a small off-centering at sub-milimeter level.
We are concluding that the initial beam after PZT2 had been pointing downward somehow.
Before doing this whole job, we checked the spot shape on IP_POS to see if the beam is clipped or not. It was a round shape, which means no clipping around MMT.
But on the other hand, the spot on IP_ANG had been clipped more than half of its bottom as Suresh reported on his elog (see here).
I found that this clipping is able to be fixed by moving the beam angle upward. I guess the clipping happened at one of the steering mirror in the ETMY chamber.
According to these information, we imagined that the beam was somehow pointing downward after PZT2.
So we started aligning the beam by touching only PZT2 for vertical direction. Then we found a beam spot on ETMY's suspension frame, and brought it to the center.
Then we aligned BS and X arm for this new beam axis. The it resulted a small off-centering on pitch.
Once the MC fully gets back, we will examine the TRX degradation with this configuration.
I tried aligning the IR beam axis for the X arm to have good beam centering on ITMX and ETMX.
As a first attempt, I started translating the beam upward by steering PZT1 and PZT2, since the pitch was quite off from the center on ITMX.
As a result I could decrease the pitch off-centering down to about 0.5 mm on ITMY, but on the other hand TRX decreased a lot (by a factor of 4).
I am worrying if something in the central part of IFO might be clipping the beam.
When I was touching PZT1 and PZT2, I payed attention on IP_ANG so that I don't lose a beam spot on IP_ANG.
As long as the beam is on the IP_ANG QPD, the angle of the beam should not be so much different.
Each time after I touched the PZTs, I realigned ITMX and ETMX to maximize the transmitted light.
In this way I proceeded the alignment by changing the PZT offsets little by little while keeping the X arm locked always.
At the beginning, all the PZT offsets were zero. And at the end of this work they became:
C1:LSC-PZT1_Y = 1.880
C1:LSC-PZT2_Y = -1.699
But during this alignment work TRX gradually decreased eventually down to 0.25, which had been 1 at the beginning (TRX is calibrated by dividing it by its maximum power).
Along with this TRX reduction, I found that the optical gain also decreased by a factor of about 5.
This fact has been confirmed by intentionally increasing the filter gain such that the servo oscillates at the UGF.
The amounts of the X arm's beam off-centering have been measured by the A2L technique.
PIT = -1.61 mm
YAW = -0.918 mm
PIT = -3.76 mm
YAW = -2.24 mm
The IR beam was found on the PRM surface, some CCDs, and in the X arm. The TTs are not aligned well yet.
I'm leaving the IFO with the following state.
ITMY/ETMY - aligned to the given green beam. GTRY (no PSL green) 1.0~1.1
ITMX/ETMX - aligned to the green beam. The end PZT for the green beam was steered to have maximum GTRX (0.76 without PSL green)
TT1/TT2 - unknown alignment, TT1/TT2 are related such that the spot is on the POP CCD
PRM - aligned to the given IR beam (i.e. PRM spot on the REFL CCD)
BS - aligned to the given IR beam (i.e. ITMX spot on the AS CCD, The X arm is flashing)
- ITMX was stuck in the suspension. it was caused by the EQ.
- When the X arm was aligned to the green beam, there was no green hitting on the GTRX PD. That's why the end PZT was adjusted.
- In order to earn more range for TT1, C1:IOO-TT1_YAW_GAIN and C1:IOO-TT1_PIT_GAIN were increased to 300 (100 nominal) and the limiter (at 500) were removed.
- The HeNe laser for BS/PRM does not emit the beam even with the driver turned on. Is there a hidden shutter or something? ==> Jenne
- Find the Y arm fringe by moving TT1 and TT2 without loosing the PRM/AS/POP spots.
Yuta is going to bring this up at the 40m meeting so it can be argued over, but we (I) want a permanent IR beat setup at the PSL table. This isn't a novel idea or anything, I just think it will save us time if we can quickly re-acquire the beat signal, so I'm bringing it up again. Eventually, as Koji suggested to me, we can make the IR beat part of a servo, so that the green beat is always within the bandwidth of the green beat PD. But for Phase 1, it's enough to just see the Ir beat on a ~1GHz PD. Suresh tells me most of the bits and pieces are around, we just have to gather them all in one place.
There has been some discussion here and there of using fiber coupled IR beats for ALS. A few weeks ago, and again today with Eric G, I poked around a bit with the fiber box Manasa set up for the FOL scheme.
Somehow, the IR beatnote is ~1000 times smaller than expected, both with the Thorlabs fiber coupled PD and a fiber coupled NF 1611.
In essence, after the fiber combiner, there is on the order of hundreds of uW each of PSL and AUX X IR light. The output of the fiber from each source looks nice and gaussian. The DC output of the 1611 indicates that it is seeing the right level of light. The green beatnote exists with good SNR at twice the IR beat frequency, so we know that the IR beat isn't some junky modes beating.
For the 1611, we would expect an RF signal of ~1mW*0.9A/W*700V/A -> .6V / +8dBm. Instead we see ~2mV / -40dBm.
Incidentally, there is some 20mV / -20dBm signal at ~400kHz, presumably from the green PDH modulation at ~200k.
(The level out of the thorlabs PD is similarly tiny; it doesn't have a DC output though, so we don't know the DC power that the active surface really sees. Not that I expect it to be much different, but the NF just makes it easier to estimate.)
The only things that should be able to cause the beat to be smaller than expected from the power levels are mode matching and polarization matching. All the fibers are single mode, so mode matching should be effectively 100%. Maybe somthing fishy is happening with the polarizations, but they'd have to be really maliciously close to orthogonal to cause this level of mismatch.
Maybe we just don't understand the splitter/combiners. Mysterious.
Maybe we just don't understand the splitter/combiners.
After an email from Eric G, I think this is the case.
If you read the text at Thorlabs about Fiber-Based Polarization Beam Combiners/Splitters, it suggests that these things take input beams both aligned to their slow axes, and outputs one field along the slow, and one orthogonal to it on the fast axis. Which is exactly what we don't want for a beat.
From the AFW website about our product, the POBC-64-C-1-7-2-25dB:
port1 slow axis -> port3 slow axis
port2 slow axis -> port3 fast axis
I was thinking that the "FOSC" product line (which is called a "coupler" instead of a "splitter/combiner") was what we wanted.
Koji brought to my attention that the 90/10 splitters we already have are of this line. So, I rigged a few up to shine a hopefully beating pair of fields on the fiber coupled thorlabs PD.
I was able to get ~80uW each of PSL and AUX X light on the PD, which produced a -10dBm beatnote! Thus, I think these FOSC splitters are indeed what we want.
I then threw this IR beatnote at our ALS signal chain. The beatnote was too big to throw through our ~+27dB RF amps, so I just sent the -10dBm over to the LSC rack.
The IR beat spectrum is somwhat noisier from 10-100Hz, but, more interesting, is that the sub-4Hz noise is identical in the two beats, and very coherent. This excludes ALS noise arising from anything happening in the green beat optics on the PSL table.
Obviously, the high frequency noise is largely the same and coherent too, but also coherent with the AUX X PDH control signal, so it is understood.
Single mode coupler, 2x2, 1064nm +/-20nm, 50/50 ratio, 900micron loose tube jacket, Hi1060flex fiber, 1m fiber length, FC/APC connectors
Four of these items ordered yesterday from http://afwtechnologies.com.au/sm_coupler.html
Yuta retrieved the IR card that had fallen to the bottom of the IOO chamber, just before we put on the access connector yesterday. The clean "pickle picker" long grabber tool worked wonders.
Sorry to say but MC1, MC2, MC3 and PRM face OSEMS are having the same problem of leaking IR into the sensors
The PMC was not locked for 11 minutes on this plot.
The PRM sensors are no longer effected by IR. What changed? The MC still does.
I came in today to check up on the StripTool and burn the Ubuntu LTS (new CDS OS) DVD. I was pretty excited to see the PRM flashes on Mon1.
I waggled the PRM/BS alignments and got a good contrast MICH and then bright flashes in the PRM that totally overload Mon1's CCD.
Now I can see flashes of some IR junk in the X Arm; its way off on the left edge of the mirror, but there's a beam.
For the short term, we can hook up the IO PZTs to some old EPICS channels (like one of the AUX guys in the LSC area), but eventually it has to get hooked up to the new ASC or ASS. We have to bug Joe to see where this shows up in his master diagram.
**Note: if you get lost sometimes when doing the alignments, remember that you can use time_machine_conlog.
rossa:general>./time_machine_conlog 2010/12/31,11:00:00 PDT C1:SUS-ITMX_PIT_COMM
Issuing the conlog command:
/cvs/cds/caltech/conlog/bin/conlog +epics -interp at 2010/12/31,11:00:00 PDT "C1:SUS-ITMX_PIT_COMM"
LIGO controls: values at 2010 12/31 11:00:00 pst
Attached is the last 8 days of Vacuum Pressure trend which includes the pumpdown.
[Gautam, Lydia, Johannes]
The next step is the tip tilt fine alignment of the IR into the arm, using TRY, from which we removed the ND filter for the time being.
Looks like we might have a problem with the IRIG-B output of the GPS receiver.
Rolf came over this morning to help debug the strange symmetricom driver behavior on fb1 with the new Spectracom card. We restarted the machine againt and this time when we loaded the drive rit was clocking at a normal rate (second/second). However, the overall GPS time was still wrong, showing a time in October from this year.
The IRIG-B122 output is supposed to encode the time of year via amplitude modulation of a 1kHz carrier. The current time of year is:
controls@fb1:~ 0$ TZ=utc date +'%j day, %T'
162 day, 18:57:35
The absolute year is not encoded, though, so the symmetricon driver has the year offset hard coded into the driver (yuck), to which it adds the time of year from the IRIG-B signal to get the correct GPS time.
However, loading the symmetricom module shows the following:
[ 1601.607403] Spectracom GPS card on bus 1; device 0
[ 1601.607408] TSYNC PIC BASE 0 address = fb500000
[ 1601.607429] Remapped 0xffffc90017012000
[ 1606.606164] TSYNC NOT receiving YEAR info, defaulting to by year patch
[ 1606.606168] date = 299 days 18:28:1161455320
[ 1606.606169] bcd time = 1161455320 sec 959 milliseconds 398 microseconds 959398630 nanosec
[ 1606.606171] Board sync = 1
[ 1606.616076] TSYNC NOT receiving YEAR info, defaulting to by year patch
[ 1606.616079] date = 299 days 18:28:1161455320
[ 1606.616080] bcd time = 1161455320 sec 969 milliseconds 331 microseconds 969331350 nanosec
[ 1606.616081] Board sync = 1
Apparently the symmetricom driver thinks it's the 299nth day of the year, which of course corresponds to some time in october, which jives with the GPS time the driver is spitting out.
Rolf then noticed that the timing module in the VME crate in the adjacent rack, which also receives an IRIG-B signal from the distribution box, was also showing day 299 on it's front panel display. We checked and confirmed that the symmetricom card and the VME timing module both agree on the wrong time of year, strongly suggesting that the GPS receiver is outputing bogus data on it's IRIG-B output, even though it's showing the correct time on it's front panel. We played around with setting in the GPS receiver to no avail. Finally we rebooted the GPS receiver, but it seemed to come up with the same bogus IRIG-B output (again both symmetricom driver and VME timing module agree on the wrong day).
So maybe our GPS receiver is busted? Not sure what to try now.